Operate

Use these commands to operate a healthy install after Configure & Validate.

Note

Every command on this page expects a working kindo-cli installation and a kubectl context that points at the target cluster. Commands that use install-contract.yaml and environment-bindings.yaml read them from the current directory unless you pass --contract / --bindings explicitly.

CLI daily-drivers

Command	Purpose
kindo status	Show install state and live release versions
kindo doctor	Read-only diagnosis of a degraded install
kindo config edit	Edit the cluster secrets config (credentials, service overrides) in $EDITOR
kindo config apply	Regenerate the per-app Secrets from the secrets config and restart the affected services
kindo config validate --preflight	Check the schema and infrastructure connectivity
kindo config override list | set | unset	Manage per-service environment-variable overrides
kindo config override edit | diff | apply	Edit overrides, preview changes, and apply them to the cluster
kindo config helm-override list | set | unset	Manage Helm chart value overrides that persist across upgrades
kindo config helm-override edit | diff | apply	Edit, preview, and apply persistent Helm chart value overrides
kindo config backup	Export the install’s configuration and secrets to an encrypted bundle
kindo restore <bundle>	Restore an install from a backup bundle onto an empty cluster
kindo config log-level set | show | unset	Set the log level for the Kindo applications
kindo db list	List the Postgres databases
kindo db tunnel <database>	Open a port-forward tunnel to a database
kindo db prompt <database>	Open an interactive psql session over a tunnel
kindo db reset [database]	Drop all tables (destructive; resetting all databases requires two confirmations)
kindo integrations list	Show available and enabled MCP integrations
kindo integrations enable <name>	Enable an integration in the contract
kindo integrations disable <name>	Disable an integration in the contract
kindo integrations apply	Register and deploy enabled integrations
kindo integrations bootstrap	Re-run integration registration against the cluster
kindo integrations status	Show live integration status from the cluster
kindo uninstall all | applications | peripheries	Tear down a group of releases

Register and review models in the superadmin dashboard at https://superadmin.<domain>.

kindo status

Check install state:

kindo status

State is stored in the cluster, so any workstation with cluster access sees the same answer. The table has one row per install step. Anything other than completed on a fresh install means stop and investigate. After fixing the cause, resume from the failed step:

kindo install --resume

Below the table, a Superadmin: line shows ✓ bootstrapped, ✗ not bootstrapped, or ? unknown with the reason. If it reports ✗ not bootstrapped, run:

kindo install --step superadmin-bootstrap

Use kindo status --no-live to skip the live checks: the superadmin line and the live release/version table.

kindo config edit and kindo config apply

Use these commands to change the cluster secrets config and restart affected services:

1. Run the pre-change check. It checks the schema and connectivity to Postgres, Redis, RabbitMQ, and object storage:

   kindo config validate --preflight

2. Open the secrets config:

   kindo config edit

   This loads the kindo-secrets-config Secret from kindo-system, opens it as YAML in $EDITOR (or vi), and saves it back. It includes sensitive values. The command checks only that the result is valid YAML and a mapping; there is no schema validation, so a typo is saved as-is. Saving does not restart services.

3. Regenerate each app’s Secret and rolling-restart the affected deployments:

   kindo config apply

   To limit regeneration and restarts, pass a comma-separated list of app names with --only:

   kindo config apply --only api,next

   kindo config apply also accepts --context to select the cluster.

Service overrides win over the values Kindo generates. With an external secrets store, values in the store take precedence over the ones kindo config apply generates.

Apply configuration changes

kindo config edit edits the secrets config, and kindo config apply reads that config only. Choose the apply command for the setting you changed:

Change	Apply with
Secrets config or service overrides	kindo config apply or kindo config override apply <service>
Helm chart values	kindo config helm-override apply
Contract ingress: block	The next kindo upgrade
Contract SMTP settings or sandbox settings	The next kindo upgrade
Contract integrations:	kindo integrations apply
Reset every feature flag to the shipped defaults	kindo install --step post-install; reapply your flag changes afterward

kindo config override

Use service overrides to change environment variables, such as SUPERADMIN_API_KEY_TTL_DAYS or NEXT_PUBLIC_NANGO_CONNECT_URL. Overrides are stored under serviceOverrides.<service>.<KEY> in the secrets config and persist across upgrades. Service overrides win over the values Kindo generates.

# Set one or more environment variables
kindo config override set api SUPERADMIN_API_KEY_TTL_DAYS=30

# Apply the staged change and restart the service
kindo config override apply api

