.NET Aspire in Production: What We Learnt Building Arkora's ERP

When the Arkora Construction ERP brief landed on my desk, the scale was immediately clear: 18 modules, 350 concurrent users across multiple construction sites, offline capability for field teams, and a hard deadline tied to a contract milestone. This was not a project for experimenting with new frameworks.

And yet we chose .NET Aspire — which was, at the time we started, still in preview.

Here’s why, what worked, and what we’d tell you before you do the same.

What Is .NET Aspire?

If you’re not familiar: .NET Aspire is Microsoft’s opinionated stack for building distributed .NET applications. It handles service orchestration, service discovery, health checks, telemetry, and local development orchestration — things you’d otherwise wire up manually or with a patchwork of libraries.

The pitch is: “start a distributed app locally with one command, and have the observability and configuration patterns you need for production already baked in.”

Why We Chose It

The Arkora ERP has multiple services: a core API, a reporting service, a notifications service, a file management service, and an offline sync service for field devices. In the past, running all of these locally meant a docker-compose.yml that grew to hundreds of lines and constant fighting with port conflicts.

Aspire’s AppHost project handles this elegantly. One dotnet run starts everything — database, cache, API, worker services — with automatic service discovery, so services find each other without environment-specific configuration.

For a team building a complex system under deadline pressure, this developer experience improvement was not trivial. We estimated it saved 2–3 hours per developer per week in environment management overhead.

What Aspire Gets Right

The dashboard is excellent. Aspire ships with a local dashboard showing all running services, their health, structured logs aggregated across services, distributed traces, and metrics. For a microservices ERP, this is transformative during development. You can see a user action flow through five services in a single trace without configuring Jaeger or Zipkin.

Service discovery is zero-config. Services reference each other by name. Aspire resolves the addresses. No hardcoded localhost ports, no environment variable juggling. This matters enormously when you have junior team members who shouldn’t need to understand networking to run the app.

The telemetry defaults are production-ready. OpenTelemetry is wired up out of the box. We pointed it at Azure Monitor for production and had distributed tracing live within a day of go-live.

Where Aspire Has Rough Edges

Azure deployment is not as turnkey as the docs suggest. The Aspire Azure provisioning via Azure Developer CLI worked for simple topologies but required significant manual intervention for our requirements: private networking, managed identity configuration, and custom scaling rules. We ended up writing Terraform for the production infrastructure and using Aspire only for local dev and staging.

The component ecosystem is immature. Third-party Aspire components vary wildly in quality. Some are excellent; others are clearly early works. Vet carefully before adopting.

Breaking changes during the preview period. We started on a preview build. Two breaking changes hit us during development — both required half-day migrations. If you’re using Aspire post-GA today, this is less of a concern, but the ecosystem is still moving fast.

The Verdict

For a complex multi-service .NET application, .NET Aspire is a genuine productivity multiplier during development. The dashboard alone justifies the learning curve.

For production, treat it as an orchestration layer for local dev and CI, with your actual infrastructure managed by Terraform or Bicep. Don’t rely on Aspire’s Azure provisioning for anything complex.

Arkora’s ERP has been running in production for six months. 350 concurrent users, 18 modules, stable. We’d make the same choice again.