Deploying .NET Aspire to Azure

Deploy your .NET Aspire application to Azure Container Apps in minutes using the Azure Developer CLI (azd). This guide covers the commands you need and the concepts interviewers ask about.

Key Takeaways

• azd up = full deploy (infrastructure + app) in one command
• azd provision deploys infra only; azd deploy deploys app only
• azd reads your azure.yaml — Aspire generates this automatically
• Use Key Vault + managed identity for secrets — never raw env vars in production

Prerequisites

Required tools:

• .NET 9.0 SDK (dotnet --version)
• Azure Developer CLI (brew tap azure/azd && brew install azd)
• Docker Desktop (must be running)
• Azure CLI (optional: brew install azure-cli)

Azure account:

• Subscription with Owner or Contributor role
• User Access Administrator role (for managed identity assignments)

Interview Angle

Interviewers ask: Why use azd instead of writing Bicep manually? Answer: azd reads the Aspire manifest and auto-generates Bicep. You get Infrastructure as Code without writing IaC — it’s generated from your AppHost configuration.

Initial Setup

Authenticate and verify

# Login to Azure
azd auth login

# Verify authentication
azd auth show

# Verify your project has azure.yaml (Aspire generates this)
cat azure.yaml

Your azure.yaml should reference your AppHost project — azd reads it to generate infrastructure templates.

Core azd Workflow

Full deployment (most common)

# Create development environment (first time only)
azd env new dev

# Full deployment: package → provision → deploy
azd up

That’s it. azd packages your containers, provisions all Azure resources, and deploys them.

Step-by-step workflow (when needed)

# Package app into containers
azd package

# Provision infrastructure only
azd provision

# Deploy app only
azd deploy

# Deploy specific service
azd deploy app

Interview Angle

Key insight: azd up = package + provision + deploy in one command. Interviewers love asking the difference between azd provision (infra only) vs azd deploy (app only) vs azd up (both). Know which to use for code-only changes (deploy) vs infrastructure changes (provision).

Environment Management

# Create environment
azd env new <name>

# List environments
azd env list

# Switch environment
azd env select <name>

# Set environment variable
azd env set KEY value

# View all variables
azd env get-values

Keep separate environments for dev/prod — switch between them with azd env select.

Dev vs Prod Deployment

Step	Development	Production
Create env	azd env new dev	azd env new prod
Set vars	Minimal — just ASPNETCORE_ENVIRONMENT=Development	Full: add JWT keys, database connections, etc.
Deploy	azd up (infra will be rebuilt)	azd up (same command, but infra is production-grade)
Secrets	Can use env vars	Must use Key Vault references
Teardown	azd down (safe to delete daily)	Never run azd down without backup

CI/CD with azd pipeline config

# Set up GitHub Actions or Azure DevOps
azd pipeline config

# Select your platform when prompted
# azd generates the workflow file automatically

Interview Angle

azd pipeline config wires GitHub Actions or Azure DevOps automatically — no YAML to hand-write. It reads your azure.yaml, generates the workflow, and configures environment-specific deployments. Interviewers often ask: How do you keep secrets safe in CI/CD? Answer: azd uses GitHub Secrets or Azure DevOps secrets, plus managed identity for Azure access — no hardcoded keys.

Monitoring & Logs

# View deployment info
azd show

# Open monitoring dashboard
azd monitor

# Stream application logs
azd monitor --logs

# Get detailed environment info
azd env get-values

Use azd monitor to open Application Insights — critical for production debugging.

Security Best Practices

Use Key Vault for secrets

# Store secrets in Azure Key Vault (never in env vars for production)
azd env set KEYVAULT_NAME your-vault-name

Configure your app to read from Key Vault using managed identity:

Azure.Extensions.AspNetCore.Configuration.Secrets

var keyVaultUrl = new Uri($"https://{keyVaultName}.vault.azure.net/");
config.AddAzureKeyVault(keyVaultUrl, new DefaultAzureCredential());

Managed identity (automatic)

# azd enables managed identity by default
# Your Container App gets an identity automatically
# Grant it Key Vault access in Azure Portal
# → Access Management → Add role assignment (Key Vault Secrets User)

Interview Angle

Classic interview question: How do you avoid secrets in environment variables? Answer: Use Azure Key Vault + managed identity. The Container App’s managed identity gets Key Vault access — no passwords anywhere. The identity is attached to the app; Azure handles the credentials behind the scenes.

Network & encryption

• Container Apps use SSL/TLS by default for data in transit
• Cosmos DB encryption at rest is enabled automatically
• Restrict Container Apps ingress: use internal ingress for internal services

Resource Commands Reference

# Environment management
azd env new <name>                 # Create environment
azd env select <name>              # Switch environment
azd env set KEY value              # Set variable

# Deployment
azd up                             # Full deployment
azd provision                      # Infrastructure only
azd deploy                         # Application only

# Monitoring
azd show                           # Show deployment info
azd monitor                        # Open Application Insights

# Infrastructure
azd infra gen                      # Generate Bicep files (review before prod)
azd down                           # Delete all resources

# CI/CD
azd pipeline config                # Set up GitHub Actions / Azure DevOps

Common Gotchas

• Docker must be running before azd up — it builds containers locally first. If Docker Desktop isn’t running, you’ll get a cryptic “container runtime” error.
• azd down deletes everything — including databases. Don’t run on production without backup. Always test on dev first.
• First deploy takes 10–15 minutes — infrastructure provisioning is slow. Subsequent deploys are much faster (2–3 min).
• Managed identity permissions take time to propagate — “access denied” errors right after deploy are usually transient. Wait 1–2 minutes and retry.
• Environment variables must be set before deploy — azd bakes them into the Container App during provisioning. Changing them later requires re-provisioning.

Quick Start Checklist

1. Run azd auth login
2. Run azd env new dev
3. Run azd up (first deploy takes ~15 min)
4. Test your app in Azure Portal or via the output endpoint
5. For production: azd env new prod → set secrets in Key Vault → azd up
6. Set up CI/CD: azd pipeline config
7. Monitor logs: azd monitor --logs

---

Need help? Check Application Insights logs via azd monitor. For deployment failures, run azd env get-values to verify all variables are set. Still stuck? The azd team maintains excellent docs.