Fundamentals

What Is a Disposable Development Environment?

This blog uses the term constantly and has mostly assumed you already know what it means. Here's the actual definition, and the three things people most often confuse it with — a snapshot, a container, and a cloud dev environment — none of which are the same guarantee, even though all three get called "disposable" in casual conversation.

The pattern: create, use, discard, recreate

A disposable development environment is one where destruction is the default, not an exception you have to remember to trigger. You create it — usually from a known-good starting point, not from scratch every time — use it for exactly one task, and it's gone the moment that task ends, with nothing about the environment surviving to affect the next one. When you need the same setup again, you recreate it fresh from that same known-good starting point, rather than reusing the one you just finished with. The defining property isn't that the environment can be deleted — almost anything can be deleted. It's that deletion is the expected, routine end state, not a cleanup step someone has to remember.

Not the same as a snapshot

A snapshot exists to get you back to a state — it's built around preservation. A disposable environment exists to get you away from a state — it's built around discarding it on purpose. These sound like opposites because they largely are: a snapshot's whole job is remembering; a disposable environment's whole job is forgetting, deliberately, so the next run can't inherit anything the last one left behind. See the concrete version of this for what a Velo restore point actually copies on disk, verified against the app's own source.

Not the same as a container

This is a common conflation worth untangling: disposability and the isolation mechanism underneath it are two separate, orthogonal properties. A container can be disposable (many CI pipelines already treat them that way) or long-lived (a container that's been running in production for months). A VM can be disposable or persistent the same way. "Disposable" describes the lifecycle policy — what happens when you're done — not the isolation boundary itself, which is a completely different question covered in VM vs. container vs. sandbox on macOS. You can have a disposable environment built on either one.

Not the same as a cloud dev environment

Cloud dev environments often get marketed with disposability-adjacent language — "ephemeral," "throwaway" — but the default behavior usually runs the other direction: they persist until you explicitly stop or delete them, and cost accrues the whole time they're sitting idle, forgotten. That's disposable-if-you-remember-to, which is a meaningfully weaker guarantee than disposable-by-default. The fuller comparison, including where cloud environments do and don't have a local GPU story at all, is in the Codespaces and Ona comparison.

The reusable half of the pattern: a known-good starting point

"Just recreate it" only works in practice if recreating is fast and cheap — otherwise disposability is a nice idea nobody actually follows under deadline pressure, and the old habit of reusing a slowly-accumulating environment creeps back in. That's what a base image is actually for: a sealed, known-good starting point that a fresh disposable environment clones from in seconds rather than being built from scratch each time. See base images as versioned infrastructure for how that half of the mechanism actually works.

Why the guarantee matters more than it sounds like it should

The payoff isn't abstract. It removes a specific, recurring doubt — "am I sure nothing's left over from last time" — by making the answer structurally yes rather than probably. A test failure that reproduces against a genuinely identical starting state is real; one that doesn't reproduce is far more likely a genuine race condition than leftover state from three runs ago, which is a meaningfully easier bug to triage. See this play out concretely in the QA/DevOps disposable VM workflow and, for the daily-habit version of the same idea, one workspace per project.