Install

Installing the Komodor Agentic Operation Platform (KAOP) is one Helm release into one namespace. The work is not the install — it is deciding a handful of values about your database, your identity provider, and your model endpoint. This page walks the whole sequence, and calls out the two choices that are hard to change afterwards.

Before you start

Run the preflight. It checks the Kubernetes version, that a storage class is available, and that an ingress controller is present:

kubectl preflight oci://ghcr.io/komodorio/charts/agentops-preflight:1.0.0

Fix anything it reports before installing. A failed preflight is a install that comes up half-working, which is harder to diagnose than one that never started.

The database decision

Make this one first, because moving afterwards means a migration.

Your own Postgres (production)
Bundled Postgres (evaluation)

The supported production path. You keep backup, restore, and high availability where your team already runs them.Point the chart at a secret holding the connection string:

postgresql:
  enabled: false
externalDatabase:
  existingSecret: agentops-db
  existingSecretKey: connection-string

The chart creates the database and role through an install hook, so the credential you supply needs rights to do that.

Today this path needs three Postgres extensions loaded through shared_preload_libraries — pgmq, pg_durable and pg_cron — which no managed Postgres offering will run. Until that requirement is removed, a managed database is not a working target, and the bundled option below is the one that installs. Check the release notes for your version before committing to a managed instance.

A single-pod StatefulSet on the upstream postgres image, for evaluation and small installs:

postgresql:
  enabled: true
  storageClass: your-storage-class

It is one pod. There is no replication, no failover, and no backup — by design, because a bundled database that looked highly available would inherit expectations nobody can meet inside a cluster Komodor cannot see. Use it to evaluate, then move to your own.

The values you will write

A working install is roughly nine lines. Everything else has a usable default.

# Where your images come from
image:
  registry: registry.internal.example.com/komodor

# How the console is reached
ingress:
  host: kaop.example.com
  tlsSecret: kaop-tls
  className: nginx

# Who may sign in
oidc:
  issuer: https://id.example.com
  clientId: kaop

# Where models are called
modelGateway:
  openaiCompatible:
    baseUrl: http://vllm.models.svc.cluster.local:8000/v1

# Storage for the components that need it
global:
  storageClass: your-storage-class

# Plus the database block from above

Every secret the chart needs can be supplied as an existingSecret, so nothing sensitive has to live in your values file. The internal secrets the platform generates for itself are created at install time.

helm install agentops oci://ghcr.io/komodorio/charts/agentops \
  --version 1.0.0 \
  --namespace agentops --create-namespace \
  -f values.yaml

The chart carries every dependency vendored inside it, so rendering never reaches out to a chart repository. Database migrations apply as the control plane starts — there is no separate migration step to run. Each release publishes a signed release.yaml listing the image digests it contains. Mirror from that rather than from tags if you need to prove what you deployed.

Open the console

Go to the ingress host you configured. You are redirected to your identity provider.

Authenticate as yourself. No local account is created and no password is set anywhere in the platform.

You become the owner

The first person to sign in to a new workspace is granted the owner role automatically, so the install cannot end up with nobody able to administer it. Everyone after you arrives as a member.

Invite the rest, and set roles

See Roles & permissions.

Verify it works

Deploy one agent and run the connectivity check on it. It uses no model, no tools, and no integrations — it proves only that the control plane can reach the worker and that runs and transcripts are flowing. Then run the sample run, which exercises your model endpoint for real. Both are described in Use cases. In this order they localize a broken install quickly: connectivity failing is deployment or networking, connectivity passing while the sample run fails is the model endpoint.

Next steps

Operating it

Upgrades, secret rotation, and what not to regenerate.

Deploy an agent

Getting the first worker running against your control plane.

Onboarding

The checklist a new workspace walks.

Use cases

The two built-in checks that prove an agent works.

Get started

Deployment methods

Install

Before you start

The database decision

The values you will write

Install

Verify it works

Next steps

Operating it

Deploy an agent

Onboarding

Use cases

​Before you start

​The database decision

​The values you will write

​Install

​First sign-in

​Verify it works

​Next steps

Operating it

Deploy an agent

Onboarding

Use cases

Before you start

The database decision

The values you will write

Install

First sign-in

Verify it works

Next steps