09afbdbd

docs: the release notes tell v0.0.3, and the roadmap looks only forward

a73x 2026-08-06 10:58

Commit message

docs: the release notes tell v0.0.3, and the roadmap looks only forward

Release notes gain v0.0.3 — macOS hosts, host-owned guest subnets,
published ports (console, API and MCP alike), images decoded in-process —
and the v0.0.2 section its one-fix release never got. The roadmap now
carries only what is ahead and points at the release notes for what
shipped. The landing description says what eitri does in two paragraphs.

ROADMAP.md

Old		New
@@ -1,61 +1,21 @@
1	# Roadmap	1	# Roadmap
2		2
3	## v0.0.1 — installable	3	What shipped in each version is in the
4		4	[release notes](https://eitri.sh/docs/releases/); this is what's ahead.
5	The goal: someone with a Linux box goes from [eitri.sh](https://eitri.sh) to a	5
6	booted VM they can `eitri-ssh` into. Prebuilt binaries fetched from stable	6	## v0.0.4 — candidates
7	URLs — no toolchain, no curl-pipe installer. This is the first tag; history is	7
8	frozen from here.	8	- Bridged guest networking: a Linux host puts its guests on the operator's
9		9	own network — taps on a named bridge, the site's DHCP addresses the guests,
10	Binaries & releases	10	the agent discovers the result
11		11	- Public gateway: route inbound traffic to guest services through eitri,
12	- Version-stamped binaries (`--version`), cross-compiled release tarballs +	12	building on published ports
13	SHA256SUMS (linux amd64/arm64; darwin for `eitri-ssh`)	13	- A PAT is enough: an opt-in eitri-managed tenant CA signs short-lived SSH
14	- Artifacts at stable URLs: `eitri.sh/dl/v0.0.1/...` with a `latest` alias, so	14	certificates, so a bare token can reach its VMs—BYO CAs stay first-class,
15	tooling can bootstrap from them, not just humans	15	and a tenant that wants eitri holding no signing power keeps that
16		16	- Remote MCP: a hosted endpoint (api.eitri.sh/mcp) any client can connect
17	eitri.sh	17	to—streamable HTTP, per-tenant auth, TLS at the edge; its identity story
18		18	is the managed tenant CA above
19	- Landing page, rendered docs, downloads, and a `CLOUDHV.fd` firmware mirror —
20	one static site image, replacing the current site
21
22	Upgrades
23
24	- Agent: replace binary + restart in place; running VMs survive and are
25	re-adopted
26	- cloud-hypervisor: swap the binary in place; new/restarted VMs use the new
27	version, running VMs keep their old process
28	- Server: stop → replace → start; downtime acceptable, VMs unaffected;
29	migrations run on boot; version skew with agents stays safe
30
31	Docs
32
33	- Quickstart: zero-to-first-VM on one host, then add a second host
34	- Upgrade guide, release notes
35
36	Multi-tenancy
37
38	- A second tenant on the fleet. The seam is already live (tenants table,
39	tenant-scoped tokens/VMs, `<tenant>.<name>` connect names); tenant #2 needs
40	the per-tenant user-CA split, SSE/console/event isolation, tenant-scoped
41	audit, and cross-tenant token mint
42
43	Gate
44
45	- Clean-slate rehearsal: the quickstart followed verbatim on a fresh host,
46	end-to-end, before the tag exists
47
48	Out of scope: curl installer, OS packages, live cloud-hypervisor handover for
49	running guests, new features.
50
51	## v0.0.2 — candidates
52
53	- macOS host support: a Mac joins the fleet as a host
54	(Virtualization.framework backend)
55	- Live cloud-hypervisor handover for running guests	19	- Live cloud-hypervisor handover for running guests
56	- Public gateway: route inbound traffic to guest services through eitri	20	- Provider integration: provision on existing cloud infrastructure (aws, gcp,
57		21	proxmox, …)
58	## v0.0.3 - candidates
59
60	- provider integration: provision on existing cloud infrastructure
61	- aws, gcp, proxmox, etc

docs/releases.md

@@ @@ -5,6 +5,77 @@ Tarballs and checksums for every release live at @@
+newest. The [quickstart](quickstart.md) takes a release from download to a
+running VM.
+## v0.0.3
+macOS hosts. An Apple-silicon Mac joins the fleet as a host and runs Linux
+guests beside your Linux boxes (so the Mac Mini can earn its keep after all).
+Around it: hosts own their guest networks, you can publish a VM's ports, and
+the agent reads guest images without a conversion tool.
+**Mac hosts.** An Apple-silicon Mac enrolls like any other host and runs
+guests through vfkit, the signed helper that drives Apple's
+Virtualization.framework. `brew install vfkit` is the one thing the agent
+cannot do for you—vfkit only works carrying Apple's virtualization
+entitlement, and an entitlement lives in a signature, so it comes from a
+signed distribution or not at all. Everything else the agent does itself: it
+installs as a LaunchAgent in the session you're already in, keeps its state in
+`~/.eitri/agent`, and upgrades from the console like every other host.
+Releases ship a `darwin_arm64` host bundle beside the Linux ones.
+**Hosts own their guest network.** The subnet a host's guests live on is a
+fact about that host, and the host is the only thing that can observe it. So
+the direction reverses: a host tells the fleet which subnet its guests are on,
+a joining host proposes its own—the fleet's allocation is only a suggestion—
+and a Mac reports whatever subnet vmnet actually gave it. A host also refuses
+a guest subnet that contains its own uplink, naming both sides and the flag
+that fixes it, because that overlap takes out the very connection you'd use to
+fix it.
+**Published ports.** SSH goes through the gate; anything else a guest serves
+needs a published port. You publish a VM's port on its host: the fleet
+binds a port on the host (30000–32767 when you leave the choice to it) and
+pipes it to the guest. The MCP tools speak it too, so an LLM that just
+built something in a VM can publish the port and hand back the address to
+dial. There is no authentication in front of a published
+port—whoever can reach the host on that port reaches the service—so publish
+what you're content to serve to everything on that network, and leave the rest
+to the gate.
+**Images, decoded in-process.** The agent reads guest images itself: qcow2,
+vmdk, vhdx, vdi, parallels, vpc and asif are parsed in-process, gzip is
+decompressed sparsely as it lands, and an image that is already raw is renamed
+into place—there is no format to change. `qemu-img` goes with it. A Linux
+host needs KVM and nothing else.
+**Fixes.** A VM says which SSH key eitri put in it—the key type, its
+fingerprint, its comment. A one-click create picks a default image its host's
+architecture can run, instead of one image for the whole fleet. A guest's
+address is judged on its own terms—does it name something reachable—rather
+than against an allocation the fleet made. A lost guest's report quotes the
+last thing its hypervisor said, instead of "lost" and nothing else. A backend
+signals only the processes it started, so a pid recycled across a host reboot
+is never someone else's process getting SIGKILL. And a host is asked whether
+it can run a guest at all before a create spends anything on a download.
+**Known limits.**
+- Apple silicon only: there is no darwin/amd64 bundle. An Intel Mac is told
+  there is no artifact for it—true, and checkable—rather than offered a
+  binary nobody has booted a guest on.
+- A Mac joins as a host. The control plane stays Linux; the Mac bundle
+  carries no server.
+- vfkit is yours to install (`brew install vfkit`); eitri cannot mirror a
+  binary whose entitlement lives in Apple's signature.
+## v0.0.2
+One fix, worth its own release. A guest's disk was handed to cloud-hypervisor
+without a declared format, and an autodetected raw image gets its sector 0
+write-protected—so the first boot's partition grow only ever happened in the
+kernel's memory, and the guest died in initramfs the first time it was
+power-cycled. Disks are now declared raw and the partition table stays
+writable.
+## v0.0.1
+The first release. eitri is a small cloud backed by your own hardware: one

site/index.md

Old		New
@@ -4,22 +4,13 @@
4		4
5	## DESCRIPTION	5	## DESCRIPTION
6		6
7	The cost of compute is rising—RAM, storage, GPU—at all-time highs,	7	eitri takes the machines you already have and lets you build out your
8	with RAM prices not expected to come down until 2030.	8	own personal cloud: VMs on your own hardware, managed without
9		9	complexity (repurposed e-waste!).
10	Companies are fighting over supply chains, cloud providers are raising	10
11	prices, and we're all lamenting that we should have upgraded RAM in 2024.	11	Software has never been easier to produce. eitri gives you a way to
12		12	run it safely: create a VM in seconds, manage your own fleet, and even
13	With the rise of LLMs, it's now easier than ever to create software, but	13	point your favourite LLM at it.
14	what hasn't improved is the cost of the hardware. eitri's premise is
15	simple: let's use what we have instead of consuming more. We don't need
16	to all go buy Mac Minis to run an AI agent (seriously, what was this
17	about?!) or spin up a VM in some remote cloud that charges us by the
18	hour. We have the hardware; we just need the ease of use. Repurposing
19	that old laptop and being able to manage it from a single pane of glass.
20	Being able to connect it to your favourite LLM and say, deploy here,
21	please, and run that software you've just developed on a VM, and show it
22	off.
23		14
24	Boot a throwaway sandbox for a risky experiment. Keep a dev machine that	15	Boot a throwaway sandbox for a risky experiment. Keep a dev machine that
25	survives host reboots. Give an AI agent a VM where it can run wild. Delete	16	survives host reboots. Give an AI agent a VM where it can run wild. Delete