Deploying a new software release means routing live request traffic away from a proven stable version (v1) and onto a new version (v2) without breaking things for real users. This simulation shows a load balancer spraying request packets across a server fleet under three classic rollout strategies, so you can see how each one shapes the "blast radius" of a bad release.
Canary releases are named after the "canary in a coal mine" — a small, expendable early warning system. Teams often automate the canary's error and latency thresholds so a bad release rolls itself back before a human even notices.
A load balancer routes live request traffic across a fleet of server instances while a software rollout proceeds under blue-green, canary, or rolling strategy rules, visualising how each approach trades speed, cost, and blast radius.
Blue-green keeps a full duplicate pool on standby and cuts traffic over instantly; canary shifts a growing percentage of live traffic onto the new version while most requests stay safe; rolling replaces instances in place, batch by batch.
Pick a strategy, then scrub the rollout progress slider or press auto-advance. Raise the new-version error rate to see how much traffic — and how many real requests — each strategy exposes to a broken release.
Many production canary pipelines automate the decision entirely: if error rate or latency crosses a threshold during the canary phase, the rollout aborts and rolls back before an on-call engineer is even paged.