The .NET Aspire Production Reality Check

I've shipped three services running through .NET Aspire's local-dev orchestration. I'll happily use it on the next one. I will not use it as my Kubernetes replacement, no matter how nice the slides at .NET Conf were.

Here's the honest split.

Aspire absolutely nails local dev orchestration. The AppHost project boots Postgres, Redis, Qdrant, your API, and the worker — all wired up with service discovery and OpenTelemetry — in a single dotnet run. No docker-compose to hand-write. No localhost:5432 strings copied across appsettings files. The dashboard at localhost:18888 is genuinely useful: traces, logs, metrics, all there without me running Grafana.

var builder = DistributedApplication.CreateBuilder(args);
var pg = builder.AddPostgres("db").AddDatabase("appdb");
var qdrant = builder.AddContainer("qdrant", "qdrant/qdrant").WithHttpEndpoint(6333);

builder.AddProject<Projects.Api>("api")
    .WithReference(pg).WithReference(qdrant);

builder.Build().Run();

That's the whole local-dev environment, in one file. New engineer joins, clones the repo, runs that. They see everything running. This part is real and it's good.

What Aspire isn't:

It's not a Kubernetes replacement. The azd up and aspire publish paths produce manifests you can deploy, but you're still going to want a real cluster, real GitOps, real secrets management once you're past one service or one customer. Aspire generates the bicep, but it doesn't replace your platform team.

It's not a Helm chart generator. Don't try to make it one. The deployment story is good enough for "ship a thing to Azure Container Apps without becoming a Kubernetes person." It's not good enough for "run a 30-microservice product on AKS."

It's not a service mesh. Service discovery is just config injection. No retries, no traffic splitting, no mTLS. If you need those, your real prod path is Dapr or Istio.

The right framing: Aspire is for local dev plus a clean handoff to cloud. The handoff is real. The "Aspire is your prod runtime" framing in some Microsoft posts has been... aspirational.

Migrating an existing solution in took me an afternoon: add the AppHost project, list the projects and containers it depends on, delete the docker-compose file, smile. Onboarding time for new devs dropped from "half a day to wire up services" to "one command, you're in."

The verdict I keep landing on: use Aspire from day one for local dev. Wire it up to OpenTelemetry properly. Use the deployment path for greenfield Azure-bound services. Don't try to use it for the prod runtime of a multi-team microservices estate. That's still Kubernetes, and Aspire isn't pretending otherwise — even if some of the .NET Conf demos do.