Beyond the Desktop: The Future of Development with Microsoft Dev Box and GitHub Codespaces

The modern developer platform has already moved past the desktop. We’re no longer defined by what’s installed on our laptops, instead we look at what tooling we can use to move from idea to production. An organisations developer platform strategy  is no longer a nice to have, it sets the ceiling for what’s possible, an organisation can’t iterate it's  way to developer nirvana if the foundation itself is brittle. A great developer platform shrinks TTFC (time to first commit), accelerates release velocity, and maybe most importantly, helps alleviate everyday frictions that lead to developer burnout.

Very few platforms deliver everything an organization needs from a developer platform in one product. Modern development spans multiple dimensions, local tooling, cloud infrastructure, compliance, security, cross-platform builds, collaboration, and rapid onboarding. The options organizations face are then to either compromise on one or more of these areas or force developers into rigid environments that slow productivity and innovation.

This is where Microsoft Dev Box and GitHub Codespaces come into play. On their own, each addresses critical parts of the modern developer platform:

• Microsoft Dev Box provides a full, managed cloud workstation. DevBox gives developers a consistent, high-performance environment while letting central IT apply strict governance and control. Internally at Microsoft, we estimate that usage of DevBox by our development teams delivers savings of 156 hours per year per developer purely on local environment setup and upkeep. We have also seen significant gains in other key SPACE metrics reducing context-switching friction and improving build/test cycles. Although the benefits of DevBox are clear in the results demonstrated by our customers it is not without its challenges. The biggest challenge often faced by DevBox customers is its lack of native Linux support. At the time of writing and for the foreseeable future DevBox does not support native Linux developer workstations. While WSL2 provides partial parity, I know from my own engineering projects it still does not deliver the full experience. This is where GitHub Codespaces comes into this story.
  
  
• GitHub Codespaces delivers instant, Linux-native environments spun up directly from your repository. It’s lightweight, reproducible, and ephemeral ideal for rapid iteration, PR testing, and cross-platform development where you need Linux parity or containerized workflows. Unlike Dev Box, Codespaces can run fully in Linux, giving developers access to native tools, scripts, and runtimes without workarounds. It also removes much of the friction around onboarding: a new developer can open a repository and be coding in minutes, with the exact environment defined by the project’s devcontainer.json. That said, Codespaces isn’t a complete replacement for a full workstation. While it’s perfect for isolated project work or ephemeral testing, it doesn’t provide the persistent, policy-controlled environment that enterprise teams often require for heavier workloads or complex toolchains.

Used together, they fill the gaps that neither can cover alone: Dev Box gives the enterprise-grade foundation, while Codespaces provides the agile, cross-platform sandbox. For organizations, this pairing sets a higher ceiling for developer productivity, delivering a truly hybrid, agile and well governed developer platform. 

Better Together: DevBox and GitHub Codespaces in action

Together, Microsoft Dev Box and GitHub Codespaces deliver a hybrid developer platform that combines consistency, speed, and flexibility. Teams can spin up full, policy-compliant Dev Box workstations preloaded with enterprise tooling, IDEs, and local testing infrastructure, while Codespaces provides ephemeral, Linux-native environments tailored to each project. 

One of my favourite use cases is having local testing setups like a Docker Swarm cluster, ready to go in either Dev Box or Codespaces. New developers can jump in and start running services or testing microservices immediately, without spending hours on environment setup. Anecdotally, my time to first commit and time to delivering “impact” has been significantly faster on projects where one or both technologies provide local development services out of the box.

Switching between Dev Boxes and Codespaces is seamless every environment keeps its own libraries, extensions, and settings intact, so developers can jump between projects without reconfiguring or breaking dependencies. The result is a turnkey, ready-to-code experience that maximizes productivity, reduces friction, and lets teams focus entirely on building, testing, and shipping software.

To showcase this value, I thought I would walk through an example scenario. In this scenario I want to simulate a typical modern developer workflow. Let's look at a day in the life of a developer on this hybrid platform building an IOT project using Python and React. 

• Spin up a ready-to-go workstation (Dev Box) for Windows development and heavy builds.
• Launch a Linux-native Codespace for cross-platform services, ephemeral testing, and PR work.
• Run "local" testing like a Docker Swarm cluster, database, and message queue ready to go out-of-the-box.
• Switch seamlessly between environments without losing project-specific configurations, libraries, or extensions.

9:00 AM – Morning Kickoff on DevBox

I start my day on my Microsoft DevBox, which gives me a fully-configured Windows environment with VS Code, design tools, and Azure integrations. I select my teams project, and the environment is pre-configured for me through the DevBox catalogue. Fortunately for me, its already provisioned. I could always self service another one using the "New DevBox" button if I wanted too. I'll connect through the browser but I could use the desktop app too if I wanted to.

