Microsoft Dev Box
Full Windows workstations in Azure, with prerequisite licensing that usually dominates the true cost. Microsoft has now placed the product in maintenance mode and is pointing new work at Windows 365.
What It Is
Managed cloud desktops for developers, running real Windows rather than a container
Read this before anything else on the page. Microsoft's own documentation for Dev Box carries a maintenance-mode notice stating that no additional features are planned, that Microsoft's investments for developer cloud environments are focused on Windows 365, and that customers should consider Windows 365 as the recommended path forward for virtualized developer environments. It adds that Dev Box remains supported for existing usage and that transition guidance will be provided.
Verify it yourself before making a decision, because it changes the shape of the evaluation entirely: learn.microsoft.com - what is Microsoft Dev Box. Checked July 2026.
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.
A real desktop
Anything that runs on Windows runs here, including GUI tooling that no container-based CDE can host.
Managed like an endpoint
Entra ID and Intune enrollment means compliance policy, conditional access, and patching use the tooling you already operate.
Hibernation, conditionally
Hibernated dev boxes accrue no compute charge, but hibernation is supported only on the 8 and 16 vCPU sizes - not on 32 vCPU.
Who It Suits, and Who It Does Not
The maintenance-mode notice narrows this considerably, and it should
Still defensible
- Existing Dev Box customers with working deployments. Support continues, and there is no announced shutdown date to react to.
- Teams whose entire justification is Windows GUI tooling, and who have already confirmed Windows 365 does not cover the scenario.
- Organizations already holding the prerequisite Microsoft 365 licensing, where the marginal cost is compute rather than a licensing program.
- Short-horizon needs, such as contractor onboarding, where a two-year platform bet is not being made.
A poor fit
- Anyone starting a new multi-year standardization. Adopting a product whose vendor recommends a different product is a hard position to defend later.
- Linux or macOS development. There is no Linux support, and containers are not the unit here.
- Organizations without the prerequisite licensing, who would be buying a Microsoft 365 program to unlock a product in maintenance mode.
- Teams needing self-hosting, another cloud, or an air-gapped deployment. Dev Box is Azure-only with no alternative.
- Buyers who need a public price to build a business case. The pricing page does not show figures without signing in.
The recommendation, stated plainly
If you are evaluating Dev Box today and you are not already running it, the first call should be to Microsoft about Windows 365 rather than to a procurement process about Dev Box. That is not this page being contrarian - it is repeating what Microsoft's own documentation says. If you already run Dev Box, there is no emergency: it remains supported, no end date has been published, and a considered migration on your own schedule beats a rushed one. But start the conversation now rather than when a deadline appears.
Deployment Model
Fully managed Azure service, with the image and identity work left to you
| Concern | You operate | Microsoft operates |
|---|---|---|
| Control plane | Nothing. No self-hosted or bring-your-own-cloud option exists. | Provisioning, scaling, availability, the whole service |
| Images and definitions | Dev box definitions, custom images, preinstalled toolchains, image maintenance | Marketplace base images and the runtime that boots them |
| Identity and device management | Entra ID configuration, Intune policy, conditional access, compliance rules | Enrollment plumbing and enforcement |
| Networking | Network connections, virtual network design, on-premises connectivity | The remote desktop path to the machine |
| Licensing | Acquiring and maintaining the per-user prerequisites, in full | Nothing. This is entirely your obligation. |
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.
License and Open Source Reality
Proprietary throughout, and here that extends to the operating system itself
Nothing here is open
Dev Box is a proprietary Azure service. There is no source, no community edition, and no self-hosted distribution. This is the least ambiguous entry in this directory: there is nothing to evaluate on open source grounds because nothing is offered.
The licensing goes deeper than the service
Elsewhere in this category, a proprietary control plane still runs your portable Linux image. Here the environment is Windows Enterprise, which is itself licensed per user. Even a perfectly executed exit leaves you re-solving how developers get a licensed Windows desktop, which is a procurement problem rather than a packaging one.
The practical consequence is that portability advice which works elsewhere does not transfer. Keeping a dev container definition is excellent hygiene and buys you very little if the reason you are here is that your toolchain needs a Windows GUI. Where automation is possible, put image builds and pool configuration in declarative infrastructure code so the setup is reproducible against whatever succeeds it.
Pricing
The compute rates are not public. The licensing prerequisites are, and they usually matter more.
No SKU rates are published here, deliberately. Fetched without signing in, every price cell on the Azure Dev Box pricing page renders as the literal placeholder $-. Max monthly price, hourly compute, and monthly storage are all blank until you sign in and select a region. Any article quoting exact Dev Box SKU rates as a public figure is reporting something that page does not show. Get your numbers from the signed-in Azure pricing calculator for your own region and agreement: azure.microsoft.com - Dev Box pricing. Checked July 2026.
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.
The F3 asterisk matters and is frequently dropped. Microsoft 365 F3 appears in the list of qualifying editions, but the documentation's own footnote states that F3 does not include a Windows Enterprise license, only limited Entra ID and Intune capabilities. A frontline-worker plan is therefore not sufficient on its own. Confirm the exact entitlement per user group before budgeting: learn.microsoft.com - configure the Dev Box service.
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
Two billing models
A predictable monthly price per dev box instance covering unlimited use of that instance for the billing month, or hourly pay-as-you-go. The two meet at the same ceiling.
The cap is automatic
When a dev box's total for the month - hourly compute plus its monthly storage - reaches that instance's max monthly price, billing stops for the rest of the month. Hourly usage cannot overshoot the monthly figure.
Storage runs regardless
Storage is billed from creation until the dev box is removed, prorated hourly. Hibernating stops compute charges but not storage, and only deletion ends it.
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.
Architecture and Isolation
One virtual machine per developer, managed as a corporate endpoint
A dev box is a dedicated Windows virtual machine assigned to one developer, backed by premium SSD storage, joined to Entra ID and enrolled in Intune. The isolation boundary is therefore the strongest in this directory by default - a full VM per person, not a container sharing a kernel - and the management model is identical to a physical corporate laptop, which is why endpoint and security teams tend to approve it quickly.
Endpoint controls apply
Conditional access, compliance policy, disk encryption, and patch management come from Intune and Entra ID rather than from a separate CDE-specific control surface.
Network placement is yours
Network connections attach dev boxes to your virtual network, which is how access to on-premises or private Azure resources is arranged. Design that deliberately rather than accepting a default.
Heavy units, slow cycles
A full Windows VM does not start in seconds and is not disposable. Ephemeral, per-branch environments are not the workflow this product is built around.
Strong isolation, wrong economics for agent workloads
A dedicated Windows VM is a robust place to run untrusted code and an absurd one to run thousands of short agent tasks in. The unit is too large, too slow to provision, and too expensive per invocation. If that is the workload, look at sandbox environments, microVM isolation, and the E2B and Daytona reviews rather than at a desktop product.
Status and Durability
Maintenance mode, with Windows 365 named as the path forward
This is the section that should drive the decision, and for once the vendor has removed the guesswork. Microsoft's Dev Box documentation states that the product is in maintenance mode with no additional features planned, that its investments for developer cloud environments are focused on Windows 365, and that customers should consider Windows 365 as the recommended path forward for virtualized developer environments. It also states that Dev Box remains supported for existing usage and that transition guidance will be provided.
Be precise about what that does and does not mean, because the distinction matters commercially. No end-of-life date has been published. Existing deployments keep working and keep being supported. This is not the same as a shutdown announcement, and treating it as one would be an overreaction. What it does mean is that the feature roadmap has stopped, and that a vendor recommending a different product is the single clearest durability signal available.
If you are evaluating
Evaluate Windows 365 instead, and use Dev Box only if a specific capability gap forces it. Then document why, because that reasoning is what a future review will ask for.
If you already run it
Do not panic-migrate. Ask Microsoft for the transition guidance the notice promises, get support horizon commitments in writing at your next renewal, and plan on your own timeline.
The pattern to notice
AWS closed Cloud9, then CodeCatalyst. Microsoft has now put Dev Box into maintenance mode. Cloud-provider developer environments have proven notably less durable than their marketing implied.
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.
Related
Alternatives to evaluate instead, and the frameworks for the decision
Self-Hosted vs Managed
The decision this page sits inside, before you compare any two products
Google Cloud Workstations
The equivalent cloud-native trade, still generally available and actively shipping
GitHub Codespaces
The other Microsoft-owned answer, if your toolchain can live in a Linux container
Ona (formerly Gitpod)
A cloud-neutral managed option, with its own unresolved ownership question
All CDE Tools
The full field, including which products have been discontinued or closed to new customers
Cost Analysis
Building a total cost model that includes per-user licensing, not only compute hours
Risk Management
Planning for maintenance mode, deprecation, and vendor redirection before they arrive
Vendor Evaluation
Reading vendor documentation rather than marketing pages for durability signals
CDE Market Guide
How much this category has churned, and which vendors are still investing
Sources and Citations
Every figure on this site with its publisher, date, and link