aspire
codewithmukesh/dotnet-claude-kit
Orchestrate cloud-native .NET services locally with AppHost, service discovery, and integrated observability.
What is aspire?
.NET Aspire provides local development orchestration for multi-service .NET applications, handling service discovery, resource configuration (databases, caches, message brokers), and observability via the Aspire dashboard. Use it when building microservices or multi-project solutions that need coordinated startup, health checks, and tracing.
- Orchestrate AppHost to start services, databases, and infrastructure together in local development
- Configure service defaults (OpenTelemetry, health checks, resilience) once and apply across all services
- Manage service-to-service communication and discovery without hardcoding connection strings
- Integrate PostgreSQL, Redis, RabbitMQ, SQL Server, and other resources with automatic health checks and tracing
- Generate deployment assets (docker-compose, Kubernetes manifests) via `aspire publish` or deploy directly to Azure Container Apps
- Observe local development with the Aspire dashboard for tracing, logging, and metrics
How to install aspire
npx skills add https://github.com/codewithmukesh/dotnet-claude-kit --skill aspireHow to use aspire
- 1.Create an AppHost project and define your infrastructure resources (databases, caches, brokers) using `builder.AddPostgres()`, `builder.AddRedis()`, etc.
- 2.Create a ServiceDefaults project with shared configuration (OpenTelemetry, health checks, resilience) and call `builder.AddServiceDefaults()` in each service
- 3.Add your application projects to the AppHost using `builder.AddProject<>()` and link them with `.WithReference()` to share connection strings and enable service discovery
- 4.Configure each service to use Aspire integrations (e.g., `builder.AddNpgsqlDbContext<AppDbContext>()`) instead of hardcoded connection strings
- 5.Run the AppHost with `dotnet run` to start all services, databases, and the Aspire dashboard together
- 6.For production, use `aspire publish` to generate docker-compose or Kubernetes manifests, or `aspire deploy` for Azure Container Apps
Use cases
- Setting up a multi-service microservices architecture with coordinated local development
- Configuring PostgreSQL, Redis, and RabbitMQ for a .NET application without manual connection strings
- Implementing service-to-service HTTP communication with automatic service discovery
- Generating production deployment manifests from your Aspire app model
- Monitoring local development with OpenTelemetry tracing and metrics in the Aspire dashboard
- Backend engineers building multi-service .NET applications
- DevOps engineers setting up local development environments for teams
- Architects designing cloud-native .NET solutions
- Teams migrating from manual orchestration to Aspire-managed infrastructure
aspire FAQ
No. The AppHost is a dev/build-time orchestrator only. Use `aspire publish` to generate deployment manifests (docker-compose, Kubernetes) or `aspire deploy` for Azure Container Apps; deploy those artifacts instead.
Aspire's built-in service discovery allows you to use DNS names like `https+http://service-name` as the base address. The AppHost and ServiceDefaults handle registration and resolution automatically.
ServiceDefaults configures OpenTelemetry (logging, metrics, tracing), health checks, service discovery, and HTTP resilience policies. Call `builder.AddServiceDefaults()` in each service to apply these consistently.
Aspire is optional for single-project apps; `dotnet run` works fine. Aspire shines with multi-service architectures where you need coordinated startup and service discovery.
The Aspire dashboard is automatically configured and accessible when you run the AppHost. It shows tracing, logging, and metrics for all services without additional setup.
Full instructions (SKILL.md)
Source of truth, from codewithmukesh/dotnet-claude-kit.
name: aspire description: > .NET Aspire for cloud-native orchestration. Covers AppHost configuration, service defaults, resource configuration, service discovery, and the Aspire dashboard. Load this skill when setting up local development orchestration, service discovery, or Aspire-managed infrastructure, or when the user mentions "Aspire", "AppHost", "service defaults", "service discovery", "orchestration", "Aspire dashboard", "AddProject", "WithReference", or "cloud-native .NET".
.NET Aspire
Core Principles
- AppHost orchestrates; it is never deployed itself — Aspire's core job is the local development experience: starting services, databases, and message brokers together. Modern Aspire also generates deployment assets (
aspire publishfor docker-compose/Kubernetes manifests,aspire deployfor Azure Container Apps) — but the AppHost process itself stays a dev/build-time tool, not a production runtime. - Service defaults are your baseline — The
ServiceDefaultsproject configures OpenTelemetry, health checks, and resilience for all services in one place. - Use Aspire integrations — Aspire has built-in integrations for PostgreSQL, Redis, RabbitMQ, SQL Server, and more. They handle connection strings, health checks, and tracing automatically.
- The dashboard is your observability tool — Use the Aspire dashboard for local development tracing, logging, and metrics instead of setting up Seq/Grafana locally.
Patterns
AppHost Configuration
// AppHost/Program.cs
var builder = DistributedApplication.CreateBuilder(args);
// Infrastructure resources
var postgres = builder.AddPostgres("postgres")
.WithPgAdmin()
.AddDatabase("myappdb");
var redis = builder.AddRedis("redis")
.WithRedisInsight();
var rabbitmq = builder.AddRabbitMQ("messaging")
.WithManagementPlugin();
// Application projects
var api = builder.AddProject<Projects.MyApp_Api>("api")
.WithReference(postgres)
.WithReference(redis)
.WithReference(rabbitmq)
.WithExternalHttpEndpoints();
var worker = builder.AddProject<Projects.MyApp_Worker>("worker")
.WithReference(postgres)
.WithReference(rabbitmq);
builder.Build().Run();
Service Defaults
// ServiceDefaults/Extensions.cs — Standard Aspire service defaults
// Configures OpenTelemetry (metrics + tracing), health checks, service discovery, and resilience
public static class Extensions
{
public static IHostApplicationBuilder AddServiceDefaults(this IHostApplicationBuilder builder)
{
builder.ConfigureOpenTelemetry();
builder.AddDefaultHealthChecks();
builder.Services.AddServiceDiscovery();
builder.Services.ConfigureHttpClientDefaults(http =>
{
http.AddStandardResilienceHandler();
http.AddServiceDiscovery();
});
return builder;
}
// ConfigureOpenTelemetry: adds logging, metrics (ASP.NET, HttpClient, Runtime),
// tracing (ASP.NET, HttpClient, EF Core), and OTLP exporter if configured
// AddDefaultHealthChecks: adds a "self" liveness check tagged ["live"]
}
Using Service Defaults in a Project
// MyApp.Api/Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();
// Add Aspire integrations
builder.AddNpgsqlDbContext<AppDbContext>("myappdb");
builder.AddRedisDistributedCache("redis");
var app = builder.Build();
app.MapDefaultEndpoints(); // health check endpoints
app.Run();
Service-to-Service Communication
// AppHost — configure service references
var orderApi = builder.AddProject<Projects.OrderApi>("order-api");
var paymentApi = builder.AddProject<Projects.PaymentApi>("payment-api")
.WithReference(orderApi); // paymentApi can discover orderApi
// In PaymentApi — use service discovery
builder.Services.AddHttpClient<OrderClient>(client =>
{
client.BaseAddress = new Uri("https+http://order-api");
});
Solution Structure with Aspire
MyApp.slnx
├── MyApp.AppHost/ # Aspire orchestrator
│ └── Program.cs
├── MyApp.ServiceDefaults/ # Shared service configuration
│ └── Extensions.cs
├── src/
│ ├── MyApp.Api/ # Web API project
│ └── MyApp.Worker/ # Background worker
└── tests/
└── MyApp.Api.Tests/
Anti-patterns
Don't Deploy the AppHost Process
// BAD — running the AppHost executable in production as an orchestrator
// The AppHost is a dev/build-time tool, not a production runtime
// GOOD — deploy the generated assets, not the AppHost:
// aspire publish → docker-compose / Kubernetes manifests from the app model
// aspire deploy → direct deployment (e.g., Azure Container Apps)
Don't Hardcode Connection Strings with Aspire
// BAD — hardcoding connection strings defeats Aspire's purpose
builder.Services.AddDbContext<AppDbContext>(o =>
o.UseNpgsql("Host=localhost;Database=myapp;..."));
// GOOD — use Aspire integration (connection string injected automatically)
builder.AddNpgsqlDbContext<AppDbContext>("myappdb");
Don't Skip Service Defaults
// BAD — manually configuring each service
builder.Services.AddOpenTelemetry()...
builder.Services.AddHealthChecks()...
// GOOD — use shared service defaults
builder.AddServiceDefaults();
Decision Guide
| Scenario | Recommendation |
|---|---|
| Local dev with multiple services | Aspire AppHost |
| Single-project local dev | dotnet run is fine, Aspire optional |
| Shared service configuration | ServiceDefaults project |
| Database for local dev | Aspire AddPostgres() / AddSqlServer() |
| Service discovery | Aspire's built-in service discovery |
| Production deployment | aspire publish (compose/K8s manifests) or aspire deploy (ACA); never the AppHost itself |
| Observability in local dev | Aspire dashboard (auto-configured) |
Related skills
More from codewithmukesh/dotnet-claude-kit and the wider catalog.

authentication
JWT, OpenID Connect, and policy-based authorization for ASP.NET Core APIs and web apps.

build-fix
Autonomous iteration loops that drive broken .NET builds and failing tests to green with bounded retries and fail-safe guards.

caching
HybridCache and output caching strategies for .NET 10 applications with stampede protection.

checkpoint
Mid-session save point: commit progress and write a handoff note before risky changes or task switches.

ci-cd
CI/CD pipelines for .NET with GitHub Actions and Azure DevOps YAML workflows.

clean-architecture
4-layer .NET architecture with dependency inversion, domain-driven design, and use-case handlers.