Generated banner for Aspire
Generated logo for Aspire

Aspire

GitHubOfficialFirst committed by ChrisMcKee1Distributed by GitHub

  • Skill
  • Tool integration
  • Software development
  • MIT
  • Medium risk

From the author

Aspire skill covering the Aspire CLI, AppHost orchestration, service discovery, integrations, MCP server, VS Code extension, Dev Containers, GitHub Codespaces, templates, dashboard, and deployment. Use when the user asks to create, run, debug, configure, deploy, or troubleshoot an Aspire distributed application.
— the description by ChrisMcKee1

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

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/github/aspire/download
  2. Unzip 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

ReferenceWhen to load
CLI ReferenceCommand flags, options, or detailed usage
MCP ServerSetting up MCP for AI assistants, available tools
Integrations CatalogDiscovering integrations via MCP tools, wiring patterns
Polyglot APIsMethod signatures, chaining options, language-specific patterns
ArchitectureDCP internals, resource model, service discovery, networking, telemetry
DashboardDashboard features, standalone mode, GenAI Visualizer
DeploymentDocker, Kubernetes, Azure Container Apps, App Service
TestingIntegration tests against the AppHost
TroubleshootingDiagnostic 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.

If running Aspire CLI 13.2 or later (aspire --version), the MCP server includes docs search tools:

ToolDescription
list_docsLists all available documentation from aspire.dev
search_docsPerforms weighted lexical search across indexed documentation
get_docRetrieves 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:

ToolDescription
list_integrationsLists available Aspire hosting integrations
get_integration_docsGets 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".

RankLibrary IDUse when
1/microsoft/aspire.devPrimary source. Guides, integrations, CLI reference, deployment.
2/dotnet/aspireAPI internals, source-level implementation details.
3/communitytoolkit/aspireNon-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/aspire

  • Samples repo: dotnet/aspire-samples

  • Community integrations: CommunityToolkit/Aspire


2. Prerequisites & Install

RequirementDetails
.NET SDK10.0+ (required even for non-.NET workloads — the AppHost is .NET)
Container runtimeDocker 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.ProjectTemplates

3. Project Templates

TemplateCommandDescription
aspire-starteraspire new aspire-starterASP.NET Core/Blazor starter + AppHost + tests
aspire-ts-cs-starteraspire new aspire-ts-cs-starterASP.NET Core/React starter + AppHost
aspire-py-starteraspire new aspire-py-starterFastAPI/React starter + AppHost
aspire-apphost-singlefileaspire new aspire-apphost-singlefileEmpty 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)

ConceptKey point
Run vs Publishaspire run = local dev (DCP engine). aspire publish = generate deployment manifests.
Service discoveryAutomatic via env vars: ConnectionStrings__<name>, services__<name>__http__0
Resource lifecycleDAG ordering — dependencies start first. .WaitFor() gates on health checks.
Resource typesProjectResource, ContainerResource, ExecutableResource, ParameterResource
Integrations144+ across 13 categories. Hosting package (AppHost) + Client package (service).
DashboardReal-time logs, traces, metrics, GenAI visualizer. Runs automatically with aspire run.
MCP ServerAI assistants can query running apps and search docs via CLI (STDIO).
TestingAspire.Hosting.Testing — spin up full AppHost in xUnit/MSTest/NUnit.
DeploymentDocker, Kubernetes, Azure Container Apps, Azure App Service.

6. CLI Quick Reference

Valid commands in Aspire CLI 13.1:

CommandDescriptionStatus
aspire new <template>Create from templateStable
aspire initInitialize in existing projectStable
aspire runStart all resources locallyStable
aspire add <integration>Add an integrationStable
aspire publishGenerate deployment manifestsPreview
aspire configManage configuration settingsStable
aspire cacheManage disk cacheStable
aspire deployDeploy to defined targetsPreview
aspire do <step>Execute a pipeline stepPreview
aspire updateUpdate integrations (or --self for CLI)Preview
aspire mcp initConfigure MCP for AI assistantsStable
aspire mcp startStart the MCP serverStable

Full command reference with flags: CLI Reference.


7. Common Patterns

Adding a new service
  1. Create your service directory (any language)

  2. Add to AppHost: Add*App() or AddProject<T>()

  3. Wire dependencies: .WithReference()

  4. Gate on health: .WaitFor() if needed

  5. Run: aspire run

Migrating from Docker Compose
  1. aspire new aspire-apphost-singlefile (empty AppHost)

  2. Replace each docker-compose service with an Aspire resource

  3. depends_on → .WithReference() + .WaitFor()

  4. ports → .WithHttpEndpoint()

  5. environment → .WithEnvironment() or .WithReference()


8. Key URLs

Files

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
AspectDCP (local dev)Kubernetes (production)
APIKubernetes-compatibleFull Kubernetes API
ScopeSingle machineCluster
NetworkingLocal proxy, auto portsService mesh, ingress
StorageLocal volumesPVCs, cloud storage
PurposeDeveloper inner loopProduction 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:

AnnotationPurpose
EndpointAnnotationDefines an HTTP/HTTPS/TCP endpoint
EnvironmentCallbackAnnotationDeferred env var resolution
HealthCheckAnnotationHealth check configuration
ContainerImageAnnotationDocker image details
VolumeAnnotationVolume mount configuration
CommandLineArgsCallbackAnnotationDynamic CLI arguments
ManifestPublishingCallbackAnnotationCustom publish behavior
Resource lifecycle states
NotStarted → Starting → Running → Stopping → Stopped
                 ↓                     ↓
          FailedToStart           RuntimeUnhealthy
                                       ↓
                                  Restarting → Running
DAG (Directed Acyclic Graph)

Resources form a dependency graph. Aspire starts resources in topological order:

PostgreSQL ──→ API ──→ Frontend
Redis ────────↗
RabbitMQ ──→ Worker
  1. PostgreSQL, Redis, and RabbitMQ start first (no dependencies)

  2. API starts after PostgreSQL and Redis are healthy

  3. Frontend starts after API is healthy

  4. 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:5672
Service 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:8000
How .WithReference() works
var redis = builder.AddRedis("cache");
var api = builder.AddProject<Projects.Api>("api")
    .WithReference(redis);

This does:

  1. Adds ConnectionStrings__cache=localhost:<auto-port> to the API's environment

  2. Creates a dependency edge in the DAG (API depends on Redis)

  3. In the API service, builder.Configuration.GetConnectionString("cache") returns the connection string

Cross-language service discovery

All languages use the same env var pattern:

LanguageHow to read
C#builder.Configuration.GetConnectionString("cache")
Pythonos.environ["ConnectionStrings__cache"]
JavaScriptprocess.env.ConnectionStrings__cache
Goos.Getenv("ConnectionStrings__cache")
JavaSystem.getenv("ConnectionStrings__cache")
Ruststd::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 /alive

Health Checks

Built-in health checks

Every integration adds health checks automatically on the client side:

  • Redis: PING command

  • PostgreSQL: SELECT 1

  • MongoDB: ping command

  • RabbitMQ: 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
EventWhen
BeforeResourceStartedEventBefore a resource starts
ResourceReadyEventResource is healthy and ready
ResourceStateChangedEventAny state transition
BeforeStartEventBefore the entire application starts
AfterEndpointsAllocatedEventAfter 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):

  1. Command-line arguments

  2. Environment variables

  3. User secrets (dotnet user-secrets)

  4. appsettings.json / appsettings.{Environment}.json

  5. Interactive 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
GitHub avatar of ChrisMcKee1ChrisMcKee1
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