Deployment

Deployment is the way a new version of the software reaches users. A canary sends a small share of traffic, such as 5 percent, to the new version first. If its health checks fail, the balancer moves that traffic back to the stable version.

Play a level

See it on the board

The same traffic runs on two boards. The simulator measured both when this page was built.

Board to show
HTTP/2HTTP/2HTTP/2SQLUsersUsersLoad balanc…1 vCPU · 1 GBNode API2 vCPU · 2 GBPostgres2 vCPU · 4 GB
HTTP/2HTTP/2HTTP/2SQLUsersUsersLoad balanc…Node APIPostgres
New build on every instance at once: misses a goal
HTTP/2HTTP/2HTTP/2HTTP/2SQLSQLUsersUsersLoad balanc…1 vCPU · 1 GBNode API2 vCPU · 2 GBPostgres2 vCPU · 4 GBNode API1.5 vCPU · 1.5 GB
HTTP/2HTTP/2HTTP/2HTTP/2SQLSQLUsersUsersLoad balanc…Node APIPostgresNode API
Canary beside a stable version, 1 s health checks: meets the goals
See it on the board
Measure Goal New build on every instance at once Canary beside a stable version, 1 s health checks
Error rate (Members) under 0.1% 50% Fail 0% Pass
Error rate (Beta) under 2% 50% Fail 1.2% Pass
p99 latency (Members) under 200 ms 29 ms Pass 29 ms Pass
Monthly cost 28 USD/mo 34 USD/mo

Key numbers

Default part values from the catalog and the price table. The simulator uses the same values.
NumberValue
Start a new API server90 s
Time between health checks, default5 s
Failed checks before a server goes out3 checks
Price of one more API service4 USD/mo
A canary before the whole fleetTap to change the deployment method

Canary · 5% of requests fail for 15 seconds · 750 failed requests

How it works

Most outages start with a change. A new build, a new configuration or a new schema reaches production and fails in a way that the tests did not show. The deployment method decides how many users see that failure, and for how long.

A deployment that replaces every server at once is fast, but a bad build then stops everything. A rolling deployment replaces a few servers at a time, so capacity stays up, but a slow failure can still reach all of them. A blue-green deployment starts a full second copy and moves all traffic at once. The rollback is fast, but the cost is double while both copies run.

A canary sends a small share of real traffic to the new version and keeps the rest on the stable one. Health checks and error metrics compare the two. If the canary fails, an automatic rollback removes it in seconds, before a person sees the alert. If it holds, its share grows step by step.

Each method needs the old version to stay ready. A schema change must work with both versions during the change, and a new server needs time to start, often more than a minute.

In the levels you keep a stable version beside the canary and let health checks remove a bad build fast.