Installing

The configurator prints this whole sequence for your answers, with your namespace and file names filled in. This page explains it; the two run in the same order.

Before you install

With a values file prepared, run these from the directory that holds it:

1. Keep the credentials out of git. Add secrets.local.yaml and auth-keys.local.yaml to .gitignore before writing either.
2. Log in to the chart registry through the edisyl-registry profile — see Registry access. The token lasts 12 hours.
3. Mint the auth signing keys into auth-keys.local.yaml — see Secrets and signing keys.
4. Mint the gateway’s runtime key into secrets.local.yaml. One sk-bf- value fills both places the file names it — see The LLM gateway. With a gateway you don’t run, fill in that gateway’s credentials instead.
5. Install what the chart does not: the CloudNativePG operator if you bundle Postgres, an NGINX ingress controller, and cert-manager with a letsencrypt-prod ClusterIssuer — see Prerequisites.
6. Create the namespace, labelled baseline if you bundle MinIO (see Namespaces), and create the image pull secret in it unless the chart seeds it from values — see Registry access.

Install

helm upgrade --install edisyl \
  oci://944311261080.dkr.ecr.us-east-1.amazonaws.com/edisyl-charts/edisyl-helm \
  --version <chart-version> \
  -n edisyl \
  -f edisyl.values.yaml \
  -f secrets.local.yaml \
  -f auth-keys.local.yaml \
  --timeout 20m

upgrade --install rather than install, so re-running after a failure works instead of stopping on “cannot reuse a name that is still in use”. If you started the configurator from an existing values file, it also writes edisyl.overrides.yaml; pass it straight after edisyl.values.yaml. Under secrets.provider: external-secrets there are no .local.yaml files to pass. If the chart seeds the pull secret from values, add the --set-string images.pullSecretAuth.password=… flag from Registry access.

Chart versions are listed on the version matrix. The packaged chart carries its subchart dependencies, so there is no helm repo add or helm dependency build step.

The flags that matter

Always pin --version. Without it Helm resolves the newest chart in the registry, so two installs weeks apart silently differ.

Pass every -f file. Configuration and credentials are kept apart — see Secrets and signing keys. Later files win where they name the same key. A bare install with no values file fails by design. The chart stops with a message naming the missing key rather than installing something that cannot boot.

Use --timeout 20m, not the 5-minute default. The post-install hooks wait on the database to provision a volume and publish its generated secrets, which routinely takes longer than five minutes on a first install with a cold image pull. At the default you get Error: failed post-install: timed out on an install that was actually working.

Do not use --atomic or --wait on the first install. The migration is a post-install hook, and both flags make Helm wait for the application deployments before the post-install hooks run — so they block on the migration that has not happened yet. --atomic then rolls the release back, which deletes the database cluster and its PersistentVolumeClaims. Every later upgrade is different: use --wait --wait-for-jobs there — see Upgrading.

Namespaces

Every object the chart renders lands in the namespace you pass to -n, with one exception: the bundled Inngest subchart reads its own inngest.namespace.name value, which defaults to edisyl. Installing into a differently-named namespace without overriding it puts Inngest somewhere its consumers and their Secrets are not. See Configuration.

Create the namespace before installing rather than with --create-namespace: the pull secret has to be in it first, and bundled MinIO needs it labelled baseline — see Pod Security Standards:

kubectl create namespace edisyl
kubectl label namespace edisyl pod-security.kubernetes.io/enforce=baseline --overwrite   # bundled MinIO only

What a first install looks like

For the first few minutes, api and worker crash-loop. This is expected and self-heals. They start before the migration hook has finished setting up the database they ship alongside, fail to connect, and are restarted until it exists.

What should happen, in order:

1. The database cluster is created and provisions a volume.
2. Hook jobs run the migration, seed, and content sync.
3. The application pods stop crash-looping and become ready.
4. The edisyl-idp-reconcile Job registers your identity provider, retrying until the database, the owner organization and the auth service exist.

If pods are still crash-looping after the hooks have finished, something is actually wrong — go to Verifying the install.

The install returns before the apps are ready

The install comes back once the hooks have run, while the Deployments are still rolling. Wait for them rather than assuming. The last line applies when the gateway runs in this install:

for d in api edisyl worker lattice auth; do
  kubectl -n edisyl rollout status "deploy/$d" --timeout=10m
done
kubectl -n edisyl rollout status statefulset/edisyl-bifrost --timeout=10m

Wait for the identity provider to register

The edisyl-idp-reconcile Job registers the IdP you declared under deploymentIdp. It is a plain Job, not a hook, so a failure does not fail the install — and until it succeeds, nobody can sign in. It retries until the migrations and the auth service are up. Wait for it, then read its log; the last lines name the provider id, and nothing needs copying back:

kubectl -n edisyl wait --for=condition=complete job -l app=edisyl-idp-reconcile --timeout=15m
kubectl -n edisyl logs -l app=edisyl-idp-reconcile --tail=20

See Authentication.

Run the chart’s test, then sign in

The chart’s own test compares the JWKS on the internal and public auth paths, which a probe from your laptop cannot — see Verifying the install:

helm test edisyl -n edisyl --logs --timeout 5m

Then sign in at https://edisyl.<your-domain>/login with an address from bootstrap.adminEmails. Start from the app, never from the IdP — see Signing in.

Watching it happen

kubectl -n edisyl get pods -w

In another shell, the hook jobs:

kubectl -n edisyl get jobs

A hook pod stuck in CreateContainerConfigError is waiting on a Secret that does not exist yet, and the pod’s event message names which one:

kubectl -n edisyl describe pod -l job-name=edisyl-migrate

Uninstalling

helm uninstall edisyl -n edisyl

This destroys a bundled database

If you run your own Postgres, helm uninstall cannot reach it and this does not apply. With the bundled database it does:

Uninstalling deletes the CloudNativePG Cluster. The chart puts no helm.sh/resource-policy: keep on it, so its PersistentVolumeClaims go with it — and if your StorageClass reclaims with Delete, which is the common default, the underlying volumes are gone too.

Take a backup first. Do not treat uninstall as a way to reset a release while keeping data.

Some subchart volumes claimed by StatefulSets do survive, so a namespace may still hold PVCs afterwards. Check before assuming either way:

kubectl -n edisyl get pvc