-
We are scaling our .NET applications and our build times are hitting the 60-minute mark on Microsoft-hosted agents. I’m considering switching to self-hosted agents on Azure VMs to speed things up and save on costs. Is the maintenance overhead of managing your own VM worth the performance gains, or are there better ways to optimize the hosted agents for high-frequency CI/CD
3 answers
Choosing between agent types depends entirely on your build complexity and security needs. Microsoft-hosted agents are great because they are zero-maintenance and always have a fresh image, but they lack persistent caching. If your build spends 20 minutes just downloading NuGet packages, a self-hosted agent with a persistent tool cache will cut your build time significantly. However, remember you’ll be responsible for patching the OS and updating the agent software. For our enterprise clients, we usually use self-hosted agents for production builds to ensure static IPs for firewall whitelisting.
Have you looked into the "Scale Set Agents" feature in Azure DevOps? It's a hybrid approach where you manage an Azure Virtual Machine Scale Set, and Azure DevOps automatically scales the number of machines up and down based on your pipeline demand. Wouldn't that solve your overhead concerns while still giving you the performance of a dedicated VM?
For .NET builds, the bottleneck is usually I/O. Self-hosted agents on Premium SSDs will always outperform the standard hosted agents. The speed boost is definitely worth the setup time.
Exactly, Barbara. We switched to self-hosted on D-series VMs and saw a 40% reduction in build duration. The local cache for Docker layers alone makes a massive difference in deployment speed.
James, that’s a brilliant suggestion! I hadn't considered VMSS agents yet. Do you know if we can still use Docker-in-Docker with that setup, or does it complicate the image configuration? We rely heavily on containerized builds, so having that flexibility while maintaining the "auto-scale" benefit would be the ideal middle ground for our current DevOps infrastructure.