Deployment Strategies 2026: Blue-Green vs Canary vs Rolling

There is no single best deployment strategy. Rolling updates are the default for stateless services because they cost nothing extra; blue-green is the right choice when you need an instant, whole-system rollback; canary releases are worth their complexity when a bad release would be expensive and you have metrics good enough to catch it. Feature flags, shadow traffic and recreate cover the remaining cases. Each strategy differs on four axes: how many versions run at once, who sees the new one and when, how fast you can go back, and what it costs. This guide covers each strategy, how to run it on Kubernetes, serverless and databases, and how to pick one.

Rolling deployment: the default for stateless services

A rolling update replaces old instances with new ones in batches. At any point some instances run v1 and some run v2, and the load balancer sends traffic to both. Capacity stays close to normal, and no extra environment is needed.

In Kubernetes this is the built-in behavior of a Deployment. Two fields control it: maxSurge (how many extra pods may exist above the desired count) and maxUnavailable (how many pods may be down during the update). Both default to 25%.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
spec:
  replicas: 6
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # one extra pod at a time
      maxUnavailable: 0    # never drop below 6 ready pods
  template:
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: checkout
          image: registry.example.com/checkout:2.4.0
          readinessProbe:
            httpGet: { path: /healthz/ready, port: 8080 }
          lifecycle:
            preStop:
              exec: { command: ["sleep", "5"] }

Three things make or break a rolling update:

• Readiness probes. The new pod must not receive traffic until it can serve. Without a probe, Kubernetes considers the container ready the moment it starts.
• Graceful shutdown. The preStop sleep gives the endpoint controller time to remove the pod from the Service before SIGTERM arrives. Your process must then finish in-flight requests within terminationGracePeriodSeconds.
• Compatibility. v1 and v2 serve requests side by side, so API contracts, cache formats, message schemas and database schema must all work for both.

Rolling has two weaknesses: there is no gate between batches other than "pods became ready", so a version that starts fine but returns wrong answers rolls all the way out; and rollback (kubectl rollout undo) is another rolling update, so it takes as long as the rollout did.

Blue-green deployment: instant cutover, instant rollback

Blue-green keeps two complete environments. Blue serves production; green receives the new version, gets tested against real dependencies, and then takes all traffic in one switch. Blue stays up until you are confident, then becomes the target for the next release.

The switch itself is the key design decision:

Switch mechanism	Cutover time	Notes
Load balancer target group / Ingress backend	Seconds	Preferred; precise and reversible
Service mesh route (Istio, Linkerd)	Seconds	Also allows a canary step before the full switch
Kubernetes Service selector change	Seconds	Simple; works without extra tooling
DNS record	Minutes to hours	Depends on TTL and client caching; avoid for rollback

On Kubernetes, the minimal version is two Deployments (checkout-blue, checkout-green) and one Service whose selector you patch from version: blue to version: green. Argo Rollouts formalizes this with strategy.blueGreen, which manages an active and a preview Service, runs optional analysis against the preview, and can wait for a manual promotion (autoPromotionEnabled: false).

Blue-green fits well when:

• You need a whole-system rollback measured in seconds, for example in payments, ticketing or regulated workloads with explicit change windows.
• Several services must switch together and a mixed v1/v2 state is not acceptable.
• You want to run a full integration or load test against production infrastructure before exposing users.

The costs: double capacity during the cutover, the same database rules as rolling (the switch can be reversed, so green must not write data blue cannot read), and draining of long-lived connections on the old side.

Canary releases and progressive delivery

A canary sends a small share of traffic, often 1–5%, to the new version, watches metrics for a fixed window, then increases the share step by step. If a metric breaches its threshold at any step, traffic goes back to the stable version automatically. The rollout is driven by evidence rather than by the clock.

Native Kubernetes cannot do this. A Deployment with two replicas of v2 and eighteen of v1 gives roughly 10% traffic, but you cannot pin the split, and it moves as pods reschedule. Precise splitting needs one of:

• Argo Rollouts, a Deployment replacement with a strategy.canary block, a traffic-routing plugin for your Ingress, Gateway API or mesh, and AnalysisTemplate resources that query Prometheus, Datadog, New Relic, CloudWatch or a web hook.
• Flagger, an operator that leaves your Deployment untouched, creates a primary copy, and manipulates mesh or Ingress weights based on metric checks defined in a Canary resource.
• A mesh or Gateway API HTTPRoute with weighted backends, driven by your own pipeline. Works, but you are rebuilding the analysis loop yourself.

