> ## 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. # Self-hosted control plane > Run the whole platform inside your own cluster — what it includes, the three deployment tiers, and what it requires of your environment. Some organizations cannot run an agent platform as a service, because the platform holds credentials to their production systems. Running the control plane yourself answers that: the Komodor Agentic Operation Platform (KAOP) sits inside your cluster, against your database, behind your identity provider. [Deployment methods](/get-started/deployment-methods) covers *what* runs where; this page covers how self-hosting is delivered, what gets installed, and what your environment must provide. ## Three tiers They differ in who operates the install and whether it may reach the internet — not in the software, which is one chart in every case. | Tier | Who runs it | Network | What it answers | | ------------------ | ------------------------------ | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | **Dedicated** | Komodor, in your cloud account | Outbound allowed | Isolation from other tenants. Komodor still holds the keys. | | **Self-installed** | You | Outbound allowed | Your cluster, your database, your identity provider. Komodor holds nothing. | | **Air-gapped** | You | No egress at all | Environments with no route to the internet. Arranged per agreement, because the image mirror and offline updates are ongoing work on both sides. | Most organizations asking for on-prem want the middle tier, and that is what the rest of these pages describe. ## What gets installed One namespace, one Helm release: | Component | What it is | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | | **Control plane** | The API, the authorization engine, the run engine, and the workflow engine — as a single deployment | | **UI** | The console | | **Valkey** | Queues and cache. Standalone by default; Sentinel is available for redundancy | | **Model gateway** | The path from an agent to a model, including your own OpenAI-compatible endpoint | | **Postgres** *(optional)* | A bundled single-pod database for evaluation. Production means bringing your own — see [Install](/get-started/on-prem/install) | The control plane ships as one process rather than the split components Komodor runs in its own environment. Fewer moving parts is most of the value of installing it yourself. ## What your environment provides | Requirement | Detail | | ------------------------ | -------------------------------------------------------------------------------------------------- | | **Kubernetes** | With an ingress controller and an available storage class. The preflight check confirms all three. | | **Postgres** | Your own is the supported production path. A bundled one exists for evaluation. | | **An identity provider** | OIDC. SAML-only providers are not supported. | | **A model endpoint** | Any OpenAI-compatible endpoint, including one you run in-cluster. | | **TLS** | Ingress host and certificate secret are yours; the chart takes them as values. | | **A registry** | Your own mirror, set through a single registry-prefix value. | Nothing in the chart requires a specific cloud, a cloud-specific storage class, or any of Komodor's own delivery tooling. Stock values produce a working release. ## What it does not include * **Hosted agents.** The path where Komodor builds and runs an agent for you stays with the hosted product. Self-hosted installs deploy their own agents. * **A highly available bundled database.** The bundled Postgres is deliberately a single pod for evaluation. Production HA means your own database, with your own backup and restore. * **An operator or OpenShift certification.** * **SAML-only identity.** ## Where your data goes Nothing leaves your cluster. Agents run in your clusters and dial the in-cluster control plane; runs, evidence, credentials and audit records are written to your database. The only outbound traffic is what you configure — your model endpoint, and the integrations you connect. ## Next steps Preflight, values, and the first sign-in. Upgrades, secrets, and the database decision. Where agents run, which is a separate choice from where the control plane runs. What the control plane does, hosted or not. ## Related topics - [Operating a self-hosted install](/get-started/on-prem/operating.md) - [Deployment methods](/get-started/deployment-methods.md) - [Data flow](/get-started/architecture/data-flow.md) - [Control plane](/get-started/architecture/control-plane.md) - [Use specialized agents](/manage-your-agents/build/use-specialized-agents.md)