Provisioning and updates
Provisioning has two paths. The CLI path asks an operator to download, inspect, import, configure, launch, and trust a distribution. The desktop path manages the runtime lifecycle, signed downloads, profile synchronization and authenticated control from the host. They use different WSL names and should not overwrite one another.
Self-hosted operator path
The Windows CLI guide uses the published 404-windows-x64.zip: a distro tarball, manifest and signature, runtime TOML, profiles, and control token. The operator imports the rootfs as 404-cli, writes the Windows username in /opt/404/win-user, runs /opt/404/404-init.sh, then installs the public CA on the Windows host and configures browser proxy routing. A manifest-to-tarball SHA-256 comparison detects mismatch with the bundled manifest; it does not authenticate the publisher unless the manifest signature is verified against a separately trusted release key.
The operator ZIP’s current release workflow writes a fixed example control-token value. That is not per-installation entropy. Change it for use outside a tightly local environment and avoid exposing the control bind to untrusted networks. The ZIP’s runtime config binds 0.0.0.0 inside WSL; host forwarding and firewall behavior determine exposure.
Managed desktop path
The Windows desktop uses a managed WSL2 distribution named 404. It verifies the signed manifest and archive digest, imports or updates the distribution, records installed version metadata, supplies runtime configuration/token/Windows username and starts STATIC. Its profile cache verifies the exact manifest cohort before replacing runtime profile files. Host CA trust and routing are separate operations.
The app-managed wsl/ area contains downloads/, distribution/, control-token and installed-version.json. Backend selection, host privileges and cleanup are described in someguy platform notes and What someguy changes. Browser runtime readiness does not prove successful host integration or matching native/WSL artifact versions.
Updating and removing a distro
A new distro tarball contains a new STATIC binary and eBPF object; it is not an in-place apk upgrade of the imported rootfs. The stable release manifest points to a versioned immutable tarball. someguy tracks installed version metadata and supervises archive replacement. A self-hosted operator should verify the matching release, stop routing, and deliberately replace or re-import their chosen distro while preserving or reinstalling the correct CA trust and profile configuration. Never unregister the app’s 404 distro when you intended to remove 404-cli; wsl --unregister deletes that distro’s filesystem.
For archive creation and signatures, continue to Build and release. For actual operator commands, use Windows installation.
Published artifacts and manual inspection
The GitHub releases provide 404-distro.tar.gz, 404-distro-manifest.json, 404-distro-manifest.json.sig, and 404-windows-x64.zip. The ZIP adds AppData/Roaming/404/static/static.runtime.toml, profiles, and AppData/Local/404/wsl/control-token. STATIC and ttl_editor.o are already in the rootfs; do not download a separate STATIC binary to import it.
The Windows CLI guide stages the operator files and imports 404-cli, distinct from someguy’s 404. Write /opt/404/win-user with the actual Windows username before invoking /opt/404/404-init.sh. A bare wsl -d <name> opens a shell and does not start STATIC. Check the running process with wsl -d 404-cli -- pgrep -a static and the token-protected /status route. Check the pinned map and tc filters separately; process readiness does not prove packet attachment. The distribution anatomy shows exact paths and commands.
The public update origin exposes a stable /distro/manifest.json and .sig, plus a versioned /distro/<tag>/404-distro.tar.gz, manifest.json, and .sig. Consumers should verify the manifest’s signature against a trusted release key before trusting its tarball hash. The build and release contract shows the JSON fields and CI publication path. The repo’s scripts/verify-distro-publication.sh checks public reachability and matching version, but is not a replacement for cryptographic verification by a consumer.