# Preview changes with values redacted
kindo config override diff api

# Edit all overrides or one service in $EDITOR
kindo config override edit
kindo config override edit api

# Remove an override and apply the change
kindo config override unset api SUPERADMIN_API_KEY_TTL_DAYS
kindo config override apply api

# Inspect staged overrides
kindo config override list
kindo config override list next --format=yaml

If the live Secret holds keys that no override set, apply stops for that service. Pass --force to apply anyway; those keys are kept.

With an external secrets store, kindo config override set, unset, edit, and apply refuse to run and change nothing. kindo config override list still runs and flags any leftover entries as inactive. kindo config apply leaves staged overrides out and warns about them.

Supply credentials through the external store. For non-secret chart settings, use kindo config helm-override, which works with an external store. To remove leftover serviceOverrides entries, open the raw secrets config with kindo config edit and delete them there.

kindo config helm-override

Use Helm overrides for chart settings such as replica counts, resources, autoscaling, log collection namespaces, telemetry retention, and envData.<KEY> values. Keep the Helm customizations reported by the upgrade plan here. Overrides are stored under helmValueOverrides in the cluster secrets config and re-applied on every install and upgrade. This command also works with an external secrets store. For which values to change, see Scaling and Tuning.

1. Stage the settings for a release:

   kindo config helm-override set api autoscaling.enabled=true autoscaling.minReplicas=2 resources.limits.memory=8Gi

2. Preview and apply the changes:

   kindo config helm-override diff api
   kindo config helm-override apply api

3. Review the stored overrides:

   kindo config helm-override list

4. To remove a setting, unset it and apply again:

   kindo config helm-override unset api autoscaling.minReplicas
   kindo config helm-override apply api

Use the Helm release name, such as api, next, task-worker-ts, litellm, otel-collector, clickhouse, hatchet, or unleash. All subcommands accept --kube-context.

Subcommand	Use
list [release] [--format yaml|json|table]	Show stored overrides for one release or all releases
set <release> PATH=VALUE...	Stage values using dot notation; use [N] for list elements, such as securityContext.capabilities.drop[0]=ALL
unset <release> PATH...	Remove staged overrides at the specified paths
diff [release]	Preview changes for one release or all releases
edit [release]	Open YAML in $EDITOR, using nested YAML or dotted paths
apply [release]	Push overrides to the live cluster; omit the release to apply every release with overrides

set validates each path against the chart and rejects paths the chart never reads. set and unset only stage changes; run apply to deploy them.

kindo config log-level

Set application logging to debug, info, warn, or error. The setting applies to api, task-worker-ts, next, credits, and litellm; LiteLLM receives the equivalent Python log level.

For a fresh install, set logLevel: in install-contract.yaml. On a running install, use:

kindo config log-level set debug
kindo config log-level show
kindo config log-level unset

set and unset accept --no-restart to update Secrets without restarting pods. All three commands accept --kube-context. unset --no-apply changes only the stored config.

Precedence is per-service override > global log level > the app’s default. To pin an individual service, set and apply its override:

kindo config override set api LOG_LEVEL=debug
kindo config override apply api
kindo config override set litellm LITELLM_LOG=DEBUG
kindo config override apply litellm

These overrides remain in effect when you set or unset the global level. If set or unset fails on one service, it continues with the others and exits non-zero. Fix the reported issue and re-run the command.

The same logger controls access logs: api and credits write them at info, so a global warn or error also suppresses their access logs. Pin a service to info with a per-service override to keep its access logs.

A log level set on a running install persists across kindo upgrade.

With an external secrets store, kindo config log-level set and unset refuse to run. Set LOG_LEVEL, or LITELLM_LOG for LiteLLM, in the app’s store entry instead; a value in the store takes precedence.

kindo doctor

Diagnose a degraded install:

kindo doctor

The command is read-only by default. It checks the secrets config, Helm releases stuck in a pending state, the external secrets store and External Secrets Operator when used, per-app Secrets, workload references to missing Secrets, and whether a superadmin exists. A missing superadmin is a warning.

To attempt repairs, run:

kindo doctor --fix

After confirmation, it rolls pending Helm releases back to their last deployed revision and recovers a missing or incomplete secrets config and missing per-app Secrets. If a release’s first install never completed, it leaves that release alone and prints the command to clear it. Other findings require manual resolution.

Flag	Use
--yes / -y	Skip confirmation prompts
--force with --fix	Restore even if required keys are missing
--context	Select the cluster context

