// the find
microsoft/aspire
Aspire is the tool for code-first, extensible, observable dev and deploy.
Aspire is Microsoft's opinionated orchestration layer for .NET-centric distributed applications, letting you define your entire service graph (APIs, frontends, databases, caches) in code and run it locally with built-in OpenTelemetry. It recently expanded to support TypeScript, Python, Go, Java, and Rust apphosts alongside C#. The target audience is .NET teams building microservices who want a Docker Compose replacement that carries the same definition into cloud deployment.
- The polyglot apphost support is genuinely useful - you can write your service orchestration in TypeScript or Python instead of C#, which removes the .NET tax for mixed-language teams.
- First-class OpenTelemetry wiring: services get traces, metrics, and logs plumbed through automatically without manual SDK setup, and the local dashboard surfaces them without running a separate collector stack.
- The CI infrastructure is unusually mature for a project this age - quarantine policies for flaky tests, automated flaky-test issue creation, outerloop test runsheets, and deployment cleanup workflows are all present and documented.
- The app model maps cleanly to both local dev (DCP runs containers and processes) and deployment targets, meaning the same definition isn't just a dev convenience that you throw away before shipping.
- Non-.NET language SDKs are clearly second-class right now - the TypeScript SDK is auto-generated and the Python/Go/Java/Rust support is still in validation scripts, not production-ready integrations with the same feature parity as the C# apphost.
- Deployment story is heavily Azure-weighted; if you're targeting AWS, GCP, or self-hosted Kubernetes you'll be writing your own deployment provider, and the manifest format docs are thin enough that this is non-trivial.
- The dependency on DCP (a separate binary, separate repo) is a black box for contributors and adds a hard runtime requirement that makes the local setup fragile on non-standard environments - Windows ARM64 and Linux musl support are clearly afterthoughts based on the clipack structure.
- Service discovery and connection string injection work well within an Aspire app, but the model breaks down when you need to reference external services not managed by Aspire (legacy databases, third-party APIs), requiring awkward workarounds with resource parameters.