Blue-Green vs Canary vs Rolling Deployment in .NET: Which Zero-Downtime Strategy Should Your Team Use?
Pushing a new version of your ASP.NET Core API to production without dropping a single request is not a luxury reserved for hyperscale companies — it is table stakes for any team shipping to users who expect continuous availability. The three strategies that make this possible, blue-green, canary, and rolling deployment, are often discussed as interchangeable, but they carry fundamentally different risk profiles, infrastructure trade-offs, and operational demands. Choosing the wrong one for your application's architecture can mean either unnecessary cost, silent production failures, or the kind of painful rollback your team only wants to do once. For developers who want to see exactly how each strategy maps to a working ASP.NET Core API — with full CI/CD configuration and Kubernetes manifests — the complete implementation is available on Patreon, annotated for production use.
Understanding the right deployment strategy also depends on how well your API handles the transition itself: graceful shutdown, readiness probes, and backward-compatible database migrations all determine which strategy you can safely adopt. Getting this right in a complete production codebase — where every deployment concern is wired together — is exactly what Chapter 15 of the Zero to Production course covers, with a Dockerfile, GitHub Actions pipeline, and deployment checklist ready to run.
What Zero-Downtime Deployment Actually Means for ASP.NET Core Teams
Zero-downtime deployment means that when you replace version N with version N+1, in-flight HTTP requests complete normally and no new requests receive a 503 or connection error during the transition. For ASP.NET Core, achieving this reliably requires more than just picking a deployment strategy — it requires that your application cooperates:
Graceful shutdown must be configured so that Kestrel stops accepting new connections, drains in-flight requests before exiting, and respects the
SIGTERMsignal sent by the container orchestrator. Without this, any strategy can produce dropped requests at the moment of pod termination.Readiness probes must accurately reflect whether the application is ready to serve traffic. An instance that registers as ready before its connection pool is warm or its cache is seeded will receive requests it cannot serve well.
Database migrations must be backward-compatible during the transition window where both the old and new version are running. A migration that drops a column before the old version is retired will break it immediately.
These requirements are not optional — they are the foundation that every zero-downtime strategy depends on. You can read in depth about configuring readiness and liveness probes correctly in ASP.NET Core Health Checks: Liveness vs Readiness vs Startup Probes, and about graceful shutdown configuration in ASP.NET Core Graceful Shutdown: IHostApplicationLifetime vs Shutdown Timeout vs SIGTERM.
How Rolling Deployment Works
Rolling deployment replaces running instances of your application one at a time — or in small batches — while the remaining instances continue serving traffic. The load balancer or Kubernetes service routes requests only to instances that pass their readiness probe, which means the transition is gradual and infrastructure-efficient.
How it maps to ASP.NET Core on Kubernetes:
When you update a Kubernetes Deployment, the default strategy is rolling update. Kubernetes terminates pods from the old ReplicaSet and creates pods in the new one, governed by maxUnavailable and maxSurge parameters. Traffic only flows to pods whose readiness probe returns HTTP 200.
What rolling deployment is good at:
Minimal infrastructure overhead — you do not need double capacity
Simple to operate — it is the default in most platforms
Continuous progress with no hard cutover moment
Where rolling deployment creates risk for ASP.NET Core teams:
During the transition, both versions are live simultaneously. If your new version introduces a breaking change to a shared cache, session store, or database schema, you have a mixed-version window where some requests are handled by v1 and others by v2 — which can produce inconsistent results.
Rollback means doing another rolling update in the opposite direction. This is not instant.
There is no easy way to send only a subset of users to the new version. All users get the new version once a pod is upgraded, proportionally as traffic is distributed.
Rolling deployment is the right choice when:
Your changes are backward-compatible with the current database schema and shared state
You have limited infrastructure budget and cannot justify idle standby capacity
Your team has not yet instrumented the application well enough to safely gate a canary release
The change is low-risk and the ability to quickly route all traffic away from the new version is not a hard requirement
How Blue-Green Deployment Works
Blue-green deployment runs two identical production environments — call them blue and green — where only one is live at any time. You deploy your new version to the idle environment, run smoke tests, then switch the load balancer or DNS to point all traffic at the new environment in a single atomic operation.
What blue-green deployment is good at:
Instant rollback: if the new version has a problem, you flip the switch back to the old environment. Rollback takes seconds, not minutes.
Clean separation: the old version is never touched during deployment of the new one. There is no mixed-version window.
Validated before cutover: the new environment is fully booted, warmed up, and smoke-tested before it receives any production traffic.
Where blue-green creates challenges for ASP.NET Core teams:
Infrastructure cost: you need capacity for two full production environments. During the pre-cutover period, you are paying for double compute.
Database schema changes are tricky. At the moment of cutover, the database switches from being accessed by v1 to v2. If the migration ran before the cutover, v1 must tolerate the new schema during the final minutes it is live — this requires expand-contract migrations, not simple destructive changes.
Stateful sessions: if users have active sessions tied to the blue environment via sticky routing, those sessions do not automatically migrate to the green environment after cutover.
Blue-green is the right choice when:
Your releases are high-stakes: payment processing, billing events, compliance-sensitive operations
You need the ability to perform an instant, clean rollback under production load
You can absorb the cost of idle standby infrastructure, even briefly
Your change has a known blast radius that you want isolated entirely from traffic until validation is complete
How Canary Deployment Works
Canary deployment routes a small percentage of production traffic — 1%, 5%, 10% — to the new version while the remaining traffic continues to the stable version. You monitor the canary closely: error rates, latency percentiles, business metrics. If the canary looks healthy over the observation window, you progressively increase its traffic share until it handles 100% and the old version is retired.
How it maps to ASP.NET Core:
Canary deployments are typically implemented at the infrastructure level — Kubernetes Ingress, NGINX, service mesh, or Azure Traffic Manager — rather than in application code. You run two separate Deployment objects (stable and canary) with different replica counts that reflect the desired traffic split.
Feature flags are a complementary approach that can simulate canary behaviour at the application layer: the new code path is deployed to all instances but activated only for a percentage of users based on a flag condition. This can be safer for schema-sensitive changes since there is no schema version mismatch even in the early phases.
What canary deployment is good at:
Risk-controlled rollout: if the new version has a defect, only a small fraction of users encounter it before the rollout is halted
Observable validation: you can measure the new version's real-world behaviour under production load before committing to it
Gradual confidence building: rather than a binary cut-over, trust is built progressively
Where canary creates challenges for ASP.NET Core teams:
Operational complexity: you need good observability — distributed tracing, error rate alerting, latency dashboards — to know when to advance or abort the rollout. Running a canary without metrics is flying blind.
Mixed-version concerns: like rolling deployment, both versions run simultaneously. Database schema and shared state must be compatible across both.
Session consistency: requests from the same user may be served by both the stable and canary version if routing is random rather than user-sticky.
Longer transition period: a 5% canary held for 30 minutes before advancing is appropriate for a significant change but feels bureaucratic for a trivial bug fix.
Canary is the right choice when:
Your team has a working observability stack: structured logs, metrics, distributed traces, and alerting
You are deploying changes that are hard to validate fully in a staging environment (behaviour that only manifests at production scale or with real user patterns)
You want to validate business metrics, not just technical health, before full rollout
You can define a clear gate condition: "advance the rollout when the 99th percentile latency of the canary matches stable and the error rate stays below 0.1%"
Side-by-Side Comparison
| Criterion | Rolling | Blue-Green | Canary |
|---|---|---|---|
| Mixed-version window | Yes | No | Yes |
| Rollback speed | Slow (another rolling update) | Instant | Fast (shift traffic to 0%) |
| Infrastructure cost | Low (rolling replacement) | High (double capacity) | Medium (small canary + stable) |
| Schema change safety | Requires backward-compatible migrations | Requires expand-contract migrations | Requires backward-compatible migrations |
| Observability requirement | Low | Low | High |
| Operational complexity | Low | Medium | High |
| Suitable for high-risk changes | No | Yes | Yes (with good monitoring) |
| Suitable for low-risk changes | Yes | Overkill | Adds unnecessary delay |
Is the Change Low-Risk or High-Risk?
The decision between the three strategies almost always comes down to this single question. Mapping the change type to risk level gives you a practical shortcut:
Low-risk changes (rolling is appropriate):
Dependency version bumps (NuGet packages, SDK updates)
Logging verbosity adjustments
Feature additions behind a feature flag
Performance improvements to non-critical paths
Medium-risk changes (rolling with careful migration validation, or canary if observability is available):
New endpoints added to an existing API version
Additive database schema changes (new nullable column, new table)
Changes to caching behaviour
Background service schedule adjustments
High-risk changes (blue-green if you need instant rollback; canary if you need production-scale validation):
Changes to payment, billing, or financial calculation logic
Breaking changes to request or response contracts (even behind versioning)
Changes to authentication or token validation logic
Destructive database operations, even guarded by expand-contract
First deployment of a feature that has no staging equivalent at production scale
The ASP.NET Core-Specific Concerns Every Strategy Shares
Regardless of which strategy you use, several ASP.NET Core runtime concerns apply during any deployment transition:
Application warmup. The first few requests to a cold ASP.NET Core instance pay the JIT compilation cost, connection pool establishment, and first-request middleware overhead. In a rolling or blue-green scenario, a pod that passes its readiness check but has not yet warmed up will serve slower-than-normal responses. You can address this with a startup probe that delays readiness signalling until a synthetic warm-up request has been processed, or by configuring app.UseWarmup() with a warmup task in .NET 9+.
In-flight request draining. When Kubernetes sends SIGTERM to terminate a pod, your ASP.NET Core application needs time to finish in-flight requests before it shuts down. The host's ShutdownTimeout should be configured to a realistic upper bound for your API's worst-case request duration. Without this, pods terminate abruptly mid-request.
Connection pool behaviour. HttpClient instances backed by IHttpClientFactory, and EF Core connection pools, do not automatically drain at shutdown. Requests that arrive in the final seconds before a pod terminates and are assigned to a connection that closes mid-stream will see errors. Configuring connection draining at the load balancer level — giving the pod a finite grace period after receiving SIGTERM before traffic is fully removed — is the correct fix.
Database schema alignment across instances. Every strategy that involves a mixed-version window — rolling and canary — requires that the database schema at any point during the transition is valid for both the old and new version. The expand-contract migration pattern (add the new column as nullable first, deploy, then populate, then enforce the constraint, then remove the old column after the old version is fully retired) is the standard tool for achieving this.
When To Combine Strategies
Real-world teams do not always pick exactly one strategy in the abstract — they combine them based on context:
Blue-green outer shell with canary inner gate: Deploy to the green environment (full blue-green isolation), then route 5% of production traffic to green as a canary gate before committing to full cutover. If the canary gate fails, you flip back to blue immediately. If it passes, you complete the cutover. This gives you the rollback speed of blue-green with the production-scale validation of canary — at higher infrastructure cost.
Rolling with feature flags: Use rolling deployment for the infrastructure transition but introduce the new behaviour behind a feature flag. The mixed-version window exists at the pod level, but the actual behavioural change does not activate until you flip the flag. This separates the deployment event from the release event, which is a useful organisational pattern even without the infrastructure overhead of blue-green or canary.
Frequently Asked Questions
Does ASP.NET Core require any specific configuration to support zero-downtime deployments? Yes. At a minimum, you need to configure graceful shutdown (via IHostApplicationLifetime and an appropriate ShutdownTimeout), implement a readiness probe that accurately reflects application readiness (not just that the process is running), and ensure your database migrations are backward-compatible across the mixed-version window. Without these, any zero-downtime strategy can produce dropped requests or data inconsistency during the transition.
Can I do a zero-downtime deployment if I have a destructive database migration? Not directly. Destructive migrations — dropping a column, renaming a column, changing a column's type — require the expand-contract pattern. Add the new structure alongside the old, deploy the new version so both coexist, backfill or migrate data, then remove the old structure only after the old application version is fully retired. Trying to apply a destructive migration during a rolling or canary deployment will break the instances still running the old version.
What is the minimum infrastructure requirement for blue-green deployment in Kubernetes? You need capacity to run two full replica sets simultaneously: both the stable (blue) deployment and the new (green) deployment at full replica count. If your production deployment typically runs 4 pods, you need capacity for 8 during the transition period. In managed Kubernetes environments like AKS or EKS, you can use cluster autoscaler to provision this capacity on demand and scale it down post-cutover, making blue-green feasible without permanently over-provisioning.
How do I choose between canary and feature flags for risk-controlled rollout? Canary deployment changes which application binary a given request falls on — it is infrastructure-level traffic splitting. Feature flags change which code path executes within the application — it is application-layer conditional logic. Canary is better for validating overall application health (memory, CPU, error rate) at production scale. Feature flags are better for user-level A/B testing, gradual business feature rollout, and cases where you want instant deactivation without a deployment event. For high-stakes changes, using both together provides maximum control.
How does rolling deployment behave during an EF Core DbContext pool warm-up? When a new pod starts and receives its first database request, the EF Core connection pool is cold. The first few requests will pay the cost of establishing physical connections, which can produce elevated latency or brief timeout spikes. In high-throughput APIs this can cause temporary spikes in error rates during the rolling update window. The standard mitigation is to configure a startup probe that runs a lightweight ExecuteScalar query before the pod's readiness probe transitions to healthy, ensuring the connection pool is established before production traffic arrives.
Is rolling deployment safe for APIs that use in-memory distributed sessions? No. If your application stores session data in the process memory of individual pods (not in a shared distributed cache like Redis), then during a rolling update, users whose requests are balanced to a new pod will lose their session state. This is true regardless of deployment strategy — you need to move to a distributed session store (Redis, distributed SQL) before any zero-downtime strategy is truly safe for session-bearing workloads.
Which deployment strategy works best with GitHub Actions CI/CD for ASP.NET Core? Rolling deployment integrates most naturally with GitHub Actions because kubectl rollout commands are native to the Kubernetes CLI and require no additional tooling. Blue-green requires managing two distinct Kubernetes Deployments and a traffic-switching step (service label patch or Ingress rule update). Canary with progressive delivery requires either manual traffic weight adjustments or a Kubernetes-native progressive delivery controller like Argo Rollouts or Flagger. For most teams starting from a basic GitHub Actions CI/CD pipeline, rolling deployment is the pragmatic default, with blue-green or canary introduced once the team has established observability and deployment process maturity.