A canary step definition with Argo Rollouts looks like this:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: checkout
spec:
  replicas: 10
  strategy:
    canary:
      canaryService: checkout-canary
      stableService: checkout-stable
      trafficRouting:
        plugins:
          argoproj-labs/gatewayAPI:
            httpRoute: checkout-route
      steps:
        - setWeight: 5
        - pause: { duration: 10m }
        - analysis:
            templates:
              - templateName: error-rate-and-latency
        - setWeight: 25
        - pause: { duration: 15m }
        - setWeight: 50
        - pause: {}            # manual promotion from here

The AnalysisTemplate referenced above is where the real work is. A good one compares the canary against the stable version over the same window, not against a static number: error rate, p95 or p99 latency, and one business signal such as checkout success. Set the failure condition on the delta, and require the metric to stay bad for more than one interval before aborting, or normal noise will fail healthy releases.

Canary is the most powerful strategy and the most demanding. You need metric labels that distinguish canary from stable, enough traffic that a 5% slice produces meaningful numbers, and sticky routing if a user hitting both versions would break something. For low-traffic services, use blue-green or flags instead.

Feature flags, dark launches, shadow traffic and recreate

Feature flags separate deploy from release. The code ships dark, behind a flag that is off, and the team enables it for internal users, then a percentage, then a segment such as a plan or a country. The infrastructure runs one version; the flag decides behavior. This is the only strategy that targets users rather than requests, and it lets several teams ship independent changes in one deploy. The cost is code hygiene: flags must be removed once fully on, and a flag evaluated on a hot path needs a local cache, never a network call. See feature flags, deployment strategies and A/B testing for the operational details.

Shadow (traffic mirroring) sends a copy of real requests to the new version and discards its responses. Users see only the stable version; the team compares logs, latency and error rates between the two. Istio and Envoy support mirroring natively; Argo Rollouts exposes it as setMirrorRoute. Shadowing is excellent for validating a rewrite or a new dependency under real load, but only for reads. Mirrored writes would duplicate side effects, so the shadow version needs its own data store or an idempotent stub for anything that mutates state.

Recreate stops every old instance and then starts the new ones. It always has downtime, so it is only right when two versions genuinely cannot coexist: a singleton scheduler, a service holding an exclusive lock, an incompatible cache format with no migration path. In Kubernetes, set strategy.type: Recreate. Do this deliberately, with a maintenance window, not by accident.

Deployment strategies on serverless and edge platforms

Serverless platforms give you rolling and canary for free, but with narrower controls.

• AWS Lambda uses function versions and aliases. An alias can route a weighted share of invocations to a second version, and CodeDeploy automates the ramp with Linear (fixed increments every N minutes), Canary (one small step, then all) and AllAtOnce configurations, rolling back on CloudWatch alarms. Provisioned concurrency on the new version avoids cold starts during the shift.
• Cloud Run keeps every revision and lets you split traffic between revisions by percentage or tag. Deploying with --no-traffic then shifting gradually is a canary; shifting 100% at once with the old revision kept warm is blue-green.
• Azure Functions uses deployment slots with a swap, which is blue-green by construction.
• Edge platforms (Cloudflare Workers, Vercel, Netlify) deploy atomically and keep previous deployments addressable, so rollback is a pointer change; Cloudflare Workers also supports a percentage split between two versions.

The recurring constraint on serverless is state: any datastore shared by two versions faces the same compatibility rules as on Kubernetes. The platform only solves the compute side.

Databases: the part every strategy shares

Every zero-downtime strategy runs two application versions against one database for some period, and every rollback runs the old version against a schema the new version may have changed. Both facts lead to the same rule: schema changes must be backward compatible for at least one release.

The pattern is expand-then-contract:

1. Expand. Add the new column, table or index. Keep the old one. Deploy code that writes to both and reads from the old.
2. Migrate. Backfill in batches, with a job that can be paused and resumed.
3. Switch reads. Deploy code that reads from the new shape but still writes both, so a rollback still has valid data.
4. Contract. Once the previous release can no longer be rolled back to, stop writing the old shape and drop it.

