Installing

With registry access configured, a values file prepared and your secrets minted:

1
helm install edisyl \
2
  oci://944311261080.dkr.ecr.us-east-1.amazonaws.com/edisyl-charts/edisyl-helm \
3
  --version <chart-version> \
4
  -n edisyl --create-namespace \
5
  -f edisyl.values.yaml \
6
  -f secrets.local.yaml \
7
  --timeout 20m

Chart versions are listed on the image 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 both -f files. 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. Both 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.

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-namespace creates the namespace if needed; omit it if you provision namespaces yourself, which you will want to do if you need specific Pod Security Standard labels.

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:

The database cluster is created and provisions a volume.
Hook jobs run the migration, seed, and content sync.
The application pods stop crash-looping and become ready.

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

helm install comes back once the hooks have run, while the Deployments are still rolling. Wait for them rather than assuming:

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

Then run the chart’s own test, which checks what a probe from your laptop cannot — see Verifying the install:

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

Watching it happen

1
kubectl -n edisyl get pods -w

In another shell, the hook jobs:

1
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:

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

Uninstalling

1
helm uninstall edisyl -n edisyl

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

1
kubectl -n edisyl get pvc

Was this page helpful?

Thanks for the feedback.