How Microsoft is changing Windows Developer workstations

When I wrote WinGet and Beyond on LeanPub, I knew WinGet wasn't done for some time. There was still a promise to be made. And that promise comes in the form of a new Microsoft-backed project.

Every Windows Developer knows that package management is the entry point for software development projects. That's why the Windows Developer Config announcement caught my attention. During the Microsoft Build 2026 keynote, Kayla Cinnamon presented it for the first time. For me, it immediately connected the story that's been going around for a while now and is something I've shared for a while now:

Bootstrapping a developer workstation should be a repeatable declaration, not a task you do over the weekend.

Developer workstations aren't just laptops. They can have your personal terminal settings, the required software for the project, or other preferences that make you productive.

That's why I was glad to see the repository getting open-sourced. It feels like Microsoft is moving towards that vision to back Windows developers for what they have already wanted for a long time: making development on Windows easy to reproduce and enjoyable out-of-the-box.

In this post, I want to give a quick introduction to the project and what it configures.

The (old) dream: Any machine can become your machine

Okay, let's take a step back. Package management is not new. There have been many solutions available in the market, like Chocolatey for Windows. But this post is not about Chocolatey. It's about WinGet, even though WinGet hasn't been around as long as Chocolatey has. Plus, WinGet isn't a package management tool only anymore.

The idea mentioned in the introduction has been there already for a while. You, as a developer, shouldn't be reading through a wiki page with steps to set up a project. Instead, it should be just a simple process that's repeatable. When you launch a fresh Windows box, it should just install.

Unfortunately, that's harder than it sounds. Apps come from package managers. OS settings live in the registry. And terminal settings live in JSON.

The Windows Developer Config accepts that complexity. The project leverages winget configure and DSC-style configuration files as the mechanism to apply such configuration. And if you know DSC, it's going to have that declarative shape of things by saying: here is the desired state with the resources I need, and for the rest, just take care of it.

That is the bridge from package management to workstation configuration. WinGet can install software, but Windows Developer Config shows how WinGet Configuration and DSC can describe a complete developer environment. So what does that actually mean if you look at the repository?

What Windows Developer Configurations are

Just borrowing it directly from the README file from the project that describes Windows Developer Configurations:

Opinionated setups for Windows dev boxes.

The beauty lies within the repository itself, as all setups are CI-tested. The repository also currently groups its work into three main experiences.

The first is a full Windows Dev Config. This is literally a monstrous configuration file and turns a fresh Windows 11 box into a developer workstation. It installs PowerShell 7, Git, GitHub CLI, VS Code, .NET, Python, uv, Node.js, Oh My Posh, PowerToys, and WSL with Ubuntu. It also applies defaults: dark theme, Developer Mode, long path support, cleaner File Explorer settings, Start and Search cleanup, Edge policies, Windows Terminal defaults, and Cascadia Nerd Fonts.

The second is WSL Comfort Shell. It's what was shown during Build by Kayla and can be used on the Windows or Linux side. On Windows, it handles WSL, Ubuntu, fonts, and a Windows Terminal profile. For Linux, it will be zsh or bash with Starship and other CLI tools (like ripgrep, fd, and more).

Lastly, the third one is a set of single-language workloads. You can also see them as personas in my eyes. From TypeScript to PowerShell, there's a wide variety you can select from. Each workload will always have its own configuration.winget file. This is helpful when you want to have only a clean machine with the particular configuration for a specific programming language.

The shift to declaring desired state

What also stands out to me is the direction of travel. Most Windows developers often use installation scripts and store them at the root of the repository. They have their purpose, but are hard to maintain (especially if the project grows over time).

Windows Developer Config(s) does it differently and brings it to desired state configuration (DSC). Packages are declared through different resources, like Microsoft.WinGet/Package or Microsoft.Windows/Registry. Each of those resources does a particular task, and the logic you normally write down in a script just sits underneath.

For example, the following resource configures dark theme mode:

# =============================================================================
# Force dark theme
# Uses app and system theme registry values to detect dark theme.
# =============================================================================
- type: Microsoft.DSC.Transitional/PowerShellScript
  name: darkTheme
  dependsOn:
    - PowerShell
  properties:
    getScript: |
      $regPath = 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\Personalize'
      $apps   = Get-ItemPropertyValue $regPath -Name AppsUseLightTheme    -EA SilentlyContinue
      $system = Get-ItemPropertyValue $regPath -Name SystemUsesLightTheme -EA SilentlyContinue
      return @{ AppsUseLightTheme = [int]$apps; SystemUsesLightTheme = [int]$system }
    testScript: |
      $regPath = 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\Personalize'
      $apps   = Get-ItemPropertyValue $regPath -Name AppsUseLightTheme    -EA SilentlyContinue
      $system = Get-ItemPropertyValue $regPath -Name SystemUsesLightTheme -EA SilentlyContinue
      return ($apps -eq 0 -and $system -eq 0)
    setScript: |
      $regPath = 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\Personalize'
      Set-ItemProperty -Path $regPath -Name "AppsUseLightTheme" -Value 0
      Set-ItemProperty -Path $regPath -Name "SystemUsesLightTheme" -Value 0
  metadata:
    description: Sets dark theme

Okay, the above example just defeated a bit what I said on manual script writing. But that's because there isn't a native resource that works with the Windows Settings. However, this shows what happens underneath.

With such configurations stored in your own repository, you only have to ask the question "is the machine already in the state we want?" It makes it super simple for new contributors to run if their system isn't in the desired state.

Why Microsoft backing matters

You know when Microsoft backs a project that something is up. And it also shows that it is serious about its delivery and commitment.

When a Microsoft-owned repository says that WinGet Configurations, DSC resources, and other developer toolchains come together in one workstation story, it not only gives individuals but also enterprises a pattern that they can follow, knowing that it will get supported.

The repository shows pieces coming together, as they've felt separate sometimes. See, WinGet is the orchestrator. DSC resources are what configure the system. And then you have WSL and Windows Terminal.

That's the bigger change I see here. I will not be surprised if more and more projects start to look at Windows Developer Config and adopt it so they have a "declare this developer environment." Even though the difference is subtle, for newcomers, you know you'll get a standardized environment.

A good direction for Windows developers

The project is fresh in my personal opinion; I don't think every developer wants exactly this configuration. And honestly, that's fine. The project being opinionated is the part that makes it useful.

What makes it strong is the fact that it gives you a default that you can run. Or you can inspect it, fork it, and change it how you want it. What matters the most is that pattern: a Windows development workstation expressed as code. And that's all backed by WinGet, DSC, and a CI that tests them.

For me, seeing the Windows Developer Config directly goes back to my story that I cared about while I was writing WinGet and Beyond. WinGet is not a simple CLI. It's becoming a part of the Windows ecosystem for configuration purposes. This new project only shows that it's becoming realer.

If this is where Microsoft is taking developer workstations, I'm glad to see it.