Run the migration as a separate step, before the application rollout, never inside a pod's startup. On Kubernetes that is a Job triggered by the pipeline or an Argo Rollouts pre-step; on serverless it is a pipeline stage. Long-running ALTER TABLE statements that take locks belong in tooling such as pg-osc, gh-ost or Postgres concurrent index builds. The full playbook, including how to handle destructive changes and multi-service ownership, is in database migration strategies for production environments.

Strategy choice affects the database in one way: the longer two versions coexist, the longer the dual-write window stays open. A ten-minute rolling update tolerates a short window; a canary held at 50% for a day, or a flag ramped over weeks, needs the expand state to be a stable, tested configuration.

Comparison table and decision checklist

Criterion	Rolling	Blue-green	Canary	Feature flags	Shadow	Recreate
Downtime	None with probes	None	None	None	None (users untouched)	Yes
Rollback speed	Minutes (reverse rollout)	Seconds (switch back)	Seconds (weight to 0)	Instant (flag off)	N/A, nothing exposed	Minutes plus downtime
Extra infra cost	One batch (maxSurge)	Full duplicate during cutover	A few replicas	None	Duplicate for mirrored share	None
Traffic control	By instance count only	All or nothing	Precise percentage or header	By user, segment, plan	Copy, not routing	None
Complexity	Low; built into every orchestrator	Medium; two environments and a switch	High; needs router, metrics, analysis	Medium; flag service and cleanup discipline	High; needs mesh and write isolation	Very low
DB compatibility	Two versions coexist briefly	Two versions coexist; switch reversible	Two versions coexist for hours or days	One version; flag paths must both be compatible	Shadow must not write	Single version; migrations can be breaking
Best for	Stateless services, frequent small releases	Coordinated cutovers, strict rollback SLAs, regulated windows	High-traffic, high-cost-of-failure services with good metrics	Product-level releases, gradual exposure by segment, A/B tests	Rewrites, new dependencies, performance validation	Singletons, incompatible upgrades, scheduled maintenance

Decision checklist

Work through these in order. The first "yes" usually settles it.

• Can the old and new versions not run at the same time? Recreate, in a maintenance window. Then fix the design so this is the last time.
• Do you need to test against production infrastructure before any user sees the change, or roll back an entire system in seconds? Blue-green.
• Is a bad release expensive, and do you have per-version metrics and enough traffic for a small slice to be meaningful? Canary, with automated analysis. Without those metrics, a canary is a slow rolling update with extra steps.
• Is the risk in a product behavior rather than in the binary, or do you need to release to specific customers first? Feature flags, on top of whichever infrastructure strategy you already use.
• Are you replacing a service or a dependency and want proof it behaves under real load before it matters? Shadow traffic for reads, then one of the above for the real cutover.
• None of the above? Rolling. It is the default for a reason.

Two cross-cutting checks apply regardless of the answer:

• Every strategy except recreate requires expand-then-contract migrations. If the team cannot commit to that, no traffic-routing trick will make the release safe.
• Readiness probes, graceful shutdown and a rollback that has actually been rehearsed matter more than the strategy label. A well-run rolling update beats a canary nobody has ever aborted. Wire the rollback into the same CI/CD pipeline that does the deploy, and practice it in staging.
• Strategies combine. Rolling plus flags is the usual SaaS setup; blue-green with a canary step keeps the fast rollback and cuts blast radius; shadow followed by canary is the safest path when migrating legacy systems piece by piece. Different services on the same Kubernetes cluster can use different strategies.

Recommendation

Start with rolling updates and tight probes for every stateless service; they are free and cover most releases. Add feature flags as soon as more than one team ships to the same service, so deploy and release stop being the same event. Move a service to canary only when it has real traffic, per-version metrics, and a failure cost that justifies running Argo Rollouts or Flagger; otherwise a canary gives you ceremony without evidence. Reserve blue-green for coordinated cutovers and systems with a hard rollback requirement, and reserve recreate for the rare singleton. Whatever you choose, treat the database as the binding constraint: expand-then-contract migrations are what make any of these strategies safe to reverse. At Arvucore we usually recommend fixing migrations and rollback rehearsal first, and picking a traffic strategy second.