.NET Aspire — Custom Publish & Deployment Pipelines

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.

Continue reading “.NET Aspire — Custom Publish & Deployment Pipelines”

From Aspire to Docker Compose in one command

One of my favorite Aspire tricks is publishing your local orchestration to a plain Docker Compose file. No bespoke YAML hand-crafting: define your resources in C#, run one command, and get a production-shaped compose you can run anywhere Docker is available.

This post shows a tiny demo that publishes PostgreSQL, Redis, and the Aspire Dashboard to Docker Compose.

AppHost: enable the Docker publisher

var builder = DistributedApplication.CreateBuilder(args);

// Enables Docker publisher (gives the compose project a stable name)
builder.AddDockerComposeEnvironment("aspire-docker-demo");

var postgres = builder.AddPostgres("database")
    .WithDataVolume();

var database = postgres.AddDatabase("demo-db");

var redis = builder.AddRedis("cache");

builder. Build().Run();

What this does

  • AddDockerComposeEnvironment("aspire-docker-demo")
    Opts the app into the Docker publisher and sets the Compose project name (used for networks, volume names, etc.).
  • Postgres + volume
    WithDataVolume() ensures a named Docker volume is created for data durability.
  • AddDatabase("demo-db")
    Declares a logical DB (helpful when apps bind to it; not strictly needed for Compose output).
  • Redis
    Adds a simple cache service.

Publish to Docker Compose

From the AppHost directory:

aspire publish -o docker-compose-artifacts

This generates a docker-compose.yaml (and related files) under ./docker-compose-artifacts/.

Continue reading “From Aspire to Docker Compose in one command”

Website Powered by WordPress.com.

Up ↑