Known limitations

These are not edge cases. Read them before you install.

Argo CD rotates generated secrets on every sync

The chart generates secrets once and reuses them by looking up the existing Secret in the cluster. That lookup needs live cluster access. Argo CD normally renders with helm template against no cluster, so the lookup returns empty on every sync and every generated value is regenerated — ENCRYPTION_KEY, the signing keys, and the bundled datastore passwords.

A rotated ENCRYPTION_KEY orphans any data encrypted under the previous one.

Under Argo CD you must supply these values explicitly, through secrets.managed.*.data or secrets.provider: external-secrets, rather than relying on generation.

Inngest run history is not durable

The bundled Inngest subchart hardcodes its data volume to an emptyDir with no option for a persistent volume, so there is nowhere durable for the chart to point it.

Queue state and in-flight run state are durable — they live in the bundled Redis. But past events, completed runs, and step results do not survive an Inngest pod restart. If you need durable run history, supply your own PostgreSQL through inngest.inngest.postgres.uri.

The auth signing keys cannot be generated by the chart

GOTRUE_JWT_KEYS needs an EC keypair, which Helm cannot produce. Until you supply one, user sign-in fails with 401 Invalid or expired token — which reads as a credential problem rather than a missing key. See Authentication.

The LLM gateway runs one replica

Applies when bifrost.enabled is true. Bifrost’s open-source build keeps provider configuration, budgets and rate-limit counters per process and reads them from Postgres only at startup, so two replicas are two gateways that disagree about what a key has already spent (upstream).

The chart therefore runs a single-replica StatefulSet and exposes no replica count. A StatefulSet’s rolling update stops the old pod before starting the new one, which is what keeps an ordinary helm upgrade from ever running two — at the cost of a short window with no gateway on every upgrade. Nothing routes inference through it until you change LLM_GATEWAY_URL, so plan the cut-over with that window in mind.

The LLM gateway’s encryption key cannot be rotated

Every provider credential Bifrost stores is encrypted under BIFROST_ENCRYPTION_KEY, and Bifrost cannot re-encrypt them. Rotating the key orphans every stored credential and the providers have to be entered again.

The chart generates the key once and reads it back from the edisyl-bifrost-encryption Secret on later upgrades. Back that Secret up. And under Argo CD, supply it explicitly — see the first limitation on this page.

Bundled subcharts do not meet restricted Pod Security

The chart’s own pods do. The bundled third-party subcharts do not. Enabling one into a namespace that enforces restricted gets those pods rejected outright.

Label the namespace baseline, or exempt the workload through whatever mechanism your cluster provides.

--atomic on a first install can destroy your database

Applies when you run the bundled PostgreSQL (cnpg.enabled: true). With your own Postgres the rollback cannot reach it — but the install still deadlocks, so the advice below is the same either way.

On install, the migration is a post-install hook. --atomic and --wait make Helm wait for the application deployments first, so they block on a migration that has not run yet, time out, and roll back — and because the release created the database cluster, rolling back deletes it and its PersistentVolumeClaims.

Do not use --atomic or --wait on a first install. On upgrade the migration is a pre-upgrade hook and the deadlock does not apply, though --atomic still cannot undo a migration.

Uninstalling deletes the bundled database

Applies when you run the bundled PostgreSQL. helm uninstall removes the database cluster, and the chart sets no helm.sh/resource-policy: keep on it. Its volumes go with it, and with a Delete reclaim policy so does the underlying storage. Back up first.