Deploying

One environment. Merging to main deploys it.

merge → build → GHCR → image-tag bump PR in appsterisk-gitops → auto-merge → ArgoCD syncs

Migrations run in an initContainer before the application starts. The seed does not and is applied by hand.

Where it runs

A single Hetzner cx23 in Nuremberg — 2 vCPU, 4 GB — running k3s and its own ArgoCD. Nuremberg is not arbitrary: it is the closest region to the Neon project the databases live in.

nbg1 also carries the whole system, so the node is a single point of failure and is stated as one rather than described as a cluster.

Why its own ArgoCD

The Webhookr controller could have synced this cluster. It would have put one product's control plane in the other's deploy path — a dependency a carve-out could not sever by moving a repository.

Rolling back

Change the image tag in appsterisk-gitops back to a previous SHA and merge. ArgoCD syncs.

A rollback across a migration is not a rollback. Migrations are applied forward and the initContainer will not undo one; an older image against a newer schema is undefined behaviour. If a migration is involved, roll forward with a corrective migration instead.

What to check when a deploy looks wrong

A run that fails with no log at all did not start. That is a permission the caller was never granted, not a syntax error — GitHub's message points at the workflow file and is misleading.

A green deploy that changed nothing is possible: the image-tag bump uses a selector, and against a manifest without an images: block it matches nothing, writes an empty list and exits zero. Check that the tag in gitops actually moved.

The pod running an older SHA than main usually means a bump PR is sitting unmerged, not that the deploy failed.