One Dedalus Machine per open PR. The PR’s branch is checked out, dependencies installed, services running. When nobody touches the preview URL for 5 minutes the VM sleeps. When the next reviewer opens the link, it wakes in under a second with the database, seed data, and log history intact.
1. On PR opened: provision
2. On webhook hit (or middleware): wake
The simplest pattern is a small router that proxies https://pr-123.previews.your-app.com to the machine’s preview URL. Before forwarding, wake the machine.
wake is idempotent, but its response may still be placement_pending or starting. Queue the request until the machine reaches running, then forward it to the stored preview URL.
3. On PR merged or closed: destroy
Why a microVM beats a container here
- Postgres, Redis, real systemd, anything else that doesn’t survive container restart, just runs. Migrations + seed data persist across sleep/wake.
- Sleep means zero compute cost while the PR is dormant. A 3-week-old PR costs only the storage GiB-month — not 24/7 uptime.
- Fast resume. Queue the first request while the machine restores, then forward it normally.
- Idle auto-sleep is built in (
autosleep, default "5m"). If your wake-on-traffic proxy forgets to put the VM back to sleep, the platform does it for you after five idle minutes.
Notes
- Set
visibility: "public" if external collaborators need to reach the preview without a Dedalus account. Use "org" to gate it on org membership, or "private" for the creator only.
- Wake latency depends on storage size. A 20 GiB machine wakes faster than a 200 GiB one.
- Serialize cold-start traffic per machine. Queue concurrent requests behind one readiness check instead of forwarding while the machine is still starting.
Last modified on August 19, 2026