A percentage-based canary needs a load balancer that supports weighting; a header-based one needs an nginx map and works anywhere.
map $http_x_canary $upstream_pool {
default app_stable;
"1" app_canary;
}
map $cookie_canary $upstream_pool_c {
default $upstream_pool;
"1" app_canary;
}
location / { proxy_pass http://$upstream_pool_c; }
Deciding on a header means the team can opt in deliberately before anyone else sees the release, which is a different and often better thing than a random percentage — a canary nobody is watching tells you nothing. The cookie fallback keeps a session on the same version, which matters as soon as the release changes anything stateful. Promoting is repointing the default, and rolling back is the same operation.