Blue-green deployment keeps two production environments that are as identical as possible. One serves users while you deploy and test the new release in the other, then a router switch moves traffic across. If something breaks, you switch back. It gives near-zero downtime and fast rollback, but shared databases complicate it.
How does it work step by step?
Martin Fowler's write-up of the pattern describes it directly. Blue is live. You do final testing in green. When green works, you point the router at it, and blue goes idle. If anything goes wrong, you point the router back at blue.
The switch can happen at a load balancer, a DNS record with a short lifetime, or a service mesh route. Each has different cut-over speed and caching behaviour, so test the one you actually use. DNS caching in particular can leave some clients on the old side for a while.
Fowler also notes the awkward part: transactions that occur while green is live and blue is idle. Depending on design you may feed both environments, or put the application in read-only mode before cut-over.
What does it do for security?
It helps in several ways, and misses in others.
Patching with a clean slate. The new environment is built from scratch from a known image, so long-lived drift and leftover tools disappear. Immutable builds are easier to verify against a signed artifact.
Safe testing. You can run smoke tests and security checks against the real production configuration before any user touches it.
Fast rollback for a bad release. If a release introduces a flaw you notice quickly, rollback takes minutes.
What it does not do. It cannot roll back data that a vulnerable release already exposed or corrupted. If green leaked records for ten minutes, switching to blue does not return them. Rollback fixes availability and behaviour, not damage.
Where does it get hard?
Databases. Both environments usually share one database, so schema changes must work for both versions of the code. The common method is expand and contract: first add new columns or tables in a backward compatible way, deploy, then remove the old structures in a later release.
Sessions and caches. If sessions live in memory, users are logged out at cut-over. Shared session stores avoid this, and also need protection.
Secrets and certificates. Two environments mean two sets of credentials and configuration. Keep them in a secret store, scope them per environment, and make sure the idle side does not hold stale, over-privileged credentials.
Cost. You run double capacity at least briefly.
Idle environment exposure. An unpatched idle environment that is still reachable becomes a forgotten target. Restrict access to it and rebuild it after each release.
A constructed example
A team releases version 42 to green. Smoke tests pass, so they shift traffic. Fifteen minutes later error rates climb, and they switch back to blue within a minute. The release added a column and dropped none, so blue still works with the new schema. A different team that renamed a column in the same step would have broken blue as well, which is why they split the change over two releases.
How to check or apply this
- Make both environments from the same infrastructure code and image build, and compare them in a check before each cut-over.
- Run automated smoke, integration and security tests against the idle side before switching.
- Use backward compatible database changes only. Split renames and removals across releases.
- Decide how sessions, queues and caches behave at cut-over, and test it.
- Practice the rollback path regularly so it is not first used in an incident.
- Limit network access to the idle environment and give it its own scoped secrets.
- Keep the previous environment for a defined window, then rebuild or destroy it.
- Log which version served traffic at each time, for audit and incident work.
Quick check
Is blue-green the same as a canary release?
No. Blue-green switches all traffic at once between two environments. A canary sends a small share of traffic to the new version first and grows it gradually.
Does rolling back remove a vulnerability that was already exploited?
It removes the vulnerable code from service, but not any data taken or changes made while it ran. Investigate and rotate credentials as needed.
Sources
Last reviewed: 18 October 2026.