My Tasks are:

• Prototype a new dashboard widget for monitoring IoT device temperature.
• Use GUI-based tools to tweak the UI and preview changes live.
• Review my Visio Architecture.
• Join my morning stand up.
• Write documentation notes and plan API interactions for the backend.

In a flash, I have access to my modern work tooling like Teams, I have this projects files already preloaded and all my peripherals are working without additional setup. Only down side was that I did seem to be the only person on my stand up this morning? 

Why DevBox first:

• GUI-heavy tasks are fast and responsive.
• DevBox’s environment allows me to use a full desktop.
• Great for early-stage design, planning, and visual work.
• Enterprise Apps are ready for me to use out of the box (P.S. It also supports my multi-monitor setup).

I use my DevBox to make a very complicated change to my IoT dashboard. Changing the title from "IoT Dashboard" to "Owain's IoT Dashboard". I preview this change in a browser live. (Time for a coffee after this hardwork). The rest of the dashboard isnt loading as my backend isnt running... yet.

10:30 AM – Switching to Linux Codespaces

Once the UI is ready, I push the code to GitHub and spin up a Linux-native GitHub Codespace for backend development.

Tasks:

• Implement FastAPI endpoints to support the new IoT feature.
• Run the service on my Codespace and debug any errors.

Why Codespaces now:

• Linux-native tools ensure compatibility with the production server.
• Docker and containerized testing run natively, avoiding WSL translation overhead.
• The environment is fully reproducible across any device I log in from.

12:30 PM – Midday Testing & Sync

I toggle between DevBox and Codespaces to test and validate the integration. I do this in my DevBox Edge browser viewing my codespace (This could be a second VS Code Desktop) and I use the same browser to view my frontend preview. I update the environment variable for my frontend that is running locally in my DevBox and point it at the port running my API locally on my Codespace. In this case it was a web socket connection and HTTPS calls to port 8000. I can make this public by changing the port visibility in my codespace.

• https://fluffy-invention-5x5wp656g4xcp6x9-8000.app.github.dev/api/devices
• wss://fluffy-invention-5x5wp656g4xcp6x9-8000.app.github.dev/ws

This allows me to:

• Preview the frontend widget on DevBox, connecting to the backend running in Codespaces.
• Make small frontend adjustments in DevBox while monitoring backend logs in Codespaces.
• Commit changes to GitHub, keeping both environments in sync and leveraging my CI/CD for deployment to the next environment.

We can see the DevBox running local frontend and the Codespace running the API connected to each other, making requests and displaying the data in the frontend!
 
Hybrid advantage:

• DevBox handles GUI previews comfortably and allows me to live test frontend changes.
• Codespaces handles production-aligned backend testing and Linux-native tools.
• DevBox allows me to view all of my files in one screen with potentially multiple Codespaces running in browser of VS Code Desktop.

Due to all of those platform efficiencies I have completed my days goals within an hour or two and now I can spend the rest of my day learning about how to enable my developers to inner source using GitHub CoPilot and MCP (Shameless plug).

The bottom line

There are some additional considerations when architecting a developer platform for an enterprise such as private networking and security not covered in this post but these are implementation details to deliver the described developer experience. Architecting such a platform is a valuable investment to deliver the developer platform foundations we discussed at the top of the article. While in this demo I have quickly built I was working in a mono repository in real engineering teams it is likely (I hope) that an application is built of many different repositories. The great thing about DevBox and Codespaces is that this wouldn’t slow down the rapid development I can achieve when using both. My DevBox would be specific for the project or development team, pre loaded with all the tools I need and potentially some repos too! When I need too I can quickly switch over to Codespaces and work in a clean isolated environment and push my changes. In both cases any changes I want to deliver locally are pushed into GitHub (Or ADO), merged and my CI/CD ensures that my next step, potentially a staging environment or who knows perhaps *Whispering* straight into production is taken care of. Once I’m finished I delete my Codespace and potentially my DevBox if I am done with the project, knowing I can self service either one of these anytime and be up and running again! 

Now is there overlap in terms of what can be developed in a CodeSpace vs what can be developed in Azure DevBox? Of course, but as organisations prioritise developer experience to ensure release velocity while maintaining organisational standards and governance then providing developers a windows native and Linux native service both of which are primarily charged on the consumption of the compute* is a no brainer. There are also gaps that neither fill at the moment for example Microsoft DevBox only provides windows compute while GitHub Codespaces only supports VS Code as your chosen IDE. It's not a question of which service do I choose for my developers, these two services are better together!

* Changes have been announced to DevBox pricing. A W365 license is already required today and devboxes will continue to be managed through Azure. For more information please see: Microsoft Dev Box capabilities are coming to Windows 365 - Microsoft Dev Box | Microsoft Learn