1.1.3.2 Disposable Environments

Disposable environments are environments — typically containers — that are created for a specific purpose and then discarded entirely rather than maintained or patched over time, a pattern Docker makes practical because creating and destroying a container is fast and leaves no residue on the host.

Disposability as a Design Default

A Docker container is, by default, meant to be replaceable: instead of logging into a running container to fix a problem, the usual practice is to fix the image definition and start a new container from it, then discard the old one.

docker stop myapp && docker rm myapp
docker run -d --name myapp myapp:1.1

This habit avoids the slow accumulation of undocumented manual fixes that, over time, makes a long-lived server difficult to reproduce or reason about.

Ephemeral Containers for One-Off Tasks

The --rm flag turns a container into something fully disposable: it is automatically removed the moment it stops, which is useful for one-off commands that should leave nothing behind.

docker run --rm -v "$(pwd)":/app node:20 npm install
docker run --rm alpine sh -c "echo task complete"

Disposable Test Environments

Disposable environments are especially useful for testing, where a clean, known-good environment is needed for every test run, and any state left behind by a previous run should not affect the next one.

docker run --rm -v "$(pwd)":/app myapp:test pytest

Each invocation starts from the same unmodified image, so there is no risk of test pollution carrying over between runs.

Disposable Databases for Local Development

A local database used only for development or testing can be created fresh and thrown away without concern, since none of the data inside it needs to persist beyond the session.

docker run -d --name scratch-db -e POSTGRES_PASSWORD=test postgres:16
docker rm -f scratch-db

Disposability and Recovery

Because disposable environments are recreated from images rather than nursed back to health, recovering from a broken container is usually faster than diagnosing what went wrong inside it — the broken container is removed, and a new one is started from the same known-good image.

docker rm -f myapp
docker run -d --name myapp myapp:1.1

This shifts operational effort away from in-place repair and toward maintaining the correctness of the image definition itself.