> ## 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.

# Operating a self-hosted install

> Upgrades, the one secret you must never regenerate, moving off the bundled database, and what to send support.

Running the Komodor Agentic Operation Platform (KAOP) yourself means you own its upgrades, its
secrets, and its database. This page covers the routine parts, and the two irreversible ones — the
encryption key, and moving off the bundled database.

## Upgrading

```bash theme={null}
helm upgrade agentops oci://ghcr.io/komodorio/charts/agentops \
  --version 1.1.0 \
  --namespace agentops \
  -f values.yaml
```

The chart version **is** the product version, so the chart you install names exactly what you get.
Migrations apply as the new control plane starts.

Read the release notes before a minor upgrade. The one class of change worth checking for is a
database requirement — the extensions the platform needs are the difference between a managed
Postgres working and not working.

## The secret you must never regenerate

Internal secrets are generated at install time and then left alone: the chart looks for an existing
value before creating one, so an upgrade does not mint new ones.

<Warning>
  **`AGENTOPS_ENCRYPTION_KEY` protects every stored credential.** If it is regenerated or lost, every
  integration credential and provider key in the database becomes unreadable — not rotated, not
  recoverable. Back it up the way you back up a root key, and never let a redeploy generate a new one.
</Warning>

Everything else is rotatable in the ordinary way. If you supply secrets as `existingSecret`, rotation
is a change to your secret followed by a restart, and nothing in the chart has to know.

## Moving off the bundled database

The bundled Postgres is a single pod with no replication and no backup. Treat it as an evaluation
step, not a first version of production.

Moving is a database migration, not a values change:

<Steps>
  <Step title="Stand up your own Postgres">
    With the extensions the release notes require, and your own backup and restore in place.
  </Step>

  <Step title="Quiet the platform">
    Scale the control plane to zero so nothing writes while you copy.
  </Step>

  <Step title="Dump and restore">
    A conventional `pg_dump` and restore into the new instance.
  </Step>

  <Step title="Repoint and bring it back">
    Set <code>postgresql.enabled: false</code>, point <code>externalDatabase.existingSecret</code> at
    your connection string, and upgrade the release.
  </Step>
</Steps>

Doing this while the platform is running loses whatever was written after the dump — runs, evidence,
audit records. The scale-to-zero step is the whole safety of the procedure.

## Sizing and the components with state

| Component         | State              | Notes                                                                               |
| ----------------- | ------------------ | ----------------------------------------------------------------------------------- |
| **Control plane** | none               | Scale horizontally. Migrations run at startup, so a rollout is safe.                |
| **UI**            | none               | Static; one replica is usually enough.                                              |
| **Valkey**        | queues and cache   | Standalone by default. Enable Sentinel if losing the queue mid-run is unacceptable. |
| **Postgres**      | everything durable | Your own, in production. This is what to back up.                                   |

Runs, evidence, transcripts and audit records all live in Postgres. If you back up one thing, that is
it.

## When something is wrong

Collect a support bundle before opening a ticket. It gathers the component state, versions, and
recent logs from the namespace:

```bash theme={null}
kubectl support-bundle oci://ghcr.io/komodorio/charts/agentops-support-bundle:1.0.0 \
  --namespace agentops
```

Include the release version, whether the database is bundled or your own, and what changed most
recently. Self-hosted problems are usually environmental — a storage class, an ingress annotation, an
identity provider's claim mapping — and the bundle answers those faster than a description does.

## Next steps

<CardGroup cols={2}>
  <Card title="Install" href="/get-started/on-prem/install">
    The sequence, and the database decision.
  </Card>

  <Card title="Secrets & credential handling" href="/security-and-governance/architecture-considerations/secrets-credential-handling">
    What the encryption key protects, and how credentials reach a run.
  </Card>

  <Card title="Troubleshooting" href="/reference/troubleshooting">
    Failure modes that are not specific to self-hosting.
  </Card>

  <Card title="Support" href="/reference/support">
    How to reach the Komodor team.
  </Card>
</CardGroup>


## Related topics

- [Self-hosted control plane](/get-started/on-prem/overview.md)
- [Install](/get-started/on-prem/install.md)
- [Marketplace](/manage-your-agents/build/marketplace.md)
- [Kubernetes RCA](/manage-your-agents/build/catalog/kubernetes-rca.md)
- [Use specialized agents](/manage-your-agents/build/use-specialized-agents.md)