What is Aspire?

What is Aspire?

Aspire is a Microsoft-built orchestration and observability framework for distributed applications. You describe the services, databases, queues, frontends, and cloud dependencies of your application in code - then Aspire runs them together locally, wires up service discovery between them, and gives you a single dashboard to inspect logs, traces, metrics, and health across the whole topology.

The product launched as .NET Aspire for C# distributed applications, and the name still carries the prefix - but the tool has since grown into a multi-language platform. The AppHost (Aspire's source of truth) can be written in C# or TypeScript today, and it can orchestrate workloads in JavaScript, Python, Go, Java, Rust, PowerShell, and more. The website's tagline now drops the ".NET" entirely: Your stack, streamlined.

Aspire is a code-first orchestration and observability layer for distributed applications.- aspire.dev

The problem it solves

Modern applications rarely consist of a single process. A typical product spans an API, one or two worker services, a database, a cache, a message broker, a frontend, and a handful of cloud dependencies. In production they run together as one system. In development, each piece often needs to be started separately, configured by hand, and debugged across multiple terminal windows.

The day-to-day cost shows up everywhere:

The pain points Aspire is built to remove are concrete: chasing logs across five terminals, hardcoding localhost:5432 until it breaks in production, manually attaching a debugger to each service, and onboarding a new engineer by walking them through the "right" startup order for the dozenth time. Aspire makes the application's local topology a piece of code, not tribal knowledge.

The AppHost - one model in code

The heart of an Aspire application is the AppHost: a single project that defines what the distributed application is made of. Resources - projects, executables, containers, databases, caches, cloud services - are added to a builder, and dependencies between them are declared explicitly:

Three things make this model useful beyond just "starting things in order":

• Type safety. Resources are typed values. A reference to a database is a C# expression the compiler checks. Misspelling a service name fails at compile time, not at aspire run.
• Single source of truth. A new team member can read one file and understand the entire application topology. No more spelunking through README files, makefiles, and Docker Compose YAMLs to figure out what runs where.
• Refactorable architecture. Renaming a service, swapping its storage backend, or splitting a worker into two services are code edits with full editor support.

Service discovery and ServiceDefaults

When the AppHost says api.WithReference(db), Aspire does two important things behind the scenes.

First, service discovery. Aspire injects the database's connection string into the API process as an environment variable before the API starts. The API never has to know whether it's running locally against a container, against a developer's external Postgres, or against a cloud-hosted instance in production - the configuration is wired up by the AppHost. The same code that ran locally runs in production with no localhost:5432 hard-coded anywhere.

Second, ServiceDefaults. Most Aspire projects include a shared ServiceDefaults project (or package) that every service references. It applies common settings across the application:

• OpenTelemetry tracing, logging, and metrics exporters
• Standardized health-check endpoints
• Resilience defaults (retry, circuit breakers, timeouts)
• HTTP client configuration with service discovery

The pattern matters because the alternative - configuring telemetry, health checks, and resilience by hand in every service - is a place teams accumulate inconsistency over time. ServiceDefaults makes "what every service does" a single artifact that everyone shares.

Observability and the Dashboard

Aspire ships with a local Dashboard that opens automatically when you run aspire run. It is one of the project's most-loved features for a simple reason: every signal you need to investigate a distributed system is already in one place.

• Resources view. A live list of every service, container, and database in the application, with start times, health, and direct links to each one.
• Logs. Every service's stdout / stderr, streamed in real time, filterable by service. No more flipping between five terminal windows.
• Traces. Distributed traces - an HTTP request that crossed three services rendered as a single waterfall with timings at every span.
• Metrics. OpenTelemetry metrics published by your services, plotted over time.

The Dashboard is also a debugging aid. Pressing F5 in a supported editor attaches the debugger to every project in the AppHost simultaneously, so a breakpoint set in the API and another set in the worker both hit when the relevant code runs - without any per-service debugger configuration on your part.

Beyond .NET - multi-language support

The biggest evolution since Aspire's 1.0 release is that the AppHost no longer has to be .NET. Aspire now supports a TypeScript AppHost as a first-class citizen, with the same orchestration model, service discovery, and dashboard tooling as the C# version:

Underneath, Aspire uses a guest/host architecture: a TypeScript AppHost talks to the same orchestration engine, integration catalog, and diagnostics pipeline as a C# one. The guest workloads themselves can be in any supported runtime - C#, Node.js, Python, Go, Java, Rust, PowerShell - all defined in the same AppHost file, all orchestrated by the same aspire run.

This matters because polyglot stacks are the norm now. A team with a C# API, a Python ML worker, and a Vite + React frontend used to need three different orchestration strategies stitched together with shell scripts. Aspire lets them all live in one model.

Development vs production

Aspire's role is local development and the path to deployment - it is not a production runtime. When it is time to ship, the same architecture definition compiles down to deployment artifacts: Kubernetes manifests, Azure Container Apps configurations, Docker Compose files, or whatever your target platform consumes. The relationships you described in the AppHost translate into the wiring your production environment needs.

What Aspire is NOT, in case the framing is unclear:

• Not a replacement for your application framework. Your services are still ASP.NET Core, FastAPI, Express, whatever you choose. Aspire orchestrates them; it does not replace them.
• Not a cloud provider. Aspire does not run your production traffic. It models your application so that whatever runs your production traffic - Kubernetes, Container Apps, ECS - has the configuration it needs.
• Not a Docker Compose replacement. Docker Compose is a YAML-based local-dev orchestrator. Aspire is a code-first one with first-class typed references, observability, and multi-language support. They overlap; they are not the same.

When to reach for Aspire

Aspire is the right call when an application has multiple moving parts that need to run together in development:

• An API plus one or more background workers
• Containerized dependencies (Postgres, Redis, RabbitMQ, MinIO)
• A frontend that talks to an API and needs the API's URL injected at startup
• Cross-language stacks where the parts are written in C#, Python, JavaScript, or any mix
• Teams whose new engineers should be productive on day one without a long setup document

Reach for something lighter when the application is a single process with no external dependencies, when the project is small enough that one terminal and a README is genuinely fine, or when the team is already deeply invested in a different orchestration model that works for them. Aspire pays off in proportion to the distance between "what runs locally" and "what runs in production" - and that distance grows fast.