I have to say this is nice packaging. It is weirdly not obvious how nice it is to cleanly use a different “machine” inside your desktop.
I never thought I’d prefer WSL to even my MacBook for working with remote servers and dev but somehow I do.
I of course know the many ways to roll something like this for myself, yes dev containers are better for many things etc. but it’s wierd how good the ergonomics of a WSL like container are.
Thanks for saying so! That's exactly why I wrote this. The UX of wsl2 is just right. There are a lot of other ways to accomplish this, but none touch that same experience.
I'm confused why VM + systemd-nspawn? From my understaing WSL 2 runs a single VM + something like systemd-nspawn per "linux installation", but it runs a VM because it needs linux kernel. Why not just do systemd-nspawn if you alread on linux?
Way better isolation, is my guess. Plus, you can use a different kernel this way.
I used to poo-poo when people said that containers aren't a _real_ security boundary, at least for personal stuff, and not a multi-tenant server. But I bet even mid-tier LLMs can break out of LXC/Docker/nspawn at this point.
"During a test conducted by Trail of Bits researcher Artem Dinaburg, a preview version of GPT 5.6-Cyber was tasked with breaking out of a Debian 12 virtual machine. Initially, the agent exploited a known Linux kernel vulnerability, CVE-2026-53359, by developing its own exploit. After the host was updated, the agent found another pathway through libslirp, chaining a known vulnerability (CVE-2026-9539) with a previously unassigned bug to gain arbitrary host memory access. Even after QEMU and libslirp were updated, the agent analyzed system components and constructed a new escape chain using three zero-day vulnerabilities and one KVM flaw that had not yet reached the distribution kernel.
These findings suggest that general-purpose VMs may not be adequate security boundaries for highly capable AI agents, especially in older systems with delayed security updates. Trail of Bits recommends using specialized isolation systems like Firecracker, restricting VM access, and implementing rapid patching to mitigate these risks."
I'd trust OP to make good architectural decisions/provide guidance even if AI mostly wrote the docs and UI. Looking into their GitHub, seems they are an engineering manager at Microsoft and contribute semi regularly to uBlue and Project Bluefin. Should be better quality than some random vibeslopper.
It makes an image and runs it in separate namespace. It can start at bash or init. It's very fast but there seem to be a problem creating an Ubuntu image on Debian and vice versa.
Distrobox mounts $HOME in the container at $HOME by default. WSL and NSL do not, and that's my preference. This means you can install tools that change your default path, change your dotfiles, etc, without affecting the host. The other obvious difference is that distrobox is powered by podman or docker, while NSL uses a VM that runs systemd-nspawn containers.
The name WSL has always struck me as a bit back area (LSW would seem to make more sense, since it is a Linux subsystem for Windows). I guess they mean it as a Windows Subsystem for Linuxing.
Anyway, should this be called LSL or WSLL? Or maybe LSWSL.
The naming is a bit awkward now, but an original design goal of the Windows NT kernel was the ability to host different types of OS "personalities" (userspace, essentially) on top of the Windows kernel, and these are called "subsystems." Win32 is one such subsystem, although there was no need to formally call it "Windows Subsystem for Win32" because everyone understood that it was just Win32 ported to NT.
The NT kernel designers came from VMS, and during development MS made various half-hearted promises that NT would be able to run VMS software as well but never actually followed through. If they had, there would likely have been a Windows Subsystem for VMS.
Nope. This is a VM, with containers inside. And the containers weren't "re-implemented", it uses existing systemd containers. That's what I was able to learn by skimming the site for 30 seconds. Did you not even do that? And why even be so condescending to someone else's project?
Because it does seem like we already have tools that skin this particular cat, it's valid to wonder what value this project provides over existing solutions.. even if they chose the wrong example to compare it to. Why do you think that's condescending?
LXC is a jail and qemu is an extra layer of emulation. Why pay that extra cost? Just because it serves a wsl image isn't really an answer. How is that worth the extra layer?
This is most useful to people who run Linux as their daily driver so rather than saying its like WSL can you explain what it offers that existing Linux containers do not?
Its also sounds different from WSL which I thought is a VM rather than a container.
> It's yet another step in my long journey to keep my host installation free from all the changing and breaking dev dependencies that force a reinstall every few months.
Something that also require a bit of explanation. What do you do that makes this such a common problem.
WSL2 uses a shared VM that does host integration (networking, shared files, permanent storage for each instance). NSL uses the same model but with Linux native technical implementations.
As for keeping my host clean - it's the developer's curse that always gets me. Install libWhatever3.2-dev because you need it to compile something, then don't realize until next time you open Chrome that it broke your system in some subtle way. There are dozens of ways to solve this like devcontainers, docker, incus, fully separate or remote vms. I like the WSL2 model so I wanted that same UX.
So a single VM with multiple containers within it? Interesting, but I think you should make it immediately clear on your site. Persistence is not the USP because there are lots of ways that you can get persistent VMs or sandboxes.
none of the above. a single vm started by systemd-vmspawn which then starts one or more containers for your instances using systemd-nspawn. It ends up being fast and lightweight.
I have to say this is nice packaging. It is weirdly not obvious how nice it is to cleanly use a different “machine” inside your desktop.
I never thought I’d prefer WSL to even my MacBook for working with remote servers and dev but somehow I do.
I of course know the many ways to roll something like this for myself, yes dev containers are better for many things etc. but it’s wierd how good the ergonomics of a WSL like container are.
Thanks for saying so! That's exactly why I wrote this. The UX of wsl2 is just right. There are a lot of other ways to accomplish this, but none touch that same experience.
I'm confused why VM + systemd-nspawn? From my understaing WSL 2 runs a single VM + something like systemd-nspawn per "linux installation", but it runs a VM because it needs linux kernel. Why not just do systemd-nspawn if you alread on linux?
Way better isolation, is my guess. Plus, you can use a different kernel this way.
I used to poo-poo when people said that containers aren't a _real_ security boundary, at least for personal stuff, and not a multi-tenant server. But I bet even mid-tier LLMs can break out of LXC/Docker/nspawn at this point.
can they not break out of a VM?
It's at least harder! Better chance it'll hit your 5-hour limit before it does. haha
See my response to the above comment
Yes, and have.
---
"During a test conducted by Trail of Bits researcher Artem Dinaburg, a preview version of GPT 5.6-Cyber was tasked with breaking out of a Debian 12 virtual machine. Initially, the agent exploited a known Linux kernel vulnerability, CVE-2026-53359, by developing its own exploit. After the host was updated, the agent found another pathway through libslirp, chaining a known vulnerability (CVE-2026-9539) with a previously unassigned bug to gain arbitrary host memory access. Even after QEMU and libslirp were updated, the agent analyzed system components and constructed a new escape chain using three zero-day vulnerabilities and one KVM flaw that had not yet reached the distribution kernel.
These findings suggest that general-purpose VMs may not be adequate security boundaries for highly capable AI agents, especially in older systems with delayed security updates. Trail of Bits recommends using specialized isolation systems like Firecracker, restricting VM access, and implementing rapid patching to mitigate these risks."
---
https://www.scworld.com/brief/ai-agent-repeatedly-escapes-vi...
you could, and if that's your preference https://nspawn.org is just right.
Neat, I wasn't aware of this tool. I just either run nixosContainer in systemd-nspawn or OCI image in systemd-nspawn.
Claude told him to do it this way.
I'd trust OP to make good architectural decisions/provide guidance even if AI mostly wrote the docs and UI. Looking into their GitHub, seems they are an engineering manager at Microsoft and contribute semi regularly to uBlue and Project Bluefin. Should be better quality than some random vibeslopper.
Always looking for a successor to https://developer.hashicorp.com/vagrant. Is this it?
Just a recommendation that difference between docker container and nsl on homepage is worth it
I'll give this one a try, thanks for sharing!
FWIW, I'm currently using systemd-nspawn via mkosi: https://github.com/systemd/mkosi
It makes an image and runs it in separate namespace. It can start at bash or init. It's very fast but there seem to be a problem creating an Ubuntu image on Debian and vice versa.
How does this compare to distrobox?
Distrobox mounts $HOME in the container at $HOME by default. WSL and NSL do not, and that's my preference. This means you can install tools that change your default path, change your dotfiles, etc, without affecting the host. The other obvious difference is that distrobox is powered by podman or docker, while NSL uses a VM that runs systemd-nspawn containers.
The name WSL has always struck me as a bit back area (LSW would seem to make more sense, since it is a Linux subsystem for Windows). I guess they mean it as a Windows Subsystem for Linuxing.
Anyway, should this be called LSL or WSLL? Or maybe LSWSL.
The naming is a bit awkward now, but an original design goal of the Windows NT kernel was the ability to host different types of OS "personalities" (userspace, essentially) on top of the Windows kernel, and these are called "subsystems." Win32 is one such subsystem, although there was no need to formally call it "Windows Subsystem for Win32" because everyone understood that it was just Win32 ported to NT.
The NT kernel designers came from VMS, and during development MS made various half-hearted promises that NT would be able to run VMS software as well but never actually followed through. If they had, there would likely have been a Windows Subsystem for VMS.
It is continuing a historic naming "accident", the precedent having been set by Windows Services for UNIX and similar in the 90s/00s.
Nice flip of the WSL idea the other way — simple interop like this keeps a one-person stack from turning into a VM zoo.
So you've just basically reimplemented LXC?
Nope. This is a VM, with containers inside. And the containers weren't "re-implemented", it uses existing systemd containers. That's what I was able to learn by skimming the site for 30 seconds. Did you not even do that? And why even be so condescending to someone else's project?
Because it does seem like we already have tools that skin this particular cat, it's valid to wonder what value this project provides over existing solutions.. even if they chose the wrong example to compare it to. Why do you think that's condescending?
LXC is a jail and qemu is an extra layer of emulation. Why pay that extra cost? Just because it serves a wsl image isn't really an answer. How is that worth the extra layer?
EDIT to not be a dick about it: I think the key detail here is the difference in isolation between containers and VMs, and where emulation comes in.
Just a reminder that the Hacker News community generally frowns on caustic dialog. Let's make sure this place doesn't turn into slashdot. :-)
Agreed. Edited. I do feel like I was just following the existing tone set by OP, but no excuse.
This is most useful to people who run Linux as their daily driver so rather than saying its like WSL can you explain what it offers that existing Linux containers do not?
Its also sounds different from WSL which I thought is a VM rather than a container.
> It's yet another step in my long journey to keep my host installation free from all the changing and breaking dev dependencies that force a reinstall every few months.
Something that also require a bit of explanation. What do you do that makes this such a common problem.
WSL2 uses a shared VM that does host integration (networking, shared files, permanent storage for each instance). NSL uses the same model but with Linux native technical implementations.
As for keeping my host clean - it's the developer's curse that always gets me. Install libWhatever3.2-dev because you need it to compile something, then don't realize until next time you open Chrome that it broke your system in some subtle way. There are dozens of ways to solve this like devcontainers, docker, incus, fully separate or remote vms. I like the WSL2 model so I wanted that same UX.
So a single VM with multiple containers within it? Interesting, but I think you should make it immediately clear on your site. Persistence is not the USP because there are lots of ways that you can get persistent VMs or sandboxes.
Looks very cool.
Now all you have to do is run NSL under WSL.
challenge accepted!
This is very cool. GG.
someone has to ask the question: can you run lsl in wsl?
The project is cool, but please use human written text.
The website's Claudisms are unbearable.
There's already Distrobox, which does exactly the same thing but isn't slop.
This handles use cases Distrobox can't, they both have a place.
IS it LXC containers or docker? Or are you running a custom chroot namespace setup?
Haven't checked the actual project but he does state he uses systemd-nspawn. Which is it's own kind of container runtime.
none of the above. a single vm started by systemd-vmspawn which then starts one or more containers for your instances using systemd-nspawn. It ends up being fast and lightweight.
He runs a systemd-nspawnd container in a "small vm", so neither really?