Aspire
Learn and apply .NET Aspire architecture—DCP, resources, and local-vs-K8s deployment—while orchestrating multi-service apps with your agent.
Overview
Aspire is an agent skill most often used in Build (also Ship, Operate) that explains .NET Aspire’s DCP engine, resource model, and local-vs-Kubernetes deployment architecture.
Install
npx skills add https://github.com/github/awesome-copilot --skill aspireWhat is this skill?
- Explains Developer Control Plane (DCP): Go-based local engine with Kubernetes-compatible API
- Resource model hierarchy from IResource through ProjectResource and containers
- DCP vs Kubernetes comparison for inner loop vs production deployment
- Service discovery, networking proxy, and Aspire Dashboard telemetry context
- Clarifies DCP is not a full Kubernetes distribution—local lightweight runtime
- DCP vs Kubernetes 5-row comparison table in reference
Adoption & trust: 8.7k installs on skills.sh; 34.6k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are adopting .NET Aspire but the DCP, resource types, and production Kubernetes story feel opaque when wiring services locally.
Who is it for?
.NET indie developers orchestrating multiple services with Aspire AppHost who need architecture context while coding or reviewing design.
Skip if: Teams not using .NET, one-file scripts with no distributed services, or operators who only need generic Docker Compose without Aspire.
When should I use this skill?
User is building or debugging .NET Aspire apps and needs DCP, resource model, or deployment architecture context.
What do I get? / Deliverables
You can reason about Aspire resources, local DCP runtime behavior, and what shifts for cluster deployment before changing AppHost or infra code.
- Architecture explanations aligned to Aspire components
- DCP versus K8s deployment guidance
- Resource hierarchy mental model for AppHost edits
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Aspire is where distributed .NET services are modeled and run locally; build/backend is the first commitment point before ship and operate concerns. Backend subphase fits service composition, ProjectResource wiring, and the Developer Control Plane runtime that backs APIs and workers.
Where it fits
Map which Aspire resources back your API and worker before adding Redis or Postgres containers.
Explain to yourself what must change when moving from DCP auto-ports to Kubernetes ingress and PVCs.
Connect Aspire Dashboard telemetry concepts to why a resource fails health checks locally.
How it compares
Architecture reference for Aspire’s control plane—not a substitute for official Aspire templates or a generic cloud IaC skill.
Common Questions / FAQ
Who is aspire for?
Solo and small-team .NET builders using Aspire to run and compose APIs, workers, and dependencies in local dev with a path toward Kubernetes.
When should I use aspire?
In Build while modeling AppHost resources; in Ship when comparing DCP local runs to K8s deployment; in Operate when tracing service discovery, ports, or dashboard telemetry issues.
Is aspire safe to install?
It is documentation-style guidance; check the Security Audits panel on this page and follow Microsoft’s official Aspire releases for anything that executes on your machine.
SKILL.md
READMESKILL.md - Aspire
# 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 → 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__<reso