Microsoft Dev Box

Dev Box gives developers a managed, cloud-hosted Windows workstation - a complete desktop, not a browser IDE and not a Linux container. Platform teams define dev box definitions from Windows images, group them into pools attached to network connections, and developers self-serve machines from those pools. The machines join Microsoft Entra ID and enroll in Intune like any other corporate Windows device, so the management story is the one your endpoint team already runs.

That is a genuinely different product from the rest of this category, and the difference is the point. A Codespaces container cannot run a full Visual Studio installation, a Windows-only SDK, a desktop test harness, or a game engine editor. Dev Box can, because it is Windows all the way down. For .NET shops, desktop software vendors, and teams whose toolchain assumes a Windows GUI, that has been the only credible cloud development environment.

Two constraints follow from the design and neither is negotiable. It is Windows only - the documentation describes no Linux support, and the images are Windows 11 and Windows 10 Enterprise variants. And every user needs prerequisite licensing before Azure charges a single compute hour, which is the part budgets get wrong.

Read the last row as a cost line rather than an administrative note. Unlike every other product covered here, Dev Box has an entry requirement that is billed per user, per month, by a different part of the same vendor, and it applies whether or not anyone starts a machine. The Pricing section below treats it as the primary number rather than a footnote.

The prerequisite licensing, which is the number that usually decides it

Microsoft's documentation is explicit that each user needs a license for Windows 11 Enterprise or Windows 10 Enterprise, Microsoft Intune, and Microsoft Entra ID P1. Those are included in Microsoft 365 E3, E5, A3, A5, Business Premium, and the Microsoft 365 Education Student Use Benefit.

For an organization already standardized on E3 or E5, this is a non-event and the real cost is Azure compute. For an organization on lighter licensing, unlocking Dev Box means moving users onto a heavier Microsoft 365 plan, and that per-user, per-month delta - multiplied across an engineering organization, twelve months a year, whether or not anyone starts a machine - routinely exceeds the compute bill. This is what "true cost" means for this product, and it is the reason a comparison against an hourly Linux CDE that quotes only Azure rates is not a comparison at all.

How the Azure charges are structured

The sizes available run from 8 vCPU with 32 GB RAM up to 32 vCPU with 128 GB RAM, with storage tiers of 256, 512, 1,024, and 2,048 GB on premium SSD. There is no small, cheap size: the floor is a substantial machine, which is consistent with a product intended to replace a developer laptop rather than host a lightweight container.

One planning trap sits inside the hibernation feature. Hibernation is the main lever for keeping hourly costs down, and it is supported on the 8 and 16 vCPU sizes but not on 32 vCPU. The largest machines - exactly the ones where idle waste costs most - cannot use it. Build cost models on the size you will actually deploy, and see cost analysis and FinOps for development environments for the wider framework.

This is the section that should drive the decision, and for once the vendor has removed the guesswork entirely. Microsoft's Dev Box documentation states that the product retires at 17:00 UTC on 09-18-2028, that its closing-down period began at 16:00 UTC on 09-14-2026, and that Windows 365 is the recommended path forward for virtualized developer environments. Microsoft has published a dedicated retirement guide rather than the open-ended transition guidance it previously promised.

Be precise about what that does and does not mean, because the distinction matters commercially. Existing deployments remain supported through the transition period, so nothing breaks this quarter. But the question this page asked at the last review - whether the earlier maintenance-mode notice would become a shutdown - is now answered, and the answer is yes with a date attached. Microsoft's retirement guide says plainly that Dev Box will not be available after retirement and that remaining customer workloads should be expected to be deleted, and it advises against creating new long-lived dependencies on the service. Two years is enough runway for a planned migration and not enough to defer one.

One detail deserves weight before you assume the replacement is a swap. Microsoft states that its proposed alternatives "aren't one-to-one replacements", that each developer scenario should be validated before migrating, and that there is no automated migration tool. Windows 365 gives you persistent Cloud PCs managed through Intune and Entra ID, including 16-vCPU, 32-vCPU and GPU configurations and support for the Windows 11 developer configuration image - but the developer-workflow parity is yours to establish, not Microsoft's to guarantee.

There is a broader lesson worth carrying into any CDE decision. A product being generally available, actively documented, and sold by a large vendor tells you very little about whether it will still be receiving investment in two years. The durability question has to be asked deliberately, re-asked periodically, and asked of the vendor's documentation rather than its marketing pages - which is exactly where this notice appears and its pricing page does not mention it. See vendor evaluation, risk management, and the CDE market guide.