nsl (NSpawn Subsystem for Linux) は、Windows Subsystem for Linux (WSL) のLinux版として位置づけられている：ディストリビューションをインストールし、カレントディレクトリでシェルを開き、コマンドを実行し、ホストを汚さない。各マシンは、systemd-vmspawnによってQEMU/KVMの下で起動される共有VM内でsystemd-nspawnコンテナとして実行されるフルディストリビューションである。VMのルートファイルシステムは置換可能でユーザー状態を持たず、マシンデータは専用のデータディスクに保存される。イメージは毎週再構築され、Frostyard公開ワークフローを通じて署名され、nslは使用前に署名を検証する。
毎週再構築されるディストリビューションイメージに署名・配布するFrostyard公開ワークフローの公式ロゴとして示されるnslプロジェクトのブランディング。
マシンを使うと、プロジェクトディレクトリでシェルを得られる (`nsl`) か、単一コマンドを実行できる (`nsl run make test`) が、ホストの終了ステータスで返ってくる。ユーザーの `$HOME`、リムーバブルメディア、 `/mnt` が `/mnt/host` に同じUID/GIDで現れ、内部ではパスワードレスの `sudo` が使える。ホストの `127.0.0.1` へのポートフォワーディング、WaypipeによるWaylandウィンドウ、そして7種類の署名済みディストリビューション (Debian 13、Ubuntu 26.04 LTS、Fedora 44、CentOS Stream 10、Arch、openSUSE Tumbleweed、Leap 16.0) から選択可能。`--isolated` モードでは、マシンを専用VMに配置し、ホストファイル、デスクトップ、ホスト側アクションを一切遮断する。
nslリポジトリのGitHub Open Graph画像は、プロジェクトを「アトミックホストとホストをクリーンに保ちたい人のための開発環境」と視覚的に要約しており、記事で説明されているnslの目的とアーキテクチャと一致する。
通常のマシンはユーザーと同等に信頼される：ホームディレクトリ (鍵やトークンを含む) を読めるが、ホストでrootになれず、ホストソケットにも到達できない。nslはユーザーとして実行され、独自のデーモンを持たず、ホストパッケージ、デバイス権限、グループ、sudoersを一切変更しない。
v0.4.0が現在の設計での最初のリリースで、v0.3.0以前は廃止されたプロトタイプである。テスト済みホストはSnow Linux 13 (systemd 261.2、QEMU 10.0.13、virtiofsd 1.13.2、GNOME Wayland)。前提条件：KVM対応x86-64 Linux、systemd-vmspawn、UEFIファームウェア付きQEMU、virtiofsd、`kvm` グループメンバーシップ。
プロジェクトはVM-plus-nspawnアーキテクチャを説明しているが、nspawnが原理的にはVMなしでLinux上で動けるにもかかわらず、なぜVMレイヤーが必要なのかは述べていない。また、toolbx、distrobox、limaといった既存のコンテナ/VMツールとの比較もソースにはなく、nslを選ぶ根拠は提供された資料には文書化されていない。