I Started Deleting My Test Environments After a Single Use. It’s the Best Decision I Ever Made.

Last month I accidentally ran rm -rf / inside a Docker container that was sharing my home directory. I wiped half my dotfiles, killed a local database, and spent the evening restoring from backup. It was the kind of mistake that happens once. After that, I started treating test environments the way SpaceX treats its prototypes: build fast, test hard, throw them away when you're done.

SpaceX doesn't baby a rocket design through years of polish before testing. They weld it together, light the engines, and often watch it blow up on the pad. Each failure is a data point. The team learns, scraps the hardware, and starts the next iteration with better assumptions. That rapid, disposable approach to testing is a perfect model for the kind of work developers do every day: risky experiments, AI-driven refactors, kernel tweaks, or just poking at a tool that might break something.

The Rocket Test Stand Philosophy

When you treat a test environment as a permanent thing, you end up with accumulated state. Old config files, half-installed packages, processes you forgot about. That state masks problems and makes failures hard to reproduce. A disposable environment removes all that. Every test starts from a known clean image. If you break it, you don't fix it. You delete it and start a new one in seconds.

This is exactly why SpaceX builds multiple identical test articles. They never reuse a test tank that might have hidden fatigue. Every destructive test happens on hardware that was meant to be sacrificed. Software testing deserves the same clarity. Your test server should be a consumable, not a pet.

Why Local and Production Are Terrible Sandboxes

Running experiments on your local machine risks clobbering your development environment. Even with containers, volume mounts can leak, you can accidentally bind to the wrong port, or a kernel module test can panic the OS. Production is even worse. Nobody wants to be the engineer who took down the staging database to try a new migration pattern.

I've moved all my dirty work to remote, ephemeral Linux shells. They give me root on a clean machine that doesn't share anything with my laptop or our infrastructure. When I sign off, destruction is a single command.

Spinning Up a Disposable Shell with xShellz

Here is the real, no-bull workflow I use daily. I keep an xShellz account for on-demand Linux boxes. Creating one takes a few seconds:

$ xshellz create --distro ubuntu-22.04 --plan light
created shell "exp-20250321" (IP: 203.0.113.42)
$ ssh [email protected]

I now have root on a bare Ubuntu instance that nobody else touches. I install the tools I need, clone a repo, and run whatever wild idea is in my head. When I'm done:

$ xshellz destroy exp-20250321

That's it. No lingering state, no bill for idle hours. If I need to keep a session alive while I step away, I launch tmux and detach. The shell stays up until I explicitly destroy it, but I treat it as disposable by habit.

Running an AI Refactor Without Trashing Your Machine

One of the best use cases for disposable environments is handing the reins to an AI coding agent. Our team has been using borg (the terminal-based AI agent from xShellz) to refactor large codebases. I would never let an LLM run arbitrary shell commands on my main machine. Instead, I spin up a shell, clone the repository, give borg the instructions, and watch.

$ borg refactor --target /home/user/repo --instructions "convert all error handling to a custom Result type"

If the agent does something destructive or generates hundreds of broken files, I discard the environment and rinse, repeat. No version control tangles, no local filesystem leftovers. Just a clean slate for the next run.

The Trade-Offs (and Why I'm Okay With Them)

Ephemeral shells have no persistent storage by default. If you need to preserve a particular test result, you have to push it to a git branch or copy artifacts out before destroying the box. For me, that's the point. The tiny overhead of rsyncing a log file or committing experimental code forces me to be intentional about what I keep. It's a lot better than cleaning up after a midnight disaster.

Some workflows need a process that stays online across reboots, like a long-running IRC bouncer. That's a different problem, and xShellz offers always-on bouncers for that. But for testing, ephemeral is the healthier default. The friction of provisioning a new shell is so low that there's no excuse to recycle old ones.

When Persistence Matters

I won't pretend every use case is ephemeral. When I'm running a CI-like job that needs to cache intermediate build artifacts, I'll use a mount. Some users tie a persistent volume to their shell. But even then, I still treat the shell itself as replaceable. If the environment gets corrupted, I re-create it and re-attach the volume. The shell is a commodity, not a snowflake.

This shift in mindset saved me more time than any tooling change in the last year. I stopped wasting cycles debugging broken state and started spending them on the actual experiment. If you're still nursing a development VM that's a year old, ask yourself: could you blow it up right now and be back to productive in under two minutes? If not, you've probably got a testing problem that a disposable approach would fix.