Skip to content

CONCEPT Cited by 1 source

Ephemeral dev environment

Definition

A development environment whose lifetime is bounded by a single session (or task, or agent run) rather than existing as a long-lived personal resource. The environment is created on demand, used for one unit of work, and torn down; reproducibility comes from recipes (images, specs, manifests), not from accumulated manual setup.

Contrast with:

  • Laptop dev environment — long-lived, accumulates config drift, tied to a physical device.
  • Persistent cloud workspace (Codespaces, Gitpod) — long-lived per-user environment running on the cloud substrate.

When it matters

Three overlapping use cases, all recent, all on this wiki:

  1. patterns/disposable-vm-for-agentic-loop — spin up a clean-slate VM per agentic task, throw it away when done. The VM's destructive mistakes, accumulated garbage, and compromise surface are all out of scope because it's going away.
  2. patterns/ephemeral-vm-as-cloud-ide — the productised shape. An ephemeral VM is the IDE; the browser is a thin client; Phoenix.new is the canonical instance.
  3. Ephemeral CI environments — the existing practice every pipeline tool implements (a clean container per job). Agent workflows generalise this shape from short-lived batch-execution to interactive development.

Properties a good ephemeral dev environment has

  • Instant boot. The primary cost of ephemerality is the create-destroy cycle. Firecracker-class boot (~125ms) keeps the cycle fast enough that spinning a fresh environment per task is viable. See concepts/fast-vm-boot-dx.
  • Reproducibility. The environment is built from a spec (Dockerfile, Fly Machine config, devcontainer.json). You can recreate yesterday's setup deterministically.
  • Preview URLs. Bound ports reach the internet without a deploy step; see concepts/ephemeral-preview-url.
  • Bounded blast radius. Whatever the session does — rm -rf /, apt install, destructive migrations — doesn't persist past teardown.
  • State capture on exit. The environment is disposable; the artifacts (commits, PRs, files exported) are not. Phoenix.new surfaces these via gh PRs and phx.run preview URLs.

Named instances on this wiki

  • Phoenix.new (2025-06-20) — per-session Fly Machine with shared root shell + headless browser + preview URL + gh CLI. Ephemeral dev environment where the primary user is a coding agent.
  • Fly.io disposable VMs sketched at 2025-02-07 — pre-productised wish-list for the same shape.

Caveats

  • "Ephemeral" is a lifetime property, not a durability property — artifacts produced by the session (commits, PRs, pushed images) persist; the substrate is what goes away.
  • There's a trade-off with state-heavy workflows (long-running builds, populated databases): ephemeral environments force you to externalise state into durable storage, which has its own cost.
  • The ephemerality claim only holds if the environment actually boots fast enough to be disposable; long-boot VMs encourage session reuse, which re-introduces drift.

Seen in

Last updated · 200 distilled / 1,178 read