nsl (NSpawn Subsystem for Linux) is positioned as a Linux analogue to Windows Subsystem for Linux (WSL): install a distro, open a shell in your current directory, run commands, and keep the host untouched. Each machine is a full distro running as a systemd-nspawn container inside a shared VM launched by systemd-vmspawn under QEMU/KVM. The VM's root filesystem is replaceable and holds no user state; machine data lives on its own data disk. Images are rebuilt weekly and signed through the Frostyard publishing workflow; nsl verifies signatures before use.
The nsl project branding shown as the official logo from the Frostyard publishing workflow that signs and distributes the weekly rebuilt distro images.
A machine gives you a shell in your project directory (`nsl`) or a single command (`nsl run make test`) with the host exit status; your `$HOME`, removable media, and `/mnt` appear at `/mnt/host` with your UID/GID and passwordless `sudo` inside; port forwarding to host `127.0.0.1`; Wayland windows via Waypipe; and a choice of seven signed distros — Debian 13, Ubuntu 26.04 LTS, Fedora 44, CentOS Stream 10, Arch, openSUSE Tumbleweed, and Leap 16.0. `--isolated` mode puts a machine in its own VM with no host files, desktop, or host actions.
The GitHub Open Graph image for the nsl repository visually summarizes the project as 'development environments for atomic hosts and people who want to keep the host clean', aligning with the article's description of nsl's purpose and architecture.
An ordinary machine is trusted as you: it can read your home directory (including keys and tokens) but cannot become root on the host or reach host sockets. nsl runs as your user with no daemon of its own and changes no host packages, device permissions, groups, or sudoers.
v0.4.0 is the first release of the current design; v0.3.0 and earlier are a retired prototype. The tested host is Snow Linux 13 with systemd 261.2, QEMU 10.0.13, virtiofsd 1.13.2, and GNOME Wayland. Prerequisites: x86-64 Linux with KVM, systemd-vmspawn, QEMU with UEFI firmware, virtiofsd, and `kvm` group membership.
The project describes the VM-plus-nspawn architecture but does not state why a VM layer is required on Linux, where nspawn could in principle run without one. The sources also do not compare nsl to existing container/VM tools such as toolbx, distrobox, or lima, so the basis for choosing nsl over alternatives is not documented in the supplied material.