Canary deployment

Canary deployment made simple with feature flags

A canary deployment sends new code to a small slice of real traffic before everyone gets it, so problems surface while they are cheap. You can build that with clusters and load balancers, or you can do it with one feature flag.

No card required

01 · The idea

Let 1% find the bug 100% would have found

The name comes from the canary in the coal mine: a small, early warning that saves everyone else. In release engineering, the canary is the first slice of users on the new code path. If error rates, latency or conversion move the wrong way, you stop; only a sliver of traffic ever saw the problem.

A canary release is not a staging environment. Staging tells you the code runs; a canary tells you what it does to real users, real data shapes and real traffic patterns, the things staging never reproduces.

Canary at 1%, live

canary cohort 1 of 100 users

One user in a hundred exercises the new path. Your dashboards see it; your customer base does not.

02 · Two ways to build it

Infrastructure canary vs feature-flag canary

Dimension	Infra canary (2nd deployment)	Flag canary (Toggled)
Setup	Second deployment target, LB rules, service mesh config	One flag around the new code path
Granularity	By request or instance percentage	By user, plan, region or percentage, sticky
Who can run one	Platform / DevOps	Any engineer with flag access
Scope	Whole binary or service version	One feature at a time, many in parallel
Abort	Shift traffic back, drain instances	Kill switch, ~3s, no infra change
User stickiness	Extra work (session affinity)	Built in via consistent hashing
Cost	Duplicate capacity while canarying	None beyond the flag

The two compose: teams with infra canaries still flag individual features, because a version-level canary cannot isolate which change hurt. If you have neither, the flag canary is the one you can adopt this week.

03 · The playbook

A canary release in five moves

Flag the path

Wrap the new code in checkout.new-flow and deploy dark.

Pick the canary

Internal team first, then 1% of everyone. Sticky by user id.

Watch the guardrails

Error rate, p95 latency, conversion. Give it a real soak, hours not minutes.

Widen or stop

Healthy: step up the ladder. Unhealthy: kill switch, everyone back on old in seconds.

Finish the job

At 100%, delete the flag and the old path. A canary is not a permanent state.

The step-up ladder and hold times get their own page: gradual rollout, 1% before 100%. The abort button gets one too: the feature flag kill switch. And if you want the canary to answer "did it help" as well as "did it break", attach a metric per A/B testing on flags.

Early access · launching soon

Run your first canary without touching infra

Toggled is in early access. Join the list, get flat team pricing at launch, and canary the next release with one flag.

No card required · your data stays yours

Keep exploring