> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deployment methods

> Which parts of the platform run on Komodor's infrastructure and which run in yours, and what that means for access and data.

The Komodor Agentic Operation Platform (KAOP) has two moving parts — the control plane and your
agents — and they do not have to run in the same place. This page explains the choices, and what
each one means for network access and data. Read it before planning a rollout, because it decides
what your network and security teams have to approve.

## The split

|                      | Runs where                            | Operated by     |
| -------------------- | ------------------------------------- | --------------- |
| **Control plane**    | Komodor's infrastructure **or** yours | Komodor, or you |
| **Agents (workers)** | Komodor's infrastructure **or** yours | Komodor, or you |

The control plane holds the registry, run lifecycle, evidence, identity, and storage. Agents are
processes that do the work. Both are separate decisions: you can run agents yourself against a
Komodor-hosted control plane, which is the common case, or run the whole platform yourself.

Most of this page is about **where agents run**, because that is the choice almost everyone makes.
Running the control plane yourself is covered in [Self-hosting](/get-started/on-prem/overview).

<Warning>
  Running the control plane yourself is arranged with Komodor rather than started from the console.
  Every tier is delivered per agreement, so talk to your account team before you plan a rollout
  around it. Running your own agents against a Komodor-hosted control plane — the rest of this
  page — needs no such arrangement.
</Warning>

## Komodor-hosted agents

The simplest path. You deploy an agent from the console and Komodor runs the worker for you.
Nothing to install, no infrastructure to provide, and the agent is online as soon as it registers.

Choose this when an agent's work is reachable over APIs it can call with credentials you have
connected — most investigation, review, and cost work.

## Self-hosted agents

You run the worker in your own environment — a Kubernetes cluster, a VM, or a container platform —
and it connects out to the control plane.

Choose this when the agent needs something only reachable from inside your network: a private
cluster's API, an internal service, a database, or a tool with no public endpoint.

<Steps>
  <Step title="Build or take an agent">
    Author a worker with the SDK, or use one of ours that supports self-hosting. See
    [Build from scratch](/manage-your-agents/build/build-from-scratch).
  </Step>

  <Step title="Give it a credential and the workspace host">
    The worker authenticates to the control plane and identifies which agent it is running.
  </Step>

  <Step title="Run it where the work is">
    It registers on start and appears in your fleet. See
    [Deploy an agent](/manage-your-agents/build/deploy-an-agent).
  </Step>
</Steps>

## What the network needs

This is the part most reviews turn on:

* An agent needs **outbound** access to the control plane — wherever that control plane runs. That
  is all.
* Nothing needs to reach **into** your environment. Work is delivered over the connection the
  agent itself opened.
* No inbound firewall rule, no public endpoint, and no VPN is required to run agents in a private
  network.

<Note>
  Because work arrives on an outbound connection, a self-hosted agent behind NAT or with
  egress-only networking runs exactly like a hosted one.
</Note>

## What this means for your data

A self-hosted agent keeps the *reach* inside your environment: it calls your internal systems
directly, and its credentials for them never leave your network.

What does travel to the control plane is the agent's **evidence** — the run's inputs, tool calls,
reasoning, output, and usage — because that is the record the platform exists to keep. Secrets are
delivered to a run in memory and are never written into that evidence. See
[Data handling & redaction](/security-and-governance/architecture-considerations/data-handling-redaction).

## Mixing both

Most teams do. The split is per agent, so a Komodor-hosted investigator can work alongside a
self-hosted agent that reaches a private cluster, with one fleet, one set of permissions, and one
evidence trail across both.

## Next steps

<CardGroup cols={2}>
  <Card title="Architecture" href="/get-started/architecture">
    How the control plane and agents communicate.
  </Card>

  <Card title="Deploy an agent" href="/manage-your-agents/build/deploy-an-agent">
    Getting a worker running.
  </Card>

  <Card title="Network & egress control" href="/security-and-governance/architecture-considerations/network-egress-control">
    Scoping what agent traffic may reach.
  </Card>

  <Card title="Agent isolation & tenancy" href="/security-and-governance/architecture-considerations/agent-isolation-tenancy">
    How workspaces stay separate.
  </Card>
</CardGroup>


## Related topics

- [Self-hosted control plane](/get-started/on-prem/overview.md)
- [Architecture](/get-started/architecture.md)
- [Outposts](/manage-your-agents/build/outposts.md)
- [Install](/get-started/on-prem/install.md)
- [Operating a self-hosted install](/get-started/on-prem/operating.md)