Skip to main content

Command Palette

Search for a command to run...

.NET Aspire Deployment: The Hidden Costs Nobody Tells You About

Updated
4 min read

I Needed My CRM to Scale Properly, So I Chose Microsoft Orleans with Aspire

I needed my CRM to scale properly, so I decided to use Microsoft Orleans in the infrastructure layer. With Aspire, you can scale each silo automatically.

Sounds great, right? But there's a catch.


Why Aspire is Worth It

Aspire was built to simplify deployment and deliver one of the best developer experiences Microsoft has created. In my opinion, it sits alongside ASP.NET Core and Microsoft Orleans as the best things Microsoft has shipped in years.

When you deploy with Aspire, the Azure Developer CLI (azd) generates a manifest file, creates Bicep infrastructure files, pushes container images to Azure Container Registry (ACR), and updates your Azure Container Apps with the new versions. All with a single command.

But if you deploy with default settings, several things will hit you hard in production.


The Difference Between Provisioning and Deploying

This is the first trap.

azd up does both provisioning AND deployment. If you run it again, it will replace your entire infrastructure and eliminate all your data. Be extremely careful with this command in production.

azd deploy is what you want for regular deployments. It only deploys your code changes without touching your infrastructure. Use this for your CI/CD pipelines after the initial setup.

The lesson here is simple: provision once, deploy many times.


Secrets Don't Persist by Default

Here's another gotcha that will waste hours of your time.

When you first run azd up, it prompts you for parameters and secrets. Those values get stored locally in ~/.aspire/deployments/{AppHostSha}/{environment}.json. The problem? Every time you deploy, you might need to reconfigure environment variables in the Azure portal.

The solution is using AddParameter with the secret: true flag. This creates proper parameter resources that persist across deployments. When combined with Azure Key Vault integration, your secrets remain stable between deployments instead of being regenerated or lost.

Additionally, using azd provision separately will prompt for secrets and store them in a local vault file, making subsequent azd deploy commands smoother.


The ACR Cost Explosion

Now let's talk about what will really kill your wallet: Azure Container Registry.

ACR has no free tier. Here's the pricing breakdown:

TierDaily CostMonthly CostStorage Included
Basic~$0.167~$510 GB
Standard~$0.667~$20100 GB
Premium~$1.66~$50500 GB

Here's where it gets ugly

Every single deploy creates a new container image. These images are stored for rollback purposes—or as I see it, it's Microsoft's way of making money from accumulated storage.

If you have multiple services in your Aspire solution (and you probably do), each one generates a new image on every deployment. Deploy 3 services twice a day for a month? That's 180 images. At the end of the month, you could easily have 10+ GB of space used in ACR.

And it doesn't stop there. The storage overage charges apply daily. Within 6 months, you could be paying up to 500% more than you expected.

This is a business. Always approach technology pragmatically.


How I Solved It

ACR has a feature called ACR Tasks that can run scheduled commands. You can create a purge task that automatically cleans up old images.

What I did is simple: every 6 hours, a scheduled task searches for all images in the ACR and deletes everything except the 3 most recent images per repository.

The command uses acr purge with these key parameters:

ParameterPurpose
--filter '*:.*'Target all repositories and tags
--ago 0dInclude all images regardless of age
--keep 3Retain only the 3 newest images
--untaggedAlso clean up orphaned manifests

You can run a dry-run first to see what would be deleted without actually removing anything. Once you're confident, schedule the task using a cron expression.

This approach has saved me significant money over time. In the long run, your wallet will thank you.


Final Thoughts

Aspire is an incredible technology for local development and cloud deployment. Azure Container Apps gives you serverless scaling with built-in Kubernetes (KEDA) for autoscaling based on CPU, memory, or custom events.

But remember:

  1. Use azd deploy for regular deployments, not azd up

  2. Configure your parameters properly with AddParameter to persist secrets

  3. Set up ACR purge tasks from day one to control storage costs

  4. Monitor your ACR usage regularly in the Azure Portal


The convenience of Aspire is real. The costs of not understanding these details are also very real.