Aspire separates publish (generate parameterized artifacts) from deploy (apply to an environment). With a tiny bit of code, you can hook into the publish pipeline, prompt for the target environment (dev/staging/prod), and stamp Docker image tags + .env accordingly—perfect for local packaging and CI pipelines.
Why this matters
Out-of-the-box, Aspire can publish for Docker, Kubernetes, and Azure. The aspire publish command generates portable, parameterized assets (e.g., Docker Compose + .env); aspire deploy then resolves parameters and applies changes—when the selected integration supports it. For Docker/Kubernetes, you typically publish and then deploy via your own tooling (Compose, kubectl, GitOps). Azure integrations (preview) add first-class deploy.
Supported targets (at a glance)
- Docker / Docker Compose → Publish ✅, Deploy ❌ (use generated Compose with your scripts).
- Kubernetes → Publish ✅, Deploy ❌ (apply with
kubectl/GitOps). - Azure Container Apps / App Service → Publish ✅, Deploy ✅ (Preview).
The workflow in practice
1. Generate artifacts
aspire publish -o artifacts/
For Docker, you’ll get artifacts/docker-compose.yml plus a parameterized .env.
2. Run those artifacts (Docker example)
docker compose -f artifacts/docker-compose.yml up --build
Provide required variables (shell export/.env/CI variables) before you run.
3. Or use aspire deploy when the integration supports it (Azure preview).
What Microsoft documents (and what they don’t)
Microsoft’s overview explains publish vs. deploy, the support matrix, and that artifacts contain placeholders intentionally—values are resolved later. The extensibility story (custom callbacks/annotations) exists but is thin; you’ll often reach for PublishingCallbackAnnotation / DeployingCallbackAnnotation to inject your own steps. This post shows one concrete, production-useful example.
