← Back to all posts
dotnetazurecontainer-appsdevopsdeploymentcsharp

Azure Container Apps and Blue-Green Deployments in .NET

Azure Container Apps and Blue-Green Deployments in .NET

Reading Time: 7 minutes

The Problem

Shipping a new version of an application is easy right up until the release goes wrong.

A typical deployment risk looks like this:

  • a new container image is pushed
  • the old version is replaced immediately
  • traffic starts hitting the new version at once
  • an unexpected bug appears under production load
  • rollback means another deployment and more waiting

That is manageable for low-risk internal tools. It is much more painful for customer-facing APIs and web applications where a bad deployment can translate directly into failed requests, downtime, and lost confidence.

The real problem is not just deployment automation. It is the lack of a safe release mechanism. If every deployment is effectively an all-or-nothing swap, production becomes a place where changes are tested under maximum pressure.

The Solution

Azure Container Apps gives you a managed platform for running containerized applications without managing Kubernetes directly, and one of its most valuable deployment features is revisions.

Revisions make blue-green style rollouts practical.

At a high level:

  • blue is the currently stable revision
  • green is the newly deployed revision
  • both can exist at the same time
  • traffic can be switched from blue to green gradually or all at once
  • rollback is fast because the previous revision is still available

That changes the deployment model from:

  • deploy and hope

into:

  • deploy, verify, shift traffic, and only then fully promote

For .NET teams, Azure Container Apps is especially useful because it combines:

  • simple container hosting
  • scale-to-zero and event-driven scaling support
  • managed ingress and traffic splitting
  • revision-based rollout control
  • good fit for ASP.NET Core APIs and background workloads

What Azure Container Apps Actually Gives You

Azure Container Apps sits between traditional App Service style hosting and full Kubernetes management.

You provide:

  • a container image
  • CPU and memory settings
  • ingress configuration
  • environment variables and secrets
  • scaling rules

Azure handles:

  • the runtime platform
  • HTTPS ingress
  • revision lifecycle
  • scaling infrastructure
  • traffic routing between revisions

That means you can use container deployment patterns without needing to operate a Kubernetes cluster yourself.

Why Blue-Green Matters

A blue-green rollout is valuable because it reduces the blast radius of change.

Instead of replacing the active version immediately, you:

  1. deploy the new revision
  2. verify it independently
  3. send a small amount of traffic to it
  4. observe errors, latency, and behavior
  5. increase traffic only when confidence is high

That gives you several benefits:

  • safer production releases
  • faster rollback
  • better confidence in new revisions
  • lower risk during schema-compatible changes
  • less pressure to treat deployment like a one-shot event

In Azure Container Apps, revisions are the mechanism that makes this practical.

Single Revision vs Multiple Revisions

Azure Container Apps supports two important modes:

Single revision mode

Only one revision is active at a time.

This is simple, but it is not what you want for blue-green deployments because the platform replaces the active revision directly.

Multiple revision mode

Multiple revisions can stay active simultaneously.

This is the mode you want for blue-green or canary-style deployments because traffic can be split between revisions.

If you want controlled rollout, use multiple revision mode.

A Typical Blue-Green Flow in Container Apps

A safe rollout usually looks like this:

  1. Build and publish a new container image.
  2. Deploy it as a new Azure Container Apps revision.
  3. Keep the previous stable revision active.
  4. Route a small percentage of traffic to the new revision.
  5. Check health, logs, latency, and business behavior.
  6. Shift more traffic to the new revision.
  7. When stable, move 100% traffic to green.
  8. Optionally deactivate the old revision afterward.

This is conceptually simple, but it is a huge improvement over immediate replacement because rollback is basically a traffic-routing decision rather than an emergency redeploy.

.NET Application Shape

From the application’s perspective, Azure Container Apps does not require special .NET code. A normal ASP.NET Core app works well as long as it behaves like a good containerized application.

That means:

  • listen on the port expected by the container runtime
  • externalize configuration through environment variables or managed configuration providers
  • write logs to standard output
  • make startup predictable and fast
  • expose health endpoints where appropriate

