Last verified
Build distributed applications locally using a code-first AppHost, built-in OpenTelemetry observability, and support for C#, TypeScript, Python, Go, and more.
Aspire provides a single AppHost that spans every service regardless of language, replacing a folder full of docker-compose.yml variants and service-specific README instructions. Teams can spin up a new developer's local environment with one command.
If your services are all in one language and you are already happy with Docker Compose, Aspire adds a learning curve without proportional benefit for small single-language stacks.
Aspire's built-in OpenTelemetry dashboard eliminates the separate collector, exporter, and visualization tool configuration that observability typically requires. Engineers get per-request traces across services from day one without touching a Jaeger or Grafana config.
If your team already has a mature OpenTelemetry pipeline with Grafana and you are not rewriting the local development experience, Aspire's dashboard is an addition rather than a replacement.
The same AppHost that runs locally generates deployment manifests for Azure Container Apps, AWS App Runner, and Kubernetes. Teams that change architecture in development are automatically changing what ships.
If you are deploying to a bare-metal or on-premises environment with no container registry, Aspire's deployment output paths assume container or cloud targets.
Aspire exposes the full application topology to connected coding agents in one connection: resource graph, endpoint health, logs, and available commands. Teams using GitHub Copilot, Claude, or other AI coding tools gain context the agent can act on directly.
If your AI tooling does not support the MCP protocol or Aspire's context format, the agent-ready feature provides no benefit without additional integration work.
Running a distributed system locally is an orchestration problem most teams solve badly. Services start in the wrong order, depend on environment variables set differently on each machine, and require manual wiring of ports, connection strings, and service discovery. Docker Compose helps but stays in Docker's model: it does not understand application-level dependencies, cannot bridge local processes and containers cleanly, and provides no observability beyond container logs.
The observability gap is the harder problem. Teams typically add OpenTelemetry after something breaks in production, by which point the feedback loop between code change and trace spans is already slow. Configuring a collector, exporter, and dashboard involves multiple separate tools and a configuration surface that grows with every new service. For a team onboarding a new developer, standing up the full local stack can take a day or more.
Defines every service, database, cache, container, and dependency in code using a fluent API available in C# and TypeScript. The AppHost is the single source of truth: change a reference there and the CLI, dashboard, and deployment artifacts all reflect the change. No YAML manifests to sync separately.
The Aspire CLI starts a local dashboard on first run with logs, traces, metrics, and resource health for every service in the app. No separate collector or Jaeger instance needed: traces flow from the first request, and clicking a resource in the dashboard takes you directly to its spans.
Brings .NET, TypeScript, JavaScript, Python, Java, Go, Rust, and containers into one application model. Each service uses its own language and framework; Aspire handles service discovery and configuration injection between them without requiring a shared runtime.
The same AppHost topology runs in local development, automated tests, and production deployment. Aspire generates deployment artifacts for Azure Container Apps, AWS App Runner, Kubernetes, or container registries from the same definition developers use locally.
Exposes live application context to connected AI coding agents (GitHub Copilot, Claude, OpenAI-compatible tools) through a single connection. The agent sees the resource graph, running endpoints, telemetry, health status, and available commands without requiring manual context setup.
Adds databases, caches, messaging systems, cloud resources, and community packages through the same fluent AppHost API. Existing integrations cover Postgres, Redis, RabbitMQ, Azure services, and AWS resources; community integrations extend the catalog further.
Both Aspire and Garden tackle local orchestration for distributed systems. Garden offers Kubernetes-native orchestration with hot reload and remote cluster support in its commercial plan; Aspire takes a code-first approach where the AppHost defines services and their connections in C# or TypeScript rather than YAML manifests.
| Feature | Aspire | Garden |
|---|---|---|
| License | MIT | Apache 2.0 (open) / Commercial |
| Configuration | Code (C#, TypeScript) | YAML manifests |
| Kubernetes support | Deployment output | Native cluster integration |
| Observability | Built-in OpenTelemetry dashboard | Via third-party tools |
| Pricing | Free | Free tier / paid enterprise |
Aspire is the better choice when your team wants a code-first model with built-in observability and polyglot service support, and when deployment targets are Azure, AWS, or standard container hosts. Garden is a stronger choice when your team is already committed to Kubernetes and needs remote cluster development with hot reloading in a cluster environment.
Pulumi and Aspire occupy different layers of the stack but overlap at the deployment step. Pulumi is infrastructure as code: it provisions cloud resources and manages their state through the paid Pulumi Cloud or a self-hosted backend. Aspire is a development orchestration tool that generates deployment artifacts but does not manage cloud state.
| Feature | Aspire | Pulumi |
|---|---|---|
| License | MIT | Apache 2.0 (open) / Pulumi Cloud (paid) |
| Primary role | Dev orchestration + deployment artifacts | Infrastructure provisioning + state management |
| Local development | Yes | No |
| Observability | Built-in | Not included |
| State management | None | Pulumi Cloud or self-hosted backend |
Aspire is the right choice when the goal is a faster local development loop and deployment parity with less infrastructure ceremony. Pulumi is worth adopting when your team needs to provision and manage cloud resources (VPCs, managed databases, IAM policies) with tracked state. The two tools are complementary: some teams use Aspire for development orchestration and Pulumi for the underlying infrastructure.
Install the Aspire CLI using the official shell installer for your platform.
```powershell
irm https://aspire.dev/install.ps1 | iex
```
```bash
curl -sSL https://aspire.dev/install.sh | bash
```No. Aspire supports C#, TypeScript, JavaScript, Python, Java, Go, Rust, and containers in the same AppHost. The original SDK was C#, and the TypeScript AppHost reached feature parity for the most common resources. Python, Java, Go, and Rust support is available but covers fewer integrations than .NET or TypeScript today.
Aspire replaces Docker Compose for the local development orchestration role, but it does more: it understands application-level dependencies (not just container health), injects service discovery and connection strings automatically, and provides a built-in OpenTelemetry dashboard. It does not replace Docker itself; containers defined in the AppHost still run via Docker locally.
Aspire generates deployment artifacts from the same AppHost definition used in development. The aspire deploy command produces manifests for Azure Container Apps, AWS App Runner, Kubernetes, or container registries. It does not provision cloud infrastructure on your behalf: you need an existing cloud account and target environment configured.
Aspire is MIT licensed. The full license text is in the GitHub repository. MIT means you can run it commercially, fork it, and modify it without restriction, and you are not required to publish source changes.
Aspire exposes a live application context endpoint that AI tools connect to through a single configuration. Once connected, the agent sees the resource graph, running endpoints, health status, logs, traces, and available commands. The website lists GitHub Copilot, Claude, and OpenAI-compatible tools as supported.
Alternative to
Pulumi Cloud
Type-safe cloud infrastructure and app logic in one TypeScript program
Open-source tools that work instantly, no signup required
Alternative to
Hangfire Pro
Distributed .NET job scheduler, decoupled workers, one dashboard.
Alternative to
Sentry
Self-hosted error tracking, drop-in compatible with all Sentry SDKs.
Alternative to
GitHub Codespaces
VS Code in the browser, self-hosted, with no per-seat pricing.
Alternative to
Easypanel
CLI tool for 93 self-hosted apps with an agent-ready install workflow.
Sponsors
Alternative to
Superhuman
AI email assistant that drafts replies and clears your inbox
Alternative to
Grok Bot
AI teammates you own: your keys, your model, your machine.
Live monitoring on LinkedIn, X, Reddit & more. Agentic social listening for startups.
The projects we add and every new guide. Free, unsubscribe any time.
Claude Code to 
OpenCode
Jira to 
Windshift
Notion to 
AppFlowy
Slack to 
Mattermost
Linear to 
GitLab
Wispr Flow to 
Handy
Arc to 
Zen Browser
CapCut to 
Concat
Grok Bot to 
rakazo
Superhuman to 
Inbox Zero
Discord to 
Stoat
Airtable to 
AITable
Datadog to 
SigNoz
Muse to 
OpenClaw
Railway to 
Coolify
GitHub Copilot to 
ClineConfluence to 
Wiki.js
Microsoft Teams to 
Rocket.Chat
1Password to 
KeePassXC
Firebase to 
Supabase
Pinecone to 
Qdrant
Zapier to 
n8n
Devin AI to 
OpenHands
Asana to 
Leantime
