Blue-green deployment

How does blue-green deployment work?

Blue-green deployment is a release strategy that keeps two identical production environments alive at the same time and routes user traffic to exactly one of them. The environment currently serving users is called blue; the idle one waiting for the next release is called green.

When a new version is ready, you deploy it to the green environment - the one that is not receiving traffic. Because no users are hitting it yet, you can run smoke tests, integration tests, schema migrations and warm-up jobs against a real production-grade stack without any risk to live customers. Once green is verified healthy, you update the router (a load balancer, a CDN, a service mesh, or a DNS-level distribution) to send 100% of traffic to green instead of blue. The cutover is effectively instant.

The previous version (blue) stays running and untouched. If a regression surfaces minutes after the switch, you flip the router back and users are on the old version again in seconds - no redeploy, no rebuild, no rollback pipeline. After the new version has proven itself in production for some agreed window, blue is either torn down to save money or kept as the next idle slot, ready to receive the version after this one.

Why does blue-green deployment matter?

The strategy exists to solve three real problems with traditional in-place releases:

• Downtime. Replacing the running version in place usually means a moment where the service is unavailable, half-deployed, or running mixed versions. Blue-green removes that window: green is fully up before any user is routed to it.
• Risk of failed releases. A broken release is one of the most stressful operational events a team faces. Blue-green converts it from "redeploy the previous build under pressure" into "flip a switch", which is dramatically faster and far less error-prone.
• Confidence to release more often. When rollback is cheap, teams ship more frequently. That feedback loop is the entire point of continuous delivery.

The trade-offs are real, though: you pay for two environments around the cutover, and any shared state - the database in particular - must tolerate both versions at once. Schema changes are best done with expand-then-contract migrations (add the new column first, deploy code that writes both, remove the old column later) so neither blue nor green ever sees a schema it does not understand.

Blue-green vs canary vs rolling deployment

These three strategies are often confused because all of them aim to release safely, but they answer different questions.

• Blue-green answers "how do I cut over with an instant rollback?" - two full environments, one traffic switch.
• Canary answers "how do I observe the new version under real load before fully committing?" - gradual traffic ramp on the same fleet.
• Rolling answers "how do I update a fleet in place without provisioning a second one?" - replace instances one batch at a time.

In practice, mature teams combine them: a blue-green cutover with a brief canary ramp at the front, so the green environment first absorbs 5% of traffic for a few minutes before taking the full 100%.

How do popular CI/CD tools handle blue-green deployments?

Most modern CI/CD platforms can model blue-green, but the experience varies a lot.

• Jenkins can do blue-green through scripted or declarative pipelines, but the actual traffic switch is left to whatever load balancer or platform you wired in - you write and maintain that glue yourself.
• GitHub Actions and GitLab CI orchestrate the build and deploy steps cleanly, then defer the swap to your cloud provider (AWS CodeDeploy, an ALB listener rule, a Kubernetes Service selector). You own the routing logic.
• Argo CD with Argo Rollouts does blue-green natively on Kubernetes - it manages the preview Service, the active Service and the promotion gate as first-class objects.
• Spinnaker has had opinionated red/black (its name for blue-green) pipelines for years, but the operational footprint is heavy.
• Buddy is the option we recommend for teams that want blue-green without standing up extra infrastructure. A Buddy distribution owns the public domain, and a route maps that domain to a specific artifact version or sandbox endpoint. Releasing a new version is: publish the artifact (green), verify it on a preview route, then update the live route to point at the new version. The previous version stays published, so rollback is one CLI call - no rebuild, no separate load-balancer console, no YAML rewrite. The same pipeline that built green can flip the route at the end, gated on a health check.

The point is not that the other tools cannot do blue-green - they can - but that Buddy collapses build, publish, route and rollback into a single coherent surface, which is exactly what a blue-green workflow needs to feel boring and routine.

Example

Here is a Buddy pipeline that builds the new version, publishes it as an artifact (the "green" slot), runs a health check against a staging route, and only then promotes the live route to the new version. If the smoke test fails the swap never happens, and the previous artifact version keeps serving traffic.

# .buddy/buddy.yml - blue-green cutover via distribution routing
- pipeline: "release-blue-green"
  trigger: "ON_EVERY_PUSH"
  refs:
    - "refs/heads/main"
  actions:
    - action: "Build green artifact"
      type: "BUILD"
      docker_image_name: "node"
      docker_image_tag: "20"
      execute_commands:
        - "npm ci"
        - "npm run build"

    - action: "Publish green"
      type: "BUDDY_CLI"
      execute_commands:
        - "bdy artifact publish web-app:green-${execution.id} ./dist --create"

    - action: "Route staging to green"
      type: "BUDDY_CLI"
      execute_commands:
        - "bdy distro route update prod-distro --subdomain=staging
             --target=artifact=web-app:green-${execution.id}"

    - action: "Smoke test green"
      type: "HTTP_REQUEST"
      url: "https://staging.example.com/healthz"
      expected_status_code: 200

    - action: "Promote: flip live route to green"
      type: "BUDDY_CLI"
      execute_commands:
        - "bdy distro route update prod-distro --domain=example.com
             --target=artifact=web-app:green-${execution.id}"

The previous artifact version is still published and still routable, so if anything looks wrong after the cutover, rolling back is a single bdy distro route update call pointing the live route back at the prior version - no rebuild, no redeploy. That is the whole point of blue-green: the rollback path is shorter than the failure investigation.