Member-only story
Preview Environments Aren’t a Kubernetes Problem. They’re a Database Problem
A per-PR preview build on Kubernetes and GitHub Actions: database strategies ranked by cost, a TTL reaper for orphaned namespaces, and prod-safe secrets.
Giving every pull request its own URL looks like a Kubernetes project: a namespace, a wildcard DNS record, a wildcard certificate. That part is the easy half.
The bill arrives with the parts the cluster can’t solve for you: where each preview gets its data, which secrets it can see, and what deletes it when nobody remembers to.
The mental model: a preview is a namespace
Most preview designs start from the same picture: CI builds an image, Helm installs it into a fresh namespace, and a hostname points at it. Close the PR, delete the namespace, done.
It’s a reasonable picture, because Kubernetes makes that half easy: namespaces are cheap, and one wildcard record and certificate cover every PR you’ll ever open.
But the picture assumes everything a preview needs lives inside the namespace, and that the close event always runs. Neither is true by default.