A minimal ASP.NET Core API is enough:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHealthChecks();

var app = builder.Build();

app.MapGet("/", () => Results.Ok(new { message = "Hello from Azure Container Apps" }));

app.MapGet("/version", () => Results.Ok(new
{
    version = Environment.GetEnvironmentVariable("APP_VERSION") ?? "unknown",
    revision = Environment.GetEnvironmentVariable("CONTAINER_APP_REVISION") ?? "unknown"
}));

app.MapHealthChecks("/health");

app.Run();

This simple shape already helps with blue-green deployment because:

  • /health can be used for validation
  • /version makes it easy to see which revision is serving traffic
  • environment variables let you distinguish revisions without code changes

Containerizing the App

A straightforward Dockerfile for an ASP.NET Core app might look like this:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

COPY . .
RUN dotnet publish -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app
COPY --from=build /app/publish .

ENV ASPNETCORE_URLS=http://0.0.0.0:8080
EXPOSE 8080

ENTRYPOINT ["dotnet", "MyApi.dll"]

The important detail is that the app must listen on the same port you configure in Azure Container Apps ingress settings.

Configuration for Azure Container Apps

You normally pass configuration through environment variables or managed services such as:

  • Azure App Configuration
  • Azure Key Vault
  • managed identity-based access to Azure services

A practical .NET example for reading a version label or feature switch:

public sealed class RuntimeOptions
{
    public string Version { get; set; } = "unknown";
    public bool EnableExperimentalEndpoint { get; set; }
}
var runtimeOptions = new RuntimeOptions
{
    Version = builder.Configuration["APP_VERSION"] ?? "unknown",
    EnableExperimentalEndpoint =
        bool.TryParse(builder.Configuration["ENABLE_EXPERIMENTAL_ENDPOINT"], out var enabled) && enabled
};

if (runtimeOptions.EnableExperimentalEndpoint)
{
    app.MapGet("/experimental", () => Results.Ok(new { version = runtimeOptions.Version }));
}

This is useful in blue-green rollout scenarios because you can compare revision behavior without rebuilding the application for every small operational change.

Operational Checks Before Traffic Shift

A deployment is not successful just because a new revision started.

Before shifting traffic, verify:

  • the revision starts correctly
  • health endpoints succeed
  • logs show no startup exceptions
  • database connections, downstream calls, and managed identity access work
  • latency and error rate look normal

That is why blue-green is so valuable. It gives you an observation window before full exposure.

Rollback Story

Rollback is where this pattern earns its keep.

If the green revision fails under real traffic:

  • reduce its traffic allocation to zero
  • return traffic to the previous blue revision
  • investigate without forcing a rushed redeploy path

Because the old revision is still there, rollback is fast and operationally simple.

That is much safer than replacing a live environment and then scrambling to rebuild confidence after a bad release.

When Blue-Green Is Especially Useful

Azure Container Apps revisions and traffic splitting are especially valuable for:

  • customer-facing APIs
  • public web applications
  • systems with strict uptime requirements
  • releases that change infrastructure integration behavior
  • deployments where rollback speed matters more than deployment simplicity

If a bad release would hurt real users, blue-green is usually worth the extra operational discipline.

Practical Recommendations

A strong default approach for Azure Container Apps with blue-green deployment is:

  • use multiple revision mode
  • keep the previous stable revision active during rollout
  • shift traffic gradually instead of replacing immediately
  • expose a health endpoint in your .NET app
  • make revision identity visible through a version endpoint or logs
  • externalize configuration through environment variables, App Configuration, or Key Vault
  • use managed identity for Azure service access rather than secrets in container settings

Summary

Azure Container Apps gives .NET teams a practical way to run containers with managed infrastructure and safer deployment mechanics.

The key advantage for releases is revisions.

That enables a blue-green deployment model where you can:

  • deploy a new revision without immediately replacing the old one
  • validate behavior before full cutover
  • shift traffic deliberately
  • roll back quickly if something goes wrong

That is the real operational win. It turns deployments from a risky switch-over into a controlled release process.

References