Skip to content

PATTERN Cited by 1 source

Ephemeral VM as cloud IDE

Shape

Spin up a fresh VM per user session, deliver its shell as a browser-based IDE, and tear the VM down at session end. The browser tab is the editor UI; the VM is the execution environment. The user (and any co-tenant agent) gets a full Linux sandbox with root for the lifetime of the session.

Why it's a distinct pattern

The "cloud IDE" category has existed for a decade (GitHub Codespaces, Gitpod, Replit, StackBlitz, AWS Cloud9). The ephemeral-VM-per-session specialisation is narrower and only becomes viable when:

  1. VM boot is fast enough to be disposable. Firecracker-class (~125ms) makes per-session VMs feasible; QEMU-speed doesn't. See concepts/fast-vm-boot-dx.
  2. The substrate has routing for bound ports. Otherwise the session VM is unreachable from the outside; preview URLs wouldn't work. Fly Machines + systems/fly-proxy provides this; see patterns/ephemeral-preview-url-via-port-forward.
  3. Co-tenant agent is a first-class use case. A human-only cloud IDE is a productivity tool; add a coding agent sharing the root shell, and the pattern becomes load-bearing because the VM-boundary-as-blast-radius-limit is the sane safety posture (see concepts/agent-with-root-shell).

Canonical instances

  • Phoenix.new (Fly.io, 2025-06-20) — canonical productised instance. Per-session Fly Machine; browser-delivered VSCode-style UI; root shell shared with a Phoenix-tuned agent; full Chrome; *.phx.run preview URLs; gh CLI.
  • Replit Agent, Bolt, v0, Lovable — structurally similar: browser-delivered IDE backed by a per-session environment (VM or container), coding-agent-first product shape.
  • Fly.io disposable VM sketch (2025-02-07, sources/2025-02-07-flyio-vscodes-ssh-agent-is-bananas) — pre-productised wish-list for this pattern.

Contrast with persistent cloud IDEs

Axis Persistent cloud IDE (Codespaces) Ephemeral VM as cloud IDE (Phoenix.new)
Session lifetime Hours / days / weeks (workspace) Minutes / hours (session)
Drift Accumulates over time None — VM dies at session end
State persistence In the workspace volume Via commits / PRs / pushed artifacts
Cold-start tolerance Seconds-to-minutes is fine Milliseconds matters
Primary user Human developer Coding agent (with human observer)
Recipe devcontainer.json VM image
Boot-per-iteration cost Amortised (workspace resumes) Paid every session

Both are valid points in the design space. The ephemeral variant trades persistence for cleanliness and is a better fit for agent-first use cases where "every session starts fresh" is a feature, not a bug.

Implementation ingredients

  • Fast-boot micro-VM substrate — systems/firecracker, Intel Cloud Hypervisor, similar. VM images pre-baked with toolchains for the supported stacks.
  • Browser UI — VSCode (web) or similar editor that connects to the session VM's shell + filesystem.
  • Session manager — allocates VMs, tears them down, routes browser connections.
  • Preview-URL fabric — detects bound ports, produces public URLs. See patterns/ephemeral-preview-url-via-port-forward.
  • Agent loop — system prompt + tools + retry policy running inside the VM (or making CDP / shell RPCs into the VM).
  • gh or similar CLI for reach into user's existing source repos / issue trackers.

Trade-offs

  • Pro: no drift; agent damage is bounded; preview URLs come for free; multi-tenancy dense at the platform level (VMs evaporate between sessions).
  • Con: per-session cold-start cost every time; state must be externalised (commits / PRs / pushed images); offline work impossible; platform-dependency for the whole workflow.
  • Specific to agent-first cases: co-tenant agent with root shell means whatever the agent does during its window can reach whatever the VM can reach — WireGuard network, credentials, etc. — until the VM dies. Credential scoping matters more, not less.

Adjacent patterns

Seen in

Last updated · 200 distilled / 1,178 read