Verifying the install

helm install returning successfully means the manifests applied. It does not mean the platform works. These checks cover the failures that surface later.

Run everything below against your install namespace.

Is the pgvector extension actually there

This is the one that bites. The chart creates the extension in the database cluster’s post-init SQL, so an image without pgvector fails during bootstrap — but the symptom is a cluster that never becomes ready, which looks like a storage or scheduling problem.

PG=$(kubectl -n edisyl get cluster.postgresql.cnpg.io \
  -o jsonpath='{.items[0].metadata.name}')

kubectl -n edisyl exec "${PG}-1" -- \
  psql -U postgres -d edisyl -tAc \
  "select 1 from pg_extension where extname='vector'"

1 means the extension is installed in that database. Empty output means it is not — most often because cnpg.imageName does not include pgvector. To tell the two apart, check whether the image offers it at all:

kubectl -n edisyl exec "${PG}-1" -- \
  psql -U postgres -tAc \
  "select 1 from pg_available_extensions where name='vector'"

Empty there means the image is wrong — see Prerequisites. Available but not installed means bootstrap did not complete.

Did the migrations run

Check the effect, not the job. Hook jobs carry a delete-on-success policy, so a successful migration deletes its own Job. Its absence proves nothing either way. The migration bookkeeping table is the durable evidence:

kubectl -n edisyl exec "${PG}-1" -- \
  psql -U postgres -d edisyl -tAc \
  "select count(*) from _prisma_migrations where finished_at is not null"

A count above zero means migrations applied. Zero, or an error that the table does not exist, means the migration never completed.

Are the workloads ready

kubectl -n edisyl get pods -o wide
kubectl -n edisyl get statefulset,deployment,job
kubectl -n edisyl get cluster.postgresql.cnpg.io
kubectl -n edisyl get pvc

Every application pod should be Running and ready. PVCs should be Bound — Pending almost always means cnpg.storageClass names a class that does not exist on this cluster, or that its class has no provisioner behind it.

Check that the images were actually pulled, not merely requested. .spec.containers[].image reads the same on a pod in ImagePullBackOff; imageID only exists once a layer landed:

kubectl -n edisyl get pods \
  -o jsonpath='{range .items[*]}{range .status.containerStatuses[*]}{.image}{" "}{.imageID}{"\n"}{end}{end}' \
  | sort -u

If you issued certificates through cert-manager, all of them should be ready — otherwise the browser gets a default self-signed certificate on a host that otherwise works:

kubectl -n edisyl get certificate

Run the chart’s own test

The chart ships a test that covers what a probe from your laptop cannot. From inside the cluster it hits the auth service’s internal health endpoint, then its public one through the ingress, then compares the JWKS documents served on both paths. If they differ, the public hostname is fronting some other auth service and tokens minted on one path will not verify on the other.

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

Two things about it. It is a helm.sh/hook: test, so an install never runs it and Argo CD never will — this command is the only thing that fires it. And --logs is not optional: without it Helm prints the phase and nothing else, while the diagnosis is in the log.

Inspecting a failed install

Hook jobs are where install-ordering failures show up. If one is still present, it has not succeeded:

for j in auth-prep-db edisyl-migrate edisyl-seed edisyl-sync-content; do
  kubectl -n edisyl get job "$j" >/dev/null 2>&1 || continue
  echo "=== $j ==="
  kubectl -n edisyl get job "$j" \
    -o custom-columns='STATUS:.status.conditions[0].type,COMPLETIONS:.status.succeeded,FAILED:.status.failed' \
    --no-headers
  kubectl -n edisyl logs "job/$j" --tail=30 2>/dev/null || echo "  (no logs yet)"
done

Common states and what they mean:

What you see	Cause
Pod in CreateContainerConfigError	Waiting on a Secret that does not exist yet — kubectl describe pod names it
Pod in ImagePullBackOff	Registry credentials expired or images.registry is wrong
api/worker crash-looping early on	Expected during a first install, until migrations finish
api/worker crash-looping after hooks finish	Real failure — check the pod logs
PVCs Pending	cnpg.storageClass does not match a class on this cluster

Can you reach it

kubectl -n edisyl get ingress

Each ingress should have an address. If they are blank, either no ingress controller is running or it has not adopted these resources. That the DNS for your domain resolves to that address is yours to arrange — the chart only declares the hostnames.

Then sign in at the web application — edisyl.<your domain>, unless you set an explicit host — using an address from bootstrap.adminEmails. See Authentication.