Most small teams we talk to assume blue-green belongs to companies with a platform group. It's an expensive-sounding idea: duplicated infrastructure, orchestration, someone paid to keep it alive.
For most modern applications, blue-green is a five-step sequence you can run on any container PaaS that supports revisions and traffic splitting. The expensive part was never the infrastructure. The expensive part is the discipline of not skipping steps when you're in a hurry.
It's worth being specific about what you're buying, because "zero downtime" is usually the least valuable part.
Without this pattern, a bad deploy costs four things: the minutes the service is broken; the minutes, sometimes many, spent deciding whether to roll back; rebuilding the previous artifact under pressure, which is when you discover it isn't where you thought; and the erosion of a team that learns deploying is dangerous and therefore deploys less, which makes every deploy bigger and more dangerous. That last one does the real damage.
What blue-green buys you isn't primarily uptime. It's removing the hard decision from the worst possible moment.
1. Deploy with no traffic. The new version comes up as a revision serving 0%. It's alive, booted, dependencies resolved. You've already eliminated an entire family of failures (bad environment variables, migrations that don't run, a binary that won't start) before a single user touches them.
2. Test against a stable URL. Every revision is reachable at its own address. Smoke tests run against it: critical paths, not the full suite. You're testing this artifact in this environment, which is exactly what no CI run can do for you.
3. Capture the rollback target before promoting. This is the step people skip and the one holding up everything else. Before a drop of traffic moves, you record which revision you'd return to. One written line, before the change.
The reason is psychological, not technical. At 11pm with errors climbing, nobody is in shape to work out which version was the good one. Between a two-minute incident and a forty-minute one there's usually just that line.
4. Promote. Shift traffic to the new revision. With traffic splitting you can do it gradually, but the mechanism matters less than the fact that the previous revision stays alive and available throughout. Rolling back isn't rebuilding. It's repointing.
5. Monitor after the change. The deploy doesn't end when traffic hits 100%. You watch behavior for a defined window afterward. Plenty of real failures only surface under real traffic: cold caches, queries that slow under concurrency, a data case no test had.
Building Hura, our technical assessment platform, we ran into a failure mode this pattern didn't cover, and one we now consider the most dangerous of all: product behavior can change without the code changing.
Hura generates technical tests from a job description and evaluates answers with two models in parallel. That means what a recruiter sees depends on three things, only one of which is code: the code, the prompt, and the model version. Tuning one instruction to improve a case can degrade ten others. A provider updates a model and your output shifts without you touching anything.
Our answer was to treat the prompt and the model version as part of the deployed artifact rather than as loose configuration:
Prompts are versioned in the repo and travel with the revision. Changing a prompt is a deploy, with its spec, its PR and its review, not an edit in an admin panel.
Model versions are pinned explicitly. No pointing at an alias that moves on its own. If the provider ships something new, it arrives through a deploy somebody decided on.
The rollback target covers all three. Returning to the previous revision has to return the previous prompt and the previous model too. A rollback that only recovers code leaves you with the same broken behavior and the disorienting sense that reverting did nothing.
Smoke tests against the revision URL evaluate real outputs, using a small fixed set of reference cases. We don't compare literal text, we compare properties: that the generated test covers the role's criteria, that scores land in range, that the two models don't contradict each other more than expected.
That fourth point is what makes step 2 worth so much. The revision with no traffic is the only place you can see what the new system actually produces, with the real configuration, before a customer does.
It's tempting to read the above as a configuration. It isn't. The five steps are easy; what's hard is that none of them gets skipped under pressure, and pressure shows up precisely when they matter most.
The degraded version we've seen in a lot of teams, and the easy one to slide into, looks like this: deploy straight to production, test in production with users acting as your smoke suite, and go looking for a rollback only once something breaks. Each of those shortcuts saves two minutes and hands out an hour at random.
So we treat them as an objective checklist with the same phase-gate logic we use everywhere else: step not done, no advance. It isn't a judgment about whoever is deploying. It's a list.
This is the part that generates the most argument when we describe it, and we think it's the most important thing in this article.
"Done" doesn't mean "the code is written". In our explicit definition, it means:
it's in production,
smoke tests passed,
traffic is at 100%,
monitoring is clean,
and the associated spec or bug is closed.
Everything short of that is work in progress, however pretty the merged PR looks. A definition of done that stops at merge quietly transfers deploy risk to the next person, usually at the worst moment.
The trade-off, said plainly: this isn't free and it doesn't cure everything. It does cost a few minutes per deploy, paid even on the 95% that didn't need it. More importantly, blue-green solves application state, not data state. If a deploy includes a destructive schema migration, the old revision can be perfectly alive and still useless to you. That's why we separate data changes from code changes and give migrations their own reversal plan, and why any database change sits on our list of irreversible steps requiring explicit human approval.
Blue-green doesn't need a platform team; it needs you to respect the order. Deploy with no traffic, test against that revision's own URL, write down your rollback target before you promote, promote, then watch. If your product has model-driven features, add one more rule: the prompt and the model version are part of the artifact, and your rollback has to return all three. A behavior change with no code change is the incident nobody knows how to diagnose.
About Aztia. We're a software development firm. We build Hura, our technical assessment platform (huraapp.com), holding ourselves to the same process we describe in this series. More at aztia.co.
Thirty minutes, no pitch. Tell us what you're building.
Talk to us →