ArchWSL: Arch Linux on Windows via wsldl, with multiple instances

What ArchWSL actually solves for Windows developers

WSL ships with distributions Microsoft curates, and Arch Linux is not one of them in the default set. ArchWSL fills that gap by pairing an Arch rootfs with wsldl, a launcher that registers and drives a WSL instance. The audience is narrow but real: people who already use Arch on their Linux machines and want the same package manager, the same rolling release cadence and the same AUR workflow inside Windows, without running a virtual machine or a second boot.

The second problem it solves is instance multiplicity. The README states that the name of the EXE file is used as the name of your WSL instance, so copying the launcher and renaming it produces separate, non-conflicting ArchWSL installations. That is a different model from a single distribution entry you can only have once. You can keep one instance pinned to a stable set of packages and another left to roll forward, and they do not share state.

The project is a Makefile-driven packaging repository rather than a distribution build system. The top level holds the Makefile, appveyor.yml, the appx and appx-online directories, buildAppX.ps1, preset.json and the i18n folder with translations of the README. The rootfs itself is not built here; the Makefile downloads it from the yuk7/ArchWSL-FS releases.

How the launcher, rootfs and Makefile fit together

The build is a two-artifact assembly. The Makefile defines OUT_ZIP as Arch.zip and LNCR_EXE as Arch.exe, then downloads rootfs.tar.gz from the yuk7/ArchWSL-FS releases API and icons.zip from the yuk7/wsldl releases API. The icons.zip archive is unpacked to obtain the launcher binary, which is renamed to Launcher.exe, and the ziproot target copies Launcher.exe into the output directory under the name Arch.exe alongside rootfs.tar.gz. The zip target then archives that directory with bsdtar.

So the released archive contains exactly two things you care about: a launcher executable and a rootfs tarball. On first run the launcher extracts the rootfs and registers it with WSL. After that, the same executable is the control surface for the instance, exposing subcommands for running commands, reading and writing settings, backing up and uninstalling. There is no daemon and no background service: every operation is a foreground invocation of the EXE.

The configuration surface is small and stored per instance. The usage text lists settable keys including --default-user, --default-uid, --append-path, --mount-drive, --wsl-version and --default-term, with matching get keys for most of them plus --wt-profile-name and --lxguid. Backup supports four output formats: .tar, .tar.gz, .ext4.vhdx and .ext4.vhdx.gz, with the vhdx variants marked WSL2 only, plus a .reg file that captures the settings registry. The clean subcommand uninstalls the instance.

Installing ArchWSL and running the first pacman command

The README documents three install routes: zip, appx and Scoop. The zip route is the one that shows the mechanism most clearly. Download the installer zip from the releases page and extract every file into a single directory that you have full access to; the README explicitly warns that a location like Program Files cannot be used. Then run Arch.exe, which extracts the rootfs and registers the instance.

If you prefer Scoop, the README gives two commands:

scoop bucket add extras
scoop install archwsl

The appx route needs a certificate step first. You download both the appx and the cer file, install the cer into Trusted People of the local machine, which the README says requires administrator privileges, and then double-click the appx.

Once the instance is registered, package management needs one more step. The README marks keyring initialization as optional but states that you will need to do it if you want to use pacman. The docs page is the canonical reference for the exact commands, so treat this as the point where you leave the README and follow How-to-Setup. After that, the launcher's run subcommand is how you execute things inside the instance:

run <command line>

The run subcommand executes the given command line in that instance and inherits the current directory. There is also runp, which converts a Windows path in the command line before running it, useful when you are invoking the launcher from a Windows shell and passing a path that needs translation.

Multiple instances, and the naming rule that makes them work

The multiple-install capability is not a separate feature so much as a consequence of how wsldl registers instances. Because the EXE filename becomes the instance name, copying Arch.exe to ArchDev.exe and ArchStable.exe gives you two instances that coexist. The README states this directly: if you copy multiple EXE files and rename them to different names, you can have multiple different ArchWSL installations at the same time without conflict.

The practical consequence is that your instance inventory lives in your filesystem as executable names, not in a central configuration file. That is convenient and slightly fragile. Renaming an EXE after registration is not described in the README as a supported operation, and the settings are addressed per instance through the launcher, so the filename is effectively the primary key. Decide on names before you first run the executable.

Each instance also carries its own WSL version setting. The config subcommand accepts --wsl-version with 1 or 2, and get --wsl-version reports the current value. That means you can keep one instance on WSL1 and another on WSL2 from the same launcher family, which is unusual flexibility. It also means the WSL1 caveat applies per instance rather than globally, so a machine with both versions needs the glibc replacement only on the WSL1 side.

The pacman keyring and the WSL1 glibc replacement

