Leadership wants "zero downtime." The team provisions two identical stacks — double VPS, double Redis, double Postgres "for safety." Bill doubles, migration never tested in parallel. Launch day, DNS switch reveals green still points at old env vars: five-minute rollback, but monthly double cost remains.
Blue-green deployment reduces cutover risk; it does not automatically justify doubling every resource. Discipline means doubling what switches fast — app, workers — and investing in compatible data migrations rather than blindly cloning Postgres.
What must be doubled — and what can be shared
| Component | Often doubled | Often shared |
|---|---|---|
| Stateless app / API | ✅ | — |
| Queue workers | ✅ or temp scale | — |
| Redis cache | ⚠️ by invalidation | sometimes |
| PostgreSQL | ⚠️ expensive | compatible migrations |
| Object storage | — | ✅ immutable versions |
Shared DB, dual app pattern relies on backward-compatible migrations: nullable new column, no brutal rename. Rollback means repointing traffic, not restoring database.
Doubling Postgres "just in case" without migration strategy = max cost, illusory rollback.
Traffic switch and rollback window
Deploy green first and run internal tests — X-Deploy: green header or dedicated hostname. Verify one hundred percent of green instances pass readiness. Then switch load balancer, Ingress, or DNS, progressively if possible. Watch application errors and keep blue idle for a few hours.
Rollback reverses flow — instant if shared state stays compatible. If green wrote incompatible format, application rollback needs database restore, often overnight.
Cost, autoscaling, and short windows
Blue need not run twenty-four-seven at production capacity: it can stay smaller off-release, scaled before deploy. Some teams keep green hot only on release day.
Kubernetes: two Deployments or Argo Rollouts with preview Service. VPS: two Compose dirs, Traefik weighting. Optimize duration of doubling, not just using the pattern.
Session data and sticky sessions
In-memory sessions on blue: users switched to green lose session. Externalize sessions — Redis, for example — before adopting blue-green. Same issue for local uploads on blue disk: shared object storage required.
Rehearsal
Run monthly drill: fake deploy, staging switch, timed rollback. Document who triggers switch and abort criteria. Unrehearsed blue-green stays theoretical the day production shakes.
The peak: double stack, easy rollback — myth
Reduce risk without blindly doubling cost = double stateless, invest in expand/contract migrations, keep blue as temporary reserve.
Decide and move forward without blind spots
First map what is stateless versus stateful in your architecture, then validate schema migrations stay compatible with both code versions. Test switch and rollback in staging before launch day. Size blue stack for release window only, not permanent duplication. Compare load balancers, VPS, and Kubernetes via directory and compare tool, and browse guides for release engineering. Success metric: staging rollback under five minutes without DB restore — else revisit pattern.
Frequently asked questions
Does blue-green always double the bill?
No, if only stateless app is doubled and DB shared with backward-compatible migrations. Duplicating entire stack, database included, nearly doubles everything — without guaranteeing simple rollback.
How do I switch traffic cleanly?
Full health check on green stack, then load balancer or DNS switch — progressively if possible. Keep blue stack warm a few hours for quick rollback.
What about schema migrations?
Apply expand/contract for old and new code compatibility before switch. Otherwise green won't start or blue breaks after rollback.
Blue-green vs rolling update?
Blue-green: instant switch and fast rollback, temporary surplus cost. Rolling update: gradual progress, less overhead, slower rollback. Choose by SLA and budget.
Smart blue-green doubles what switches fast — not what is expensive to sync.