The exit code is 0 for no findings or warnings only, and 1 when a critical finding is present. With --fix, exit code 1 means a critical finding remains after recovery.

kindo upgrade refuses to run while kindo doctor reports a critical finding. Run kindo doctor --fix or resolve the finding manually before upgrading.

kindo db

Use these database names with tunnel, prompt, and reset:

Database	Stores
main	Kindo application data
litellm	LiteLLM proxy and model catalog
hatchet	Background task data
nango	Integration connection data
unleash	Feature flags
openshell	Sandbox gateway state

Open a database tunnel on localhost:15432, or choose a port with --port. The command prints a ready-to-use psql URL. Press Ctrl+C to close the tunnel:

kindo db tunnel main

For an interactive psql session, run:

kindo db prompt litellm

kindo db reset drops every table, sequence, and enum type in the named database’s public schema. Use it only when you intend to discard that data. Resetting one database requires one confirmation; --all requires two:

kindo db reset hatchet
kindo db reset --all

After a reset:

1. Recreate the schema:

   kindo install --step migrations

2. Re-create your superadmin:

   kindo install --step superadmin-bootstrap

3. Restore feature flags:

   kindo install --step post-install

   This sets every flag to the shipped default. Reapply your flag changes afterward.

4. Register models again in the superadmin dashboard at https://superadmin.<domain>.

kindo integrations

Integrations are declared under integrations: in install-contract.yaml. Use the CLI to enable, disable, and deploy them:

# List available and enabled integrations
kindo integrations list

# Enable integrations and supply OAuth credentials when prompted
kindo integrations enable github slack

# Register and deploy enabled integrations
kindo integrations apply

# Re-run registration after a Nango reset
kindo integrations bootstrap

# Check live integration status
kindo integrations status

# Disable an integration and apply the change
kindo integrations disable slack
kindo integrations apply

Disabling an integration and running apply stops deploying it, but its Nango configuration and existing connections are retained. To fully remove an integration, also delete its auth instance in the Nango dashboard and re-run kindo integrations apply.

Back up and restore

Take a configuration backup and database snapshots before every upgrade.

1. From the install directory containing install-contract.yaml and environment-bindings.yaml, run:

   kindo config backup

   You can specify the files with --contract and --bindings. The encrypted bundle contains the secrets config, install-contract.yaml, environment-bindings.yaml, and the install version. Its default name is kindo-backup-<version>-<timestamp>.kindo-backup; use --output / -o to choose another path.

2. Supply a passphrase of at least 8 characters at the prompt, or through KINDO_BACKUP_PASSPHRASE.

3. Take Postgres snapshots at the same time. Store the bundle and passphrase separately, away from the cluster.

The backup refuses to proceed if the cluster config is missing keys needed for a full restore. Recover them with kindo doctor --fix first. --allow-incomplete overrides the check, but that bundle cannot fully restore the install.

To restore onto an empty cluster:

1. Restore the Postgres databases from the snapshots taken with the bundle.

2. Extract install-contract.yaml and environment-bindings.yaml:

   kindo config extract <bundle>

   This writes install-contract.yaml and environment-bindings.yaml. Edit the bindings if the restored databases have new endpoints.

3. Restore the install:

   kindo restore <bundle>

   The command checks that the cluster is empty, the bundle is complete, and the contract’s appVersion matches the bundle’s version. --force permits overwriting existing cluster state; --version overrides the version. Review the plan and confirm to run the standard install against the restored configuration. --yes skips confirmation.

4. Verify the restored install:

   kindo status
   kindo doctor

The bundle excludes Qdrant embeddings, ClickHouse telemetry, HyperDX dashboards, and the object-storage bucket. Restore these from their own backups if needed.

kindo uninstall

Choose the scope to remove. Each command asks for confirmation unless you pass --force:

# Remove applications and keep peripheries and databases
kindo uninstall applications

# Remove peripheries
kindo uninstall peripheries

# Remove releases and preserve PVCs and the secrets config
kindo uninstall all --keep-data

# Remove releases, secrets config, and all Kindo namespaces
kindo uninstall all --delete-namespaces

uninstall all removes releases in reverse install order. The kindo-secrets-config Secret and install state are preserved by default so you can reinstall against the same infrastructure with the same credentials. Pass --delete-namespaces to remove them too.

Where to go next

Scaling and TuningAdjust replicas, resources, and storage as usage grows.

UpgradePreview and apply an upgrade, recover from an interrupted upgrade, and roll back.