Skip to content

CONCEPT Cited by 1 source

Blue/green deployment

Definition

Blue/green deployment is a deployment strategy where two identical production-capable environments (named "blue" and "green") are maintained, and a new release is applied to the idle environment while the live environment continues serving traffic. Once the new environment is validated, a switchover redirects all traffic to the new environment, which becomes the new live production. The old environment remains available (as a rollback candidate or for review) until explicitly torn down. The names "blue" and "green" are arbitrary colour labels — they alternate roles on every release, so the same environment can be "blue" in release N and "green" in release N+1.

Canonical verbatim framing (Morrison II, 2024):

"When new features are released as part of a blue/green strategy, you'd typically have two identical environments that can both act as production. As an example, 'blue' is the current production environment, and 'green' is used to identify the other environment that will become production once the new artifacts are released. When the artifacts are deployed to the green environment, you'd reroute traffic to it and make green your new production environment. The traffic alternates back and forth between the two environments as they trade their production status based on the latest release of the code."

(Source: sources/2026-04-21-planetscale-planetscale-branching-vs-amazon-aurora-bluegreen-deployments.)

Application-tier vs database-tier

Blue/green originated at the application-tier: two identical stateless server fleets, load balancer flips traffic between them, rollback is trivially "flip back to blue." Stateless fleets make the primitive cheap; duplication is only during the release window and both sides serve from the same database.

Applying blue/green at the database tier (the Aurora-family pattern) introduces constraints that don't exist at the application tier:

  • State synchronisation — both environments need data. Aurora uses [[concepts/copy-on-write-storage- fork|copy-on-write storage clone]] for the initial fork + binlog replication for ongoing sync.
  • Schema-change envelope bounded by the sync mechanism — schema changes on green must binlog-replicate cleanly for the replication to keep blue and green in sync during the green-side lifetime.
  • Switchover is disruptive — writes must be stopped + final drain + replica catch-up + resource rename; not the "flip a load balancer" primitive of application-tier blue/green.
  • Post-switchover cost — blue side remains running (billable); not symmetric teardown.
  • Reversibility trade-off — once writes land on green, blue is stale; reverting means losing green-side writes (Aurora's explicit limitation).

Seen in

  • sources/2026-04-21-planetscale-planetscale-branching-vs-amazon-aurora-bluegreen-deployments — Brian Morrison II (PlanetScale, 2024-02-02). Canonical wiki introduction of blue/green deployment as a generic deployment strategy + its database-tier instance on Amazon Aurora. Canonicalises the scripted switchover lifecycle verbatim: "Amazon will run the environments through a series of guardrails, which ensure that the changes made are compatible and that no long-running operations are being run against the blue environment. Once that's done, Amazon will perform the following actions: Stop new writes and drop all connections to the database. Wait for any final writes and replication operations to execute. Switch blue to read-only. Rename the resources in both environments so that the green environment's resources adopt the original names of the blue environment's resources." Canonical use cases enumerated: minor schema changes (add-columns-at-end, indexes), MySQL version upgrades, instance-class scaling. Contrasted against PlanetScale's database branching
  • rolling upgrades as the alternative architecture.
Last updated · 378 distilled / 1,213 read