Blue-Green Deployment State Machine

DevOps & CI/CD · state diagram · CC-BY-4.0

State diagram for a blue-green deployment with smoke tests and a canary ramp-up — the standard zero-downtime release pattern with safe rollback at every step.

Source: https://martinfowler.com/bliki/BlueGreenDeployment.html
Curated by Archigram editorial
devops deployment blue-green canary release-engineering

Mermaid source

stateDiagram-v2
    [*] --> BlueLive
    BlueLive: Blue Live (100% traffic)\nGreen idle

    BlueLive --> DeployingGreen: New release
    DeployingGreen: Deploying to Green\nRun smoke tests

    DeployingGreen --> SmokeFailed: Tests fail
    SmokeFailed --> BlueLive: Rollback

    DeployingGreen --> CanaryShift: Tests pass
    CanaryShift: Shift 5% traffic to Green\nMonitor SLOs

    CanaryShift --> CanaryFailed: SLO breach
    CanaryFailed --> BlueLive: Drain Green

    CanaryShift --> RampUp: SLOs healthy
    RampUp: Shift 25 -> 50 -> 100%
    RampUp --> GreenLive: Full cutover

    GreenLive: Green Live (100% traffic)\nBlue idle (warm)
    GreenLive --> [*]: Promote Green\nReplace Blue on next release

What this diagram shows

A blue-green deployment state machine where Blue serves 100% of traffic until a new release deploys to Green. The machine progresses through Deploying (smoke tests), CanaryShift (5% traffic for SLO monitoring), and RampUp (25 → 50 → 100%) before fully cutting over. Each state has a safe rollback path back to BlueLive if smoke tests fail or SLOs degrade. Once cutover completes, Green becomes the live environment and the (former) Blue stays warm as the next-release rollback target.

When to use it

Use blue-green when you need zero-downtime releases and a fast, predictable rollback path. It is the right pattern for stateless services behind a load balancer where you can pay for double the capacity during the cutover window. The added canary step (this diagram) gives you the safety of progressive delivery while keeping the operational simplicity of two named environments.

How to adapt it for your project

If you cannot afford double capacity, switch to a rolling deployment instead — you trade rollback speed for cost. For stateful services, keep the blue-green shape but add a database migration phase where both versions can read/write the schema (expand → contract migrations). For Kubernetes, the same state machine maps to two Deployments behind one Service with label selectors, or you can use Argo Rollouts which implements this directly. Add a manual approval gate between CanaryShift and RampUp for higher-risk releases.

Key concepts

Related diagrams