Add Aspire FAQ

[BethMassi]

Aspire FAQ

Short version: Aspire is a code-first way to model a distributed application's services and relationships in an AppHost (in C# or TypeScript), run them together locally, observe them in a built-in dashboard, and carry the same app model into deployment workflows across existing stacks and clouds.

FAQ

What is Aspire?

Aspire is a code-first application model and tooling experience for distributed apps. It makes it easier to build, run, debug, and deploy services across any language, stack or cloud. It's free and open source github.com/microsoft/aspire. Its central idea is the AppHost: the place where you declare your services, resources, dependencies, endpoints, parameters, and relationships in code instead of scattering that information across many config files. AppHosts can be written in C# or TypeScript, which makes Aspire a strong fit for polyglot teams. Learn more: Build your first Aspire app

What problem does Aspire solve?

Aspire makes multi-service development easier to understand and operate. It reduces the friction of working on connected services. It gives teams one place to model the app, start related services together, wire dependencies, inspect telemetry, and reduce configuration drift across development and deployment workflows.

What is the AppHost, and why is it so important?

The AppHost is Aspire's control center. It's a map for all of the pieces of your distributed app and the single source of truth for your app's architecture: projects, containers, databases, endpoints, volumes, parameters, and the relationships between them. The same AppHost model is used across inner-loop development, local deployment, and release workflows. Learn more: What is the AppHost?

What does Aspire actually give me out of the box?

Aspire brings together four especially useful capabilities:

1. Code-first orchestration for your app's resources and relationships.
2. A dashboard for logs, metrics, traces, and resource health.
3. Opinionated defaults through integrations that handle service discovery, health checks, telemetry, and resilient communication.
4. A lifecycle-friendly, agent-friendly CLI for creating, running, publishing, deploying, inspecting, and troubleshooting apps.

Every part of the lifecycle can be inspected and automated by humans or agents.
Learn more: Aspire dashboard overview, CLI overview, Integrations gallery

What kinds of integrations does Aspire provide?

Aspire provides integrations for many of the building blocks that show up in real systems: databases, caches, messaging systems, storage services, observability backends, and cloud resources. These integrations help you model resources in the AppHost, connect services with references, and inject the right configuration such as connection strings, URLs, and environment variables automatically.
Learn more: Integrations gallery, aspire add

How do Aspire integrations fit with existing apps?

Integrations are additive. You can introduce them one by one as your system needs them, whether your app is new or already running in production. A common pattern is to model a shared resource such as PostgreSQL, Redis, or a message broker in the AppHost and then reference it from the services that need it.
Learn more: Integrations gallery, aspire init

What is the Aspire dashboard?

The dashboard is the most visible part of the developer experience, but it is not the whole story. When you run an Aspire app, the dashboard provides real-time visibility into resources, logs, metrics, traces, configuration, and health so you can understand how the system is behaving.
Learn more: Aspire dashboard overview

Can Aspire complement any stack, framework, or cloud?

Yes. Aspire is designed to complement the technologies you already use rather than requiring a rewrite into one framework or one cloud. It can orchestrate apps across many languages like C#, Python, JavaScript, Node.js, Go, and Java, and it supports a TypeScript AppHost. For deployment, it works through configured targets and integrations instead of requiring one proprietary hosting model.
Learn more: What is the AppHost?, Deployment overview

Is Aspire only for .NET apps?

No. .NET is an especially strong experience in Aspire, but the app model is broader than one framework or runtime. Aspire is designed to coordinate services across multiple stacks, and the TypeScript AppHost makes it a natural fit for existing JavaScript and TypeScript applications as well.
Learn more: TypeScript AppHost support

Can I write the AppHost in TypeScript?

Yes. A TypeScript AppHost (apphost.ts) is a first-class option for existing JavaScript and TypeScript applications. That experience uses commands such as aspire init --language typescript and AppHost APIs such as addNodeApp, addViteApp, and addJavaScriptApp.
Learn more: aspire init,TypeScript AppHost support

Is Aspire only for brand-new projects?

No. Aspire can be adopted incrementally. You can add an AppHost to an existing codebase, register the resources you already have, and bring the system under Aspire orchestration step by step without rewriting everything at once.
Learn more: aspire init

How is Aspire different from Docker Compose?

The simplest confident answer is: Docker Compose is container-first YAML; Aspire is app-model-first code. Compose focuses on describing containers and their runtime settings. Aspire focuses on describing the whole distributed application and its relationships, then layering in orchestration, service discovery, integrations, telemetry, and dashboard-driven insight. That said, Docker is one of the many computing environments Aspire supports and can publish Docker YAML artifacts. Learn more: Docker integration, Aspire app lifecycle guide

How does Aspire compare to Pulumi, Terraform, or Bicep?

