Hey everyone! I’m collecting concrete examples of where better Windows support in Nix would make a difference for people and teams.
If this is relevant to you, I’d love to hear:
What would you want to build or do?
What’s difficult or blocking you today?
Are you using Nix through WSL, interested in native Windows support, or looking to build Windows software from another platform?
Personal projects, team workflows, and organizational use cases are all useful. If you’ve wanted to adopt Nix but Windows requirements got in the way, that’s especially helpful to understand.
No roadmap or promises here just trying to understand the needs and where improvements would matter most.
Reply here, or DM me if you’d rather keep details private. Even a short “we’d use this for X” helps!
I did try to convince a former employer to use it instead of ansible. I doubt i would have been successful regardless, but not working on windows certainly didn’t make it easier. Pretending i had been able to push it, some magical thing that could
Configure IIS
Define registry keys
Set up schedules
Configure MS SQLServer
Would have gone a long way. That being said a better approach for that particular situation would have been to just ditch windows instead so maybe don’t take this too seriously. I also think it’s a bit of a minefield since those are very stateful things, and any attempt might involve a huge amount of work and still no declarative guarantees - I guess very much like ansible. It’s such a potential quagmire.
I did use it unauthorized on WSL for a while, but the retirement of the last .net framework piece made me able to just switch to Nixos instead. Maybe working on better documented mono/.net core for nixos would be the real treassure that was inside us all along.
I.e., I’m using the GNU Emacs 30.2 (build 2, x86_64-w64-mingw32) of 2025-08-14 emacs version at the workplace, native nix would be a great enhancement for sure. Right now it is scoop I use to manage tools (aspell and sorts).
Sure I have a NixOS-WSL in heavy use, but WSL still sucks at some points (RDP for WSLg is one big itch) and it is extra maintenance to use in a really integrated manner, like I really only use it inside wezterm (that is always in reach obviously, also installed via scoop).
In a past job, we had to port a large’ish application (mostly C++ & CMake) to various platforms that are only served by proprietary, binary-only compilers (think clang forks with vendor secret-sauce layered over them), that only worked on Windows. Hostile tools, in a hostile environment.
The project was pure-Nix from the start - native Linux builds, and pkgsCross.mingwW64 for Windows builds, and I’d have much preferred to do these proprietary-platform builds there too. I’d done custom CMake platforms for everything, and could’ve integrated this all with Nix nicely…if it ran on Windows.
Interestingly… Windows support provides a really powerful moat. It is generally accepted in the Windows ecosystem to have fully-encompassing solutions/ides/environments/tools that manage your development process. So Nix needing somewhat full adoption is a natural fit… it just needs to work. Next step is to find a niche… some development domain where a nice user-experience can be Nix-driven and be adopted - not because the people like Nix, but because Nix is the path by which they achieve ( embdeded development / gaming mods / self-hosted AI / random niche music editing toolkit / easy interoperability with server-side data processing / whatever). Find that thing, and expand from there.
Hi Ron, Nix is directly relevant to our workflow. We want to leverage it to create consistent development environments and build standalone .exe applications using Hydra without requiring /nix/store at runtime of the application.
We considered WSL, but decided against it to avoid the long-term maintenance overhead and technical debt of eventually migrating off it. While native Windows support for Nix isn’t fully available yet, DigitalBrewStudios is eager to collaborate on and continually contributing to the goal of native Windows development (such as porting tools like perl to MinGW).
Enabling native Windows support would allow us to contribute more actively to the Nix ecosystem and help drive its adoption in small businesses and potential educational settings.