Since lesson 3.2.5, the Kladde has been delivered with azd, and with its own infrastructure from infra/: azd deploys main.bicep and then rolls out
the images. The AppHost supplies only the projects and the template of the Container App web. 3.2.5 also had a paragraph on the second way,
aspire deploy, and why the Kladde stays with azd. This lesson walks the second way once all the way through, compares what it produces, and writes
down the decision so that someone will still understand it in a year.
What becomes of the model when you publish it
When you publish, the AppHost doesn’t run; it describes. What comes out is determined by the environment the model is delivered to:
| Environment in the AppHost | Package | what comes out |
|---|---|---|
AddAzureContainerAppEnvironment("cae") |
Aspire.Hosting.Azure.AppContainers |
Bicep: Container Apps environment, registry, identities, roles, one Container App per project |
AddDockerComposeEnvironment("compose") |
Aspire.Hosting.Docker |
docker-compose.yaml and an .env with the open values |
| Kubernetes, App Service | further Aspire.Hosting.… packages |
manifests or Bicep for those targets |
Since Aspire 9.4, the environment has to be in the AppHost (3.2.5). The earlier way of publishing with “publishers” of their own no longer exists.
Two commands of the Aspire CLI lead into publishing. aspire publish writes the files into a folder, aspire-output by default, and leaves
open values open; another tool or a person applies them later. aspire deploy produces the same, fills in the values and delivers directly.
aspire --help in version 13.6.5 shows both commands (and aspire do) with the label “preview”. You don’t have to switch them on; they’re there. The
label means that their behavior may still change between versions.