Skip to content

PATTERN Cited by 2 sources

Disposable VM for agentic loop

Shape

Instead of running an LLM-driven agentic coding loop on the developer's laptop (or on any shared dev server), spin up a disposable, clean-slate VM per task / session, run the agentic loop against that VM, and discard the VM when the task is done. The VM's compromise, mis-configuration, destructive mistakes, and accumulated state are all out-of-scope by construction — the VM is going away.

Three properties the VM must have:

  1. Clean slate on each boot — no carryover state to confuse the LLM across runs, no half-configured mess from yesterday's loop.
  2. Instant boot — the loop iterates; provisioning latency throttles the cycle. Seconds, not minutes.
  3. Bounded blast radius — the LLM's boundary issues (destructive commands, random package installs, unintended file edits) cannot touch the dev laptop, the user's Git project, or production.

Fly.io's 2025-02-07 canonical phrasing:

"A thing you'd really like to be able to do: run a closed-loop agent-y ('agentic'? is that what we say now) configuration for an LLM, on a clean-slate Linux instance that spins up instantly and that can't screw you over in any way." (Source: sources/2025-02-07-flyio-vscodes-ssh-agent-is-bananas)

Canonical substrate

Fly Machines — Firecracker micro-VMs — hit all three properties by design. Sub-second boot, per-Machine kernel-enforced isolation via systems/firecracker, discardable and re-creatable from a Docker image. Fly's post is the architectural argument for this substrate as the target for agentic loops; the productisation post (VSCode Remote against a Fly Machine) is explicitly deferred.

The substrate does not have to be Fly Machines in particular — any similarly-shaped micro-VM offering (or container-with-strong- isolation, e.g. gVisor, kata-containers, firecracker-in-Docker) can fill the role. The architectural requirement is the three properties; the vendor is a choice.

Why not just sandbox on the dev laptop

Directly running the agentic loop on the laptop fails the bounded blast radius requirement in several independent ways:

  • Filesystem scope ambiguity. The LLM agent may edit files outside the current project directory (the "boundary issues" phrase is Fly's). A container running with a bind-mount of the project directory mostly contains this, but escapes are easy to get wrong.
  • Secret exposure. The laptop typically has the developer's SSH keys, AWS credentials, cloud CLIs, production access. An agentic loop running on the laptop has access to them by default.
  • Network side-effects. The LLM may curl arbitrary URLs, npm install arbitrary packages, git push to arbitrary remotes. Containing this requires explicit egress controls, which laptop configurations typically don't have.
  • Concurrent mess. The developer is using the laptop for other things at the same time. LLM-driven iterations changing system state (installed packages, env vars, shell history) pollute the developer's own work.

A disposable VM eliminates all four by construction. "Can't screw you over in any way."

Why not just use a reusable dev server

A long-lived dev server shared by developers (or a single developer's always-on VM) fails the clean slate requirement: state from yesterday's loops, half-installed dependencies, mutated config files, and residual processes all bias the next iteration. "The same LLM mistake you made yesterday is waiting to bite you today." Disposability is load-bearing — the loop works because each iteration starts from a known-good baseline.

Composition with agent-deployment remote-dev

The pattern composes cleanly with stager-downloads-agent-for-remote-control:

  • Target the remote-dev agent (e.g. VSCode Remote-SSH) at the disposable VM, not at the dev laptop.
  • The agent's RAT-shape blast radius is now scoped to the VM; the VM goes away, the blast radius goes with it.
  • The developer keeps their preferred editor UX; the execution environment is safely elsewhere.

Fly.io's implicit argument (per sources/2025-02-07-flyio-vscodes-ssh-agent-is-bananas): this is the right integration shape, and Fly's promised follow-up post is "a custom connection to a Fly Machine working in VSCode."

The disposable-VM pattern answers the blast-radius question at the isolation boundary layer (kernel, hypervisor). A complementary answer at the authority layer is the capability-based sandbox — deny ambient authority by default, grant capabilities only for what the task needs. Both compose: a capability-sandboxed runtime inside a disposable VM gives you two independent layers of containment.

Seen in

  • sources/2025-02-07-flyio-vscodes-ssh-agent-is-bananas — Fly.io's 2025-02-07 post is the canonical wiki articulation of the pattern. The post names the three VM requirements (clean-slate, instant, can't-screw-you-over), names the motivating use-case (agentic LLM loop), and positions Fly Machines as the intended substrate without shipping the productisation post.
  • sources/2025-06-20-flyio-phoenixnew-remote-ai-runtime-for-phoenix — productised instance. Four months after the 2025-02-07 sketch, Fly.io ships Phoenix.new — a browser-delivered coding agent for Phoenix / Elixir where every session is a fresh Fly Machine the user and agent share as co-tenants with root access, backed by a full Chrome the agent drives and *.phx.run preview URLs. Canonical disposable-VM product; see patterns/ephemeral-vm-as-cloud-ide for the productisation pattern distinct from the raw disposable-VM shape.
Last updated · 200 distilled / 1,178 read