Aspire
GitHubOfficialFirst committed by ChrisMcKee1Distributed by GitHub
- Skill
- Tool integration
- Software development
- MIT
- Medium risk
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
Aspire is a code-first, polyglot orchestration framework designed to simplify the development, debugging, and deployment of distributed applications. It uses an AppHost project to manage the lifecycle of containers, executables, and cloud resources, providing a unified developer experience across various languages including C#, Python, Go, and JavaScript. The framework includes a local Developer Control Plane (DCP) for orchestration, a real-time dashboard for observability, and built-in support for service discovery and infrastructure integrations.
What it does
- Orchestrates multi-service applications via a central AppHost project.
- Provides a local runtime engine (DCP) for managing resource lifecycles.
- Automates service discovery and configuration through environment variable injection.
- Offers a real-time dashboard for monitoring logs, traces, and metrics.
- Supports polyglot workloads including .NET, Python, Go, and Node.js.
- Generates deployment manifests for cloud environments like Kubernetes and Azure.
When to use it
- When building a distributed system that requires local orchestration of multiple services.
- When you need to manage dependencies between containers, databases, and APIs.
- When you want to simplify service discovery and configuration in a polyglot environment.
- When you need to transition from local development to cloud deployment using standardized manifests.
- When you require integrated observability and health checks during the development loop.
Advantages
- Unified developer experience for polyglot distributed systems.
- Code-first approach allows for programmatic infrastructure definition.
- Automatic service discovery reduces manual configuration overhead.
- Integrated dashboard provides immediate visibility into system health and logs.
- Supports standard container runtimes and cloud-native deployment targets.
Usage examples
- “Create a new Aspire project with a starter template.”
- The agent executes 'aspire new aspire-starter' to generate a project structure containing an AppHost, service defaults, and sample services.
- “How do I add a Redis cache to my existing Aspire AppHost?”
- The agent guides you to run 'aspire add redis' and shows how to wire the resource in your AppHost using '.WithReference(redis)'.
- “Run my distributed application locally.”
- The agent triggers 'aspire run', which builds the AppHost, starts the DCP engine, manages resource dependencies, and opens the Aspire dashboard.
- “How can I deploy my Aspire application to Kubernetes?”
- The agent explains the use of 'aspire publish' to generate the necessary deployment manifests for your target environment.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/github/aspire/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip aspire.zip -d .agents/skills
Documentation by ChrisMcKee1
Aspire — Polyglot Distributed-App Orchestration
Aspire is a code-first, polyglot toolchain for building observable, production-ready distributed applications. It orchestrates containers, executables, and cloud resources from a single AppHost project — regardless of whether the workloads are C#, Python, JavaScript/TypeScript, Go, Java, Rust, Bun, Deno, or PowerShell.
Mental model: The AppHost is a conductor — it doesn't play the instruments, it tells every service when to start, how to find each other, and watches for problems.
Detailed reference material lives in the references/ folder — load on demand.
References
| Reference | When to load |
|---|---|
| CLI Reference | Command flags, options, or detailed usage |
| MCP Server | Setting up MCP for AI assistants, available tools |
| Integrations Catalog | Discovering integrations via MCP tools, wiring patterns |
| Polyglot APIs | Method signatures, chaining options, language-specific patterns |
| Architecture | DCP internals, resource model, service discovery, networking, telemetry |
| Dashboard | Dashboard features, standalone mode, GenAI Visualizer |
| Deployment | Docker, Kubernetes, Azure Container Apps, App Service |
| Testing | Integration tests against the AppHost |
| Troubleshooting | Diagnostic codes, common errors, and fixes |
1. Researching Aspire Documentation
The Aspire team ships an MCP server that provides documentation tools directly inside your AI assistant. See MCP Server for setup details.
Aspire CLI 13.2+ (recommended — has built-in docs search)
If running Aspire CLI 13.2 or later (aspire --version), the MCP server includes docs search tools:
| Tool | Description |
|---|---|
list_docs | Lists all available documentation from aspire.dev |
search_docs | Performs weighted lexical search across indexed documentation |
get_doc | Retrieves a specific document by its slug |
These tools were added in PR #14028. To update: aspire update --self --channel daily.
For more on this approach, see David Pine's post: https://davidpine.dev/posts/aspire-docs-mcp-tools/
Aspire CLI 13.1 (integration tools only)
On 13.1, the MCP server provides integration lookup but not docs search:
| Tool | Description |
|---|---|
list_integrations | Lists available Aspire hosting integrations |
get_integration_docs | Gets documentation for a specific integration package |
For general docs queries on 13.1, use Context7 as your primary source (see below).
Fallback: Context7
Use Context7 (mcp_context7) when the Aspire MCP docs tools are unavailable (13.1) or the MCP server isn't running:
Step 1 — Resolve the library ID (one-time per session):
Call mcp_context7_resolve-library-id with libraryName: ".NET Aspire".
| Rank | Library ID | Use when |
|---|---|---|
| 1 | /microsoft/aspire.dev | Primary source. Guides, integrations, CLI reference, deployment. |
| 2 | /dotnet/aspire | API internals, source-level implementation details. |
| 3 | /communitytoolkit/aspire | Non-Microsoft polyglot integrations (Go, Java, Node.js, Ollama). |
Step 2 — Query docs:
libraryId: "/microsoft/aspire.dev", query: "Python integration AddPythonApp service discovery"
libraryId: "/communitytoolkit/aspire", query: "Golang Java Node.js community integrations"Fallback: GitHub search (when Context7 is also unavailable)
Search the official docs repo on GitHub:
Docs repo:
microsoft/aspire.dev— path:src/frontend/src/content/docs/Source repo:
dotnet/aspireSamples repo:
dotnet/aspire-samplesCommunity integrations:
CommunityToolkit/Aspire
2. Prerequisites & Install
| Requirement | Details |
|---|---|
| .NET SDK | 10.0+ (required even for non-.NET workloads — the AppHost is .NET) |
| Container runtime | Docker Desktop, Podman, or Rancher Desktop |
| IDE (optional) | VS Code + C# Dev Kit, Visual Studio 2022, JetBrains Rider |
# Linux / macOS
curl -sSL https://aspire.dev/install.sh | bash
# Windows PowerShell
irm https://aspire.dev/install.ps1 | iex
# Verify
aspire --version
# Install templates
dotnet new install Aspire.ProjectTemplates3. Project Templates
| Template | Command | Description |
|---|---|---|
| aspire-starter | aspire new aspire-starter | ASP.NET Core/Blazor starter + AppHost + tests |
| aspire-ts-cs-starter | aspire new aspire-ts-cs-starter | ASP.NET Core/React starter + AppHost |
| aspire-py-starter | aspire new aspire-py-starter | FastAPI/React starter + AppHost |
| aspire-apphost-singlefile | aspire new aspire-apphost-singlefile | Empty single-file AppHost |
4. AppHost Quick Start (Polyglot)
The AppHost orchestrates all services. Non-.NET workloads run as containers or executables.
var builder = DistributedApplication.CreateBuilder(args);
// Infrastructure
var redis = builder.AddRedis("cache");
var postgres = builder.AddPostgres("pg").AddDatabase("catalog");
// .NET API
var api = builder.AddProject<Projects.CatalogApi>("api")
.WithReference(postgres).WithReference(redis);
// Python ML service
var ml = builder.AddPythonApp("ml-service", "../ml-service", "main.py")
.WithHttpEndpoint(targetPort: 8000).WithReference(redis);
// React frontend (Vite)
var web = builder.AddViteApp("web", "../frontend")
.WithHttpEndpoint(targetPort: 5173).WithReference(api);
// Go worker
var worker = builder.AddGolangApp("worker", "../go-worker")
.WithReference(redis);
builder.Build().Run();For complete API signatures, see Polyglot APIs.
5. Core Concepts (Summary)
| Concept | Key point |
|---|---|
| Run vs Publish | aspire run = local dev (DCP engine). aspire publish = generate deployment manifests. |
| Service discovery | Automatic via env vars: ConnectionStrings__<name>, services__<name>__http__0 |
| Resource lifecycle | DAG ordering — dependencies start first. .WaitFor() gates on health checks. |
| Resource types | ProjectResource, ContainerResource, ExecutableResource, ParameterResource |
| Integrations | 144+ across 13 categories. Hosting package (AppHost) + Client package (service). |
| Dashboard | Real-time logs, traces, metrics, GenAI visualizer. Runs automatically with aspire run. |
| MCP Server | AI assistants can query running apps and search docs via CLI (STDIO). |
| Testing | Aspire.Hosting.Testing — spin up full AppHost in xUnit/MSTest/NUnit. |
| Deployment | Docker, Kubernetes, Azure Container Apps, Azure App Service. |
6. CLI Quick Reference
Valid commands in Aspire CLI 13.1:
| Command | Description | Status |
|---|---|---|
aspire new <template> | Create from template | Stable |
aspire init | Initialize in existing project | Stable |
aspire run | Start all resources locally | Stable |
aspire add <integration> | Add an integration | Stable |
aspire publish | Generate deployment manifests | Preview |
aspire config | Manage configuration settings | Stable |
aspire cache | Manage disk cache | Stable |
aspire deploy | Deploy to defined targets | Preview |
aspire do <step> | Execute a pipeline step | Preview |
aspire update | Update integrations (or --self for CLI) | Preview |
aspire mcp init | Configure MCP for AI assistants | Stable |
aspire mcp start | Start the MCP server | Stable |
Full command reference with flags: CLI Reference.
7. Common Patterns
Adding a new service
Create your service directory (any language)
Add to AppHost:
Add*App()orAddProject<T>()Wire dependencies:
.WithReference()Gate on health:
.WaitFor()if neededRun:
aspire run
Migrating from Docker Compose
aspire new aspire-apphost-singlefile(empty AppHost)Replace each
docker-composeservice with an Aspire resourcedepends_on→.WithReference()+.WaitFor()ports→.WithHttpEndpoint()environment→.WithEnvironment()or.WithReference()
8. Key URLs
| Resource | URL |
|---|---|
| Documentation | https://aspire.dev |
| Runtime repo | https://github.com/dotnet/aspire |
| Docs repo | https://github.com/microsoft/aspire.dev |
| Samples | https://github.com/dotnet/aspire-samples |
| Community Toolkit | https://github.com/CommunityToolkit/Aspire |
| Dashboard image | mcr.microsoft.com/dotnet/aspire-dashboard |
| Discord | https://aka.ms/aspire/discord |
| https://www.reddit.com/r/aspiredotdev/ |
Files
- ATTRIBUTION.mdAdded by AutoGineer851 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md9.1 KiB
- references/architecture.md10.0 KiB
- references/cli-reference.md8.5 KiB
- references/dashboard.md6.3 KiB
- references/deployment.md6.2 KiB
- references/integrations-catalog.md5.0 KiB
- references/mcp-server.md8.3 KiB
- references/polyglot-apis.md8.8 KiB
- references/testing.md7.4 KiB
- references/troubleshooting.md10.8 KiB
references/architecture.md
Architecture — Deep Dive
This reference covers Aspire's internal architecture: the DCP engine, resource model, service discovery, networking, telemetry, and the eventing system.
Developer Control Plane (DCP)
The DCP is the runtime engine that Aspire uses in aspire run mode. Key facts:
Written in Go (not .NET)
Exposes a Kubernetes-compatible API server (local only, not a real K8s cluster)
Manages resource lifecycle: create, start, health-check, stop, restart
Runs containers via the local container runtime (Docker, Podman, Rancher)
Runs executables as native OS processes
Handles networking via a proxy layer with automatic port assignment
Provides the foundation for the Aspire Dashboard's real-time data
DCP vs Kubernetes
| Aspect | DCP (local dev) | Kubernetes (production) |
|---|---|---|
| API | Kubernetes-compatible | Full Kubernetes API |
| Scope | Single machine | Cluster |
| Networking | Local proxy, auto ports | Service mesh, ingress |
| Storage | Local volumes | PVCs, cloud storage |
| Purpose | Developer inner loop | Production deployment |
The Kubernetes-compatible API means Aspire understands the same resource abstractions, but DCP is not a Kubernetes distribution — it's a lightweight local runtime.
Resource Model
Everything in Aspire is a resource. The resource model is hierarchical:
Type hierarchy
IResource (interface)
└── Resource (abstract base)
├── ProjectResource — .NET project reference
├── ContainerResource — Docker/OCI container
├── ExecutableResource — Native process (polyglot apps)
├── ParameterResource — Config value or secret
└── Infrastructure resources
├── RedisResource
├── PostgresServerResource
├── MongoDBServerResource
├── SqlServerResource
├── RabbitMQServerResource
├── KafkaServerResource
└── ... (one per integration)Resource properties
Every resource has:
Name — unique identifier within the AppHost
State — lifecycle state (Starting, Running, FailedToStart, Stopping, Stopped, etc.)
Annotations — metadata attached to the resource
Endpoints — network endpoints exposed by the resource
Environment variables — injected into the process/container
Annotations
Annotations are metadata bags attached to resources. Common built-in annotations:
| Annotation | Purpose |
|---|---|
EndpointAnnotation | Defines an HTTP/HTTPS/TCP endpoint |
EnvironmentCallbackAnnotation | Deferred env var resolution |
HealthCheckAnnotation | Health check configuration |
ContainerImageAnnotation | Docker image details |
VolumeAnnotation | Volume mount configuration |
CommandLineArgsCallbackAnnotation | Dynamic CLI arguments |
ManifestPublishingCallbackAnnotation | Custom publish behavior |
Resource lifecycle states
NotStarted → Starting → Running → Stopping → Stopped
↓ ↓
FailedToStart RuntimeUnhealthy
↓
Restarting → RunningDAG (Directed Acyclic Graph)
Resources form a dependency graph. Aspire starts resources in topological order:
PostgreSQL ──→ API ──→ Frontend
Redis ────────↗
RabbitMQ ──→ WorkerPostgreSQL, Redis, and RabbitMQ start first (no dependencies)
API starts after PostgreSQL and Redis are healthy
Frontend starts after API is healthy
Worker starts after RabbitMQ is healthy
.WaitFor() adds a health-check gate to the dependency edge. Without it, the dependency starts but the downstream doesn't wait for health.
Service Discovery
Aspire injects environment variables into each resource so services can find each other. No service registry or DNS is needed — it's pure environment variable injection.
Connection strings
For databases, caches, and message brokers:
ConnectionStrings__<resource-name>=<connection-string>Examples:
ConnectionStrings__cache=localhost:6379
ConnectionStrings__catalog=Host=localhost;Port=5432;Database=catalog;Username=postgres;Password=...
ConnectionStrings__messaging=amqp://guest:guest@localhost:5672Service endpoints
For HTTP/HTTPS services:
services__<resource-name>__<scheme>__0=<url>Examples:
services__api__http__0=http://localhost:5234
services__api__https__0=https://localhost:7234
services__ml__http__0=http://localhost:8000How .WithReference() works
var redis = builder.AddRedis("cache");
var api = builder.AddProject<Projects.Api>("api")
.WithReference(redis);This does:
Adds
ConnectionStrings__cache=localhost:<auto-port>to the API's environmentCreates a dependency edge in the DAG (API depends on Redis)
In the API service,
builder.Configuration.GetConnectionString("cache")returns the connection string
Cross-language service discovery
All languages use the same env var pattern:
| Language | How to read |
|---|---|
| C# | builder.Configuration.GetConnectionString("cache") |
| Python | os.environ["ConnectionStrings__cache"] |
| JavaScript | process.env.ConnectionStrings__cache |
| Go | os.Getenv("ConnectionStrings__cache") |
| Java | System.getenv("ConnectionStrings__cache") |
| Rust | std::env::var("ConnectionStrings__cache") |
Networking
Proxy architecture
In aspire run mode, DCP runs a reverse proxy for each exposed endpoint:
Browser → Proxy (auto-assigned port) → Actual Service (target port)port (the external port) — auto-assigned by DCP unless overridden
targetPort — the port your service actually listens on
All inter-service traffic goes through the proxy for observability
// Let DCP auto-assign the external port, service listens on 8000
builder.AddPythonApp("ml", "../ml", "main.py")
.WithHttpEndpoint(targetPort: 8000);
// Fix the external port to 3000
builder.AddViteApp("web", "../frontend")
.WithHttpEndpoint(port: 3000, targetPort: 5173);Endpoint types
// HTTP endpoint
.WithHttpEndpoint(port?, targetPort?, name?)
// HTTPS endpoint
.WithHttpsEndpoint(port?, targetPort?, name?)
// Generic endpoint (TCP, custom schemes)
.WithEndpoint(port?, targetPort?, scheme?, name?, isExternal?)
// Mark endpoints as externally accessible (for deployment)
.WithExternalHttpEndpoints()Telemetry (OpenTelemetry)
Aspire configures OpenTelemetry automatically for .NET services. For non-.NET services, you configure OpenTelemetry manually, pointing at the DCP collector.
What's auto-configured (.NET services)
Distributed tracing — HTTP client/server spans, database spans, messaging spans
Metrics — Runtime metrics, HTTP metrics, custom metrics
Structured logging — Logs correlated with trace context
Exporter — OTLP exporter pointing at the Aspire Dashboard
Configuring non-.NET services
The DCP exposes an OTLP endpoint. Set these env vars in your non-.NET service:
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317
OTEL_SERVICE_NAME=<your-service-name>Aspire auto-injects OTEL_EXPORTER_OTLP_ENDPOINT via .WithReference() for the dashboard collector.
ServiceDefaults pattern
The ServiceDefaults project is a shared configuration library that standardizes:
OpenTelemetry setup (tracing, metrics, logging)
Health check endpoints (
/health,/alive)Resilience policies (retries, circuit breakers via Polly)
// In each .NET service's Program.cs
builder.AddServiceDefaults(); // adds OTel, health checks, resilience
// ... other service config ...
app.MapDefaultEndpoints(); // maps /health and /aliveHealth Checks
Built-in health checks
Every integration adds health checks automatically on the client side:
Redis:
PINGcommandPostgreSQL:
SELECT 1MongoDB:
pingcommandRabbitMQ: Connection check
etc.
WaitFor vs WithReference
// WithReference: wires connection string + creates dependency edge
// (downstream may start before dependency is healthy)
.WithReference(db)
// WaitFor: gates on health check — downstream won't start until healthy
.WaitFor(db)
// Typical pattern: both
.WithReference(db).WaitFor(db)Custom health checks
var api = builder.AddProject<Projects.Api>("api")
.WithHealthCheck("ready", "/health/ready")
.WithHealthCheck("live", "/health/live");Eventing System
The AppHost supports lifecycle events for reacting to resource state changes:
builder.Eventing.Subscribe<ResourceReadyEvent>("api", (evt, ct) =>
{
// Fires when "api" resource becomes healthy
Console.WriteLine($"API is ready at {evt.Resource.Name}");
return Task.CompletedTask;
});
builder.Eventing.Subscribe<BeforeResourceStartedEvent>("db", async (evt, ct) =>
{
// Run database migrations before the DB resource is marked as started
await RunMigrations();
});Available events
| Event | When |
|---|---|
BeforeResourceStartedEvent | Before a resource starts |
ResourceReadyEvent | Resource is healthy and ready |
ResourceStateChangedEvent | Any state transition |
BeforeStartEvent | Before the entire application starts |
AfterEndpointsAllocatedEvent | After all ports are assigned |
Configuration
Parameters
// Plain parameter
var apiKey = builder.AddParameter("api-key");
// Secret parameter (prompted at run, not logged)
var dbPassword = builder.AddParameter("db-password", secret: true);
// Use in resources
var api = builder.AddProject<Projects.Api>("api")
.WithEnvironment("API_KEY", apiKey);
var db = builder.AddPostgres("db", password: dbPassword);Configuration sources
Parameters are resolved from (in priority order):
Command-line arguments
Environment variables
User secrets (
dotnet user-secrets)appsettings.json/appsettings.{Environment}.jsonInteractive prompt (for secrets during
aspire run)
Requirements and compatibility
Written for: GitHub Copilot
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an MCP server, Needs network access
Security
What our scanner noticed· Medium risk
- Instructions that use the network
- Downloads piped into a shell
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- First committed by
ChrisMcKee1
- Publisher
- GitHub (Official)
- Distributed by
- GitHub
- Source
- github/awesome-copilot · skills/aspire · commit 797337f
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
- Contributors
- ChrisMcKee1
AutoGineer is not affiliated with or endorsed by ChrisMcKee1 or GitHub.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download aspire.zip