Skip to main content
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