Aspire DeploymentCAUTION

An Aspire reference architecture for cloud-native microservices and agentic AI with MCP, A2A & AG-UI

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: aspire-deployment
description: '**WORKFLOW SKILL** — Deploy Aspire apps from AppHost models to Docker Compose, Kubernetes, Azure, AWS, or preview Radius. WHEN: "deploy Aspire app", "publish Aspire artifacts", "deploy to Azure Container Apps", "generate Kubernetes artifacts", "deploy to Radius", "tear down Aspire deployment". INVOKES: aspire CLI, Aspire docs, target cloud/container CLIs. FOR SINGLE OPERATIONS: use generic Azure, Kubernetes, Docker, AWS, or Radius tools only when no Aspire AppHost exists.'
license: MIT
metadata:
  author: Microsoft
  version: "0.0.3"
---

# Aspire Deployment

Use this skill when the task is to publish, preview, validate, deploy, or tear down an Aspire application deployment. This skill owns Aspire deployment routing. Do not start with a generic Azure, Docker, Kubernetes, Helm, or Bicep workflow until you have checked whether the workspace is an Aspire app.

Aspire deployment starts from the AppHost model. Treat `aspire deploy`, `aspire publish`, `aspire destroy`, `aspire do`, and the deployment environment resources in the AppHost as the primary path. Use stable SDK/hosting packages from the project's release family and matching preview builds for preview-only integrations such as Kubernetes and Radius.

Keep this as one skill with target-specific references. Load only the reference files that match the target you discover or the user requests.

## Routing precedence

This skill wins over generic cloud deployment skills when both conditions are true:

1. The user asks to deploy, publish, generate deployment artifacts, create Bicep/Helm/Compose/CDK output, host on Azure or AWS, deploy to Azure, AWS, Kubernetes, Docker Compose, or Radius, tear down deployed resources, or validate a deployment.
2. The workspace has Aspire markers:
   - Aspire workspace configuration
   - C# or TypeScript AppHost files
   - an AppHost project
   - AppHost code using Aspire distributed application builder APIs

If Aspire markers are present but this skill was not automatically invoked, switch to this skill before continuing. Prefer Aspire CLI commands such as `aspire ls`, `aspire config list`, `aspire ps`, and `aspire describe` for workspace orientation.

## Guiding principles

### Use Aspire docs before changing deployment code

Before adding target packages, editing the AppHost, or using an unfamiliar deployment API, use Aspire docs:

```bash
aspire docs search "deploy with Aspire"
aspire docs search "Docker Compose deployment"
aspire docs search "Kubernetes deployment"
aspire docs search "Azure Container Apps deployment"
aspire docs search "Azure App Service deployment"
aspire docs search "Azure Kubernetes Service deployment"
aspire docs search "Radius deployment"
aspire docs get "deploy-to-azure-kubernetes-service-aks"
aspire docs get "<slug-from-search-results>"
```

When you need exact C# or TypeScript API shape, use API docs too. Search both languages when you are not sure which AppHost language the repo uses:

```bash
aspire docs api search "<deployment API or concept>" --language csharp
aspire docs api search "<deployment API or concept>" --language typescript
aspire docs api get "<id-from-api-search>"
```

Do not invent package names, builder methods, overloads, or deployment commands. API shapes differ between C# and TypeScript AppHosts.

### Prefer Aspire-native deployment

Deploy the resources declared in the AppHost, not the AppHost process itself.
For Docker Compose, configure the Compose environment and let Aspire generate services
for those resources; do not replace this with an AppHost Dockerfile or Compose service.

Use Aspire deployment targets and CLI commands first:

```bash
aspire publish --list-steps
aspire deploy --list-steps
aspire publish
aspire deploy
aspire destroy
aspire do <step>
```

Use target-specific tooling only after Aspire has generated artifacts or when the target docs call for it:

- Docker Compose: inspect generated `aspire-output/docker-compose.yaml` and `.env*`; Aspire can also run `docker compose up` through `aspire deploy`.
- Kubernetes: inspect generated Helm chart output; use Helm/kubectl when applying published artifacts yourself.
- Azure: use `aspire add <azure-target>`, `aspire publish`, and `aspire deploy` through the AppHost deployment environment.
- AWS: use `aspire add aws` to add the integration, inspect generated CDK/CloudFormation output, and follow the AWS integrations repository guidance.
- Radius: treat `Aspire.Hosting.Radius` as preview. Use integration/docs search to verify
  the package and API, then model `AddRadiusEnvironment(...).WithNamespace(...)`.

### Ask where to deploy only when ambiguous

Do not ask for target selection when the user already chose a target such as Docker Compose, Kubernetes, Azure Container Apps, Azure App Service, Azure Kubernetes Service (AKS), or AWS. Use the chosen target and continue with its reference.

If the user did not explicitly choose a deployment target and the AppHost does not already contain exactly one deployment environment, ask where they want to deploy before adding integrations, editing the AppHost, publishing artifacts, or deploying. Use a single multiple-choice question:

> Where do you want to deploy this Aspire app?

Show these choices:

| Choice                         | Aspire add command               | Use when                                                                                                      |
| ------------------------------ | -------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Docker Compose                 | `aspire add docker`              | The user wants local/server container deployment artifacts for Docker or Podman.                              |
| Kubernetes                     | `aspire add kubernetes`          | The user has an existing Kubernetes cluster and wants Helm/Kubernetes artifacts or direct cluster deployment. |
| Az

CAUTIONgrade C · trust 79/100 Install with care. The audit found things worth knowing before you trust its output.

What the source does

Filesystem

none-observed

Network

declared (2 observation(s))

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (3)

Explain when resources exist only locally or only in publish/deploy mode. If a resource is behind a run-mode-only branch, do not tell the user it will deploy.

curl -sSL https://aspire.dev/install.sh | bash

run: curl -sSL https://aspire.dev/install.sh | bash

Gates applied: instruction_override, no_behavioural_pass.