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 is described in the existing 404 application documentation as an app-managed lifecycle. 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 published desktop guide describes a managed WSL distro named 404. It says the app retrieves a signed manifest and distro tarball, verifies the manifest signature using an embedded public key and the tarball SHA-256, imports the distribution, records an installed version, supplies a control token and Windows username, starts STATIC, installs host CA trust, and configures routing. The documented local wsl/ state includes downloads/, distribution/, control-token, and installed-version.json.
That is a description of the existing app documentation. The private sethzhonda/404-APP repository was not accessible to the connected GitHub account during this revision, so exact desktop implementation, privilege scope, cleanup sequencing, and currently shipped macOS behavior have not been confirmed from app code. The STATIC CA page similarly separates verified proxy code from app-documented trust installation.
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. The managed app documentation says it tracks the installed version and supervises updates. 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.