Zum Inhalt springen
Sprache wählen:Deutsch

Install on Kubernetes with Helm

Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.

The chart runs the same image as Compose, with the same environment variables.

  • Secrets first. The chart never writes a secret: you create the database logins’ secret (and, with the bundled Postgres, its superuser’s) before installing, and reference the optional ones (the keys, S3, the backup’s credentials, SMTP, the metrics token) by name in the values.
  • Postgres: a bundled StatefulSet on the same pinned pgvector image as Compose, for a quick start, or your own PostgreSQL 18. With a database superuser’s (or a provider admin’s) secret, a Job creates Kept’s roles and extensions; without one, run the managed-Postgres SQL yourself.
  • Migrations run in a hook Job with the owner login, so the new version never serves before its migrations are applied. With a backup target configured, that Job first takes a pre-upgrade snapshot. With the bundled Postgres the first install’s Job runs after the install, so don’t pass --wait to that first helm install.
  • Files stored locally sit on a ReadWriteOnce volume, so the Deployment uses the Recreate strategy: an upgrade stops the old pod before the new one starts. Rolling updates come only with S3 file storage and the keys in a secret.
  • Backups run in the worker, never in a CronJob: the same nightly job as in Compose, configured in Admin → Backups or locked by the chart’s values.
  • Split web and worker Deployments are an option; the worker is a single replica.
  • Volumes are kept on helm uninstall; delete the claims yourself to remove the data.
  • helm test asks the running Kept for /readyz and /version.

The chart’s version is Kept’s version: release 1.0.1 publishes chart 1.0.1. It is published as a signed OCI artifact beside the image with each release; see verifying a release.