These tools are best thought of as complements, not competitors:

• Pulumi / Terraform / Bicep focus on provisioning and managing infrastructure resources and cloud environments.
• Aspire focuses on modeling the application itself: its services, dependencies, orchestration, discovery, telemetry, and developer workflow.

A good practical framing is: use Aspire to build, run, debug, and deploy the application topology, while IaC tools only provision environment and platform resources.
Learn more: Aspire app lifecycle guide

How does Aspire compare to Kubernetes?

Kubernetes is a production orchestration platform. Aspire is an application model and developer workflow that helps you describe, connect, and observe your services. Aspire is not a one-for-one Kubernetes replacement; it is an application composition experience that can feed real deployment targets, like Kubernetes.
Learn more: Deployment overview

How does Aspire compare to Dapr or other service-runtime frameworks?

Dapr provides runtime building blocks such as pub/sub, bindings, state, and service invocation. Aspire focuses on application composition, orchestration, integration wiring, and observability. They address different layers of the problem and can be used together when that combination makes sense.
Learn more: Dapr integration

Does Aspire replace Docker Compose, Kubernetes, or my deployment platform?

No. Aspire helps you model, run, observe, publish, and deploy distributed apps, but you still choose the actual compute environments and deployment targets that fit your platform strategy.
Learn more: Deployment overview, aspire deploy

How does Aspire fit into the development-to-production lifecycle?

Aspire supports a consistent lifecycle:

1. aspire run for inner-loop development and debugging.
2. aspire deploy for deployment to configured compute environments.
3. aspire publish and related CI/CD steps for release artifacts and deployment workflows.

The key idea is that the same AppHost configuration flows across these stages.
Learn more: Aspire app lifecycle guide, aspire run, aspire deploy, aspire publish

What commands matter most when introducing Aspire?

If you want the shortest useful list, start with these:

• aspire new - create a new Aspire app
• aspire init - initialize Aspire in an existing codebase
• aspire init --language typescript - create a TypeScript AppHost for JS/TS apps
• aspire add - add hosting integrations
• aspire run - run the AppHost for development
• aspire deploy - deploy to configured targets
• aspire publish - generate deployment artifacts
• aspire logs, aspire docs, and aspire doctor - inspect, learn, and troubleshoot

Learn more: CLI overview, aspire init, aspire run

Is the deployment manifest still recommended?

No. The deployment manifest is deprecated. The current path is to use aspire publish and aspire deploy with supported deployment targets and workflows.
Learn more: aspire publish, aspire deploy

How should humans and agents talk about Aspire confidently without overclaiming?

Prefer language like this:

• "Aspire is an agent-ready, code-first tool to compose, debug and deploy any distributed app."
• "Aspire is code-first and relationship-aware."
• "Aspire improves local orchestration, observability, and service-to-service wiring."
• "Aspire complements existing stacks, frameworks, clouds, and workflows."
• "Aspire supports C# and TypeScript AppHosts."
• "Aspire carries the same application model across development and deployment workflows."

Avoid vague hype like:

• "Aspire replaces everything in your platform."
• "Aspire is only a dashboard."
• "Aspire only works for brand-new .NET apps."

What should an agent say if it is not fully sure about a deployment or integration detail?

Use a safe answer like this:

"Based on the Aspire docs, the core model is the AppHost plus dashboard, service defaults, and CLI-driven lifecycle workflows. For the exact deployment target or integration behavior, we should verify the specific integration docs before making a stronger claim."

Recommended site blurb

Aspire is an agent-ready, code-first tool to compose, debug and deploy distributed apps. You define services and dependencies in an AppHost written in C# or TypeScript, get built-in observability through the dashboard, and use the same application model across development, deployment, and release workflows while complementing your existing stack, cloud, and tools.

Further reading

• What is the AppHost?
• Build your first Aspire app
• Aspire dashboard overview
• Integrations gallery
• CLI overview
• aspire init
• aspire run
• aspire deploy
• aspire publish

[BethMassi]

To be answered next

• What compute environments are officially supported today, and which ones are GA vs preview?
• Can Aspire deploy to Kubernetes, Azure Container Apps, AWS, GCP, or on-prem, and what is first-class vs custom?
• Do I need containers to use Aspire, or can it orchestrate local processes too?
• What's the difference between the AppHost, integrations, and Service Defaults?
• How do secrets, parameters, and environment variables flow from AppHost to apps and deployments?
• Is the dashboard just for local development, or is there a production and security story for it?
• How does Aspire handle front-end apps in production, especially Vite, React, and Next.js scenarios?
• What does "agent-ready" mean in practice—what can agents inspect, control, or automate?
• When is Aspire not the right choice?
• How much code has to change to adopt Aspire incrementally in an existing app?