Shipping zero-downtime deployments
Customer storefronts don't get a maintenance window. Here's how we ship changes to Badger Commerce while it stays fully online.
Rolling updates by default
Every service runs as a Kubernetes Deployment with a rolling update strategy. New pods are started and must report healthy before old pods are removed, so there's always a pool of ready instances serving traffic. A bad image never takes the old one offline, because the old one isn't retired until the new one proves itself.
Health gating with probes
Rolling updates are only safe if the cluster genuinely knows when a pod is ready. We rely on three signals:
- Readiness probes — a pod receives traffic only once it reports ready, so requests are never routed to a process that's still warming up.
- Liveness probes — a wedged process is restarted automatically.
- Startup probes — slower-booting services get the grace they need before liveness checks begin.
Combined with sensible resource requests, this means traffic only ever lands on instances that can actually serve it.
Deployment is a Git change
Because the platform is GitOps-driven, a deployment isn't a special imperative action — it's a change to an image tag in the repository. New application builds are promoted by updating the tag for the relevant environment; Flux notices, applies the rolling update, and records the change in Git history. Development and production are separate overlays, so a change can be proven in development before it's promoted.
Rollback is just the previous commit
When something does go wrong, recovery is fast and boring — the best kind. Reverting the Git change rolls the platform back to the previous known-good state automatically, the same way it rolled forward. There's no scramble to remember "what did we change?" because the answer is in the commit. Our monitoring stack usually tells us we need to before a customer would notice.