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.

It also needs a database of its own. With the bundled cluster off, you provision it and name its connection Secret in edisyl.auth.database.secretName.

An external Redis has to be configured completely

With redis.enabled: false, the render fails until config.redisHost, config.redisPort, config.redisUser, REDIS_PASSWORD, LATTICE_REDIS_URL and — while the bundled job runner is on — INNGEST_REDIS_URI are set. The chart never generates the password, and the API refuses to start on a blank one, so a passwordless Redis needs a password. Under external-secrets the chart cannot see your store, so the store has to carry them. Your Redis also needs RediSearch and RedisJSON; a plain managed Redis will not work.

Behind Sentinel, the job runner’s client cannot authenticate to the Sentinels or use TLS with them — see Using your own infrastructure.

Keys the chart stops rendering stay in the live Secret

Helm’s three-way merge leaves a key it no longer renders in place, so a key that moved to config.* is still in its Secret after helm upgrade. The ConfigMap is read last, so a stale key never overrides a value it carries, but it still applies where the ConfigMap leaves a blank optional key out. Remove the stale keys after the upgrade — never delete the Secrets themselves; see Upgrading.

Bundled MinIO is single-node

Enabled, MinIO works, with the chart deriving the provider, URL, path-style addressing and root credentials. But one replica with no redundancy is not a production object store. For anything beyond an evaluation, turn it off and set config.objectStorage* — see Using your own infrastructure.

The LLM gateway runs one replica

Applies in every install that runs the bundled gateway, which is every install not pointed at another deployment’s through bifrost.external.url. 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. Every inference call goes through it, so that window is an inference outage. Anything else that moves the pod costs the same window; on a Karpenter fleet, set bifrost.podAnnotations: { karpenter.sh/do-not-disrupt: "true" } so consolidation leaves it alone.

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.