Two documented steps stand between a fresh install and a usable system, and both are easy to skip. The first is keyring initialization. The README lists it as optional in step 4 of the zip instructions but immediately qualifies that: it is not required, but you will need to do this if you want to use pacman. In practice, an Arch instance without a working keyring cannot verify package signatures, so pacman is effectively unusable until you run the initialization. Treating it as optional is a documentation framing choice, not a statement that you can skip it and still install packages.

The second is the WSL1 glibc replacement. The README puts this in bold: if you use WSL1, you must replace the glibc package on the first run of the instance, and it points to the setup docs. This is the sharpest constraint in the project. WSL1 translates Linux syscalls rather than running a real kernel, and Arch's glibc build assumes a real kernel interface, so the stock package does not work there. If you are on WSL1 and you do not do this, you have an instance that registers successfully and then misbehaves at the libc level, which is a much harder failure to diagnose than a clean error message.

A third limitation is structural rather than a bug: the launcher manages instances, not packages. There is no ArchWSL equivalent of an upgrade command that moves your installed packages forward. The zip update instructions replace the exe and rootfs.tar.gz, which refreshes the launcher and the base image, while your package state is whatever you have made it through pacman. Rolling-release Arch means the maintenance burden is yours and it is continuous.

Where ArchWSL is the wrong choice, and what to use instead

If your goal is simply a Linux userland on Windows with the least setup friction, ArchWSL is the wrong tool. The Ubuntu entry that ships with WSL registers in one command, has a supported keyring out of the box, and does not require you to reason about glibc variants. ArchWSL's value is that it is Arch, and if you do not specifically want pacman, the AUR and rolling packages, you are paying setup cost for nothing. The search interest in comparing Ubuntu and Arch for WSL reflects exactly this fork in the road.

Compared with a full virtual machine running Arch, the difference is architectural. A VM gives you a real kernel, so the WSL1 glibc problem does not exist and you can run anything that needs kernel modules. ArchWSL runs as a WSL instance, which means it shares the Windows kernel interface through WSL and, on WSL2, runs in a lightweight utility VM. You get far lower overhead and direct filesystem interop with Windows, and you give up kernel-level control. If your work involves custom kernel modules or nested virtualization, a VM is the honest answer.

Compared with building your own rootfs and importing it with wsl --import, ArchWSL is a convenience layer. The manual route gives you full control over what goes into the image, and it is not much more work if you already have a tarball. What ArchWSL adds is the launcher: the config and get subcommands, the backup formats, the Windows Terminal profile integration via --default-term and --wt-profile-name, and the naming convention that makes multiple instances trivial. If you do not want those, you are carrying a dependency on wsldl for no benefit.

Maintenance, updates and what the MIT licence covers

The repository is not archived, and the last push was on 2026-04-02, which is under six months before today. The most recent release, 26.4.2.0, carries the same date, following 25.3.19.0 and 25.3.2.0 in March 2025. The release cadence is therefore not uniform: there is a gap of roughly a year between the 2025 releases and the 2026 one. Plan updates around releases rather than assuming a fixed schedule.

Updating depends on your install route. For zip installs, the README says to download the installer zip, extract the exe and rootfs.tar.gz, and overwrite your existing files. For appx installs, download the appx and double-click it. Note what this does and does not do: it replaces the launcher and the base rootfs, and it does not touch the packages you installed inside the instance. The README does not document a rollback path for either route, so if an update goes wrong your recovery options are whatever you captured with the backup subcommand beforehand. That is the reason the backup formats matter more than they first appear.

The project is MIT licensed, with a separate LICENSE-3RD-PARTY file at the top level covering bundled components. MIT is permissive, so redistribution and modification are allowed with the licence and copyright notice retained. The Arch rootfs and any packages you install inside the instance carry their own licences, which are not the same thing as the launcher's licence, and the project does not attempt to summarize them for you. That is a question for your own legal review, not something the README answers.

Build reproducibility is worth noting if you rebuild from source. The Makefile resolves the rootfs and launcher download URLs by querying the GitHub releases API and taking the first matching asset with jq and curl, so a build today can pull a different rootfs than a build last month. The Makefile has no pinned version or checksum step. If you need reproducible images, that is a gap you would have to close yourself.

Editorial conclusion

Adopt ArchWSL if you want a rolling-release Arch userland inside WSL and you are willing to run the keyring initialization and WSL1 glibc replacement the docs describe. Skip it if you need a supported, vendor-backed distribution with a guaranteed upgrade path, or if you expect the launcher to manage packages for you: it only registers and configures the instance. Before committing, verify three things on your machine: that the downloaded rootfs.tar.gz matches the release you intended, that your Windows build is 1709 FCU or later, and whether you are on WSL1, because the README requires replacing the glibc package on first run in that case.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. yuk7/ArchWSL on GitHub