Fundamentals

What Is a Disposable Development Environment?

This blog uses the term constantly and has mostly assumed you know what it means. Here's the definition, and the three things it's most often confused with: a snapshot, a container, and a cloud dev environment.

By Gaoliang Luo · Published September 22, 2026 · Updated September 28, 20262 min read

In this article

The pattern: create, use, discard, recreate
Not a snapshot
Not a container
Not a cloud dev environment
The reusable half: a known-good starting point
Why the guarantee matters

The pattern: create, use, discard, recreate

A disposable development environment is one where throwing it away is the default, not something you have to remember to do. You create it, usually from a known-good starting point rather than from scratch, use it for one task, and it's gone when the task ends, with nothing surviving to affect the next one. When you need the same setup again, you create a fresh one from the same starting point instead of reusing the last. The defining property isn't that it can be deleted (almost anything can). It's that deletion is the normal ending, not a cleanup step.

Not a snapshot

A snapshot exists to get you back to a state; it's about keeping. A disposable environment exists to get you away from a state; it's about discarding on purpose, so the next run can't inherit anything from the last. Disposable VM vs. snapshot shows what a Velo Workspaces restore point copies on disk, for the concrete version.

Not a container

Disposability and the isolation underneath it are separate properties. A container can be disposable (many CI pipelines treat them that way) or long-lived (one that's run in production for months). A VM can be either too. "Disposable" describes the lifecycle, what happens when you're done, not the isolation boundary, which is a different question covered in VM vs. container vs. sandbox on macOS.

Not a cloud dev environment

Cloud dev environments often use disposable-sounding words like "ephemeral", but by default they usually persist until you stop or delete them, and cost money the whole time they sit idle. That's disposable if you remember, which is a much weaker guarantee than disposable by default. The Codespaces and Ona comparison has the full picture, including the missing local GPU.

The reusable half: a known-good starting point

"Just recreate it" only works if recreating is fast and cheap. Otherwise disposability is a nice idea nobody follows under deadline, and the habit of reusing a slowly cluttering environment creeps back. That's what a base image is for: a saved, known-good starting point that a fresh environment clones from in seconds. In Velo Workspaces, disposable workspaces and saving base images are part of Pro; base images as versioned infrastructure covers how they work.

Since 1.2 there's a second fast starting point: an official cloud image. A fresh Ubuntu, Debian, Fedora or Rocky Linux workspace is ready about a minute after the download, and the image stays in your library, so the next one starts even sooner.

Why the guarantee matters

It removes a recurring doubt, "am I sure nothing's left over from last time?", by making the answer yes by construction rather than probably. A test failure that reproduces from an identical starting state is real. One that doesn't is more likely a race condition than leftovers from three runs ago, which is a much easier bug to chase. See it in practice in the QA and DevOps workflow and, as a daily habit, in one workspace per project.