Disposable by Design: Ephemeral Cloud Environments From a Docker Compose File

A Docker Compose File Is Already a Full Specification

Chalupa’s job is narrow: take a project’s existing docker-compose.yml, and stand up a short-lived, real copy of it on DigitalOcean. The interesting decision was refusing to make users describe their infrastructure twice. Instead of a second, hand-maintained inventory of services, ports, and volumes, Chalupa infers all of it directly from the Compose file already sitting in the repository, and layers a small config file on top for the handful of things Compose does not express — which services get exposed, and how.

“Exposed” is deliberately minimal. Every service port binds only to the droplet’s loopback interface — not to the public internet — and the only way in is an SSH tunnel. The firewall in front of the droplet allows nothing but SSH, and only from explicit source addresses. There is no public port for the application to leak from, because there is no public port. That is not a hardening pass applied at the end; it is the default shape of every environment Chalupa creates, and there is no flag to turn it off.

Show What You Are About to Do Before You Do It

chalupa up runs a specific sequence, and the sequence itself is a design decision. It validates the configuration, then shows a redacted preview of everything it is about to provision — the droplet, the firewall rules, the services, the volumes — before it touches the cloud at all. The operator confirms against that preview, not against a mental model of what the tool probably does.

The same discipline applies on the way down. chalupa down destroys the compute and reports exactly what it destroyed. Provisioning a disposable environment should feel cheap, but it should never feel vague: at every point, the tool can tell you what exists, what it costs, and what will happen when you tear it down.

Compute Is Disposable, Data Is Not, and the Split Is Structural

The core of the design is a boundary. Chalupa keeps two separate Pulumi stacks per environment: a compute stack that is genuinely disposable, and a second, separate data stack that owns the one persistent resource — a storage volume — that survives when compute does not.

Tearing down an environment tears down compute. It does not touch the data stack, because the two are not the same program sharing state; they are two separate programs with two separate lifecycles, and destroying one has no path to reach the other by accident. Deleting the persistent volume — the one thing that is allowed to be irreversible — is its own explicitly named operation, separate from down. Someone tearing down a disposable environment should not be one flag away from also destroying the data it was attached to.

This split is what makes “ephemeral” honest. Plenty of tools call environments disposable while quietly accumulating state that makes teardown scary. If destroying compute is ever risky, people stop destroying it, and the ephemeral environment becomes a small, expensive pet. Making the destructive path safe by construction — rather than by careful operator behavior — is what keeps the environments actually cheap to throw away.

Boundaries Beat Conventions

It would have been less work to keep one stack and lean on naming conventions: tag the volume protected, write a warning in the README, trust the operator to read both. Conventions like that hold right up until the moment someone is tired, or new, or scripting the tool from CI — which is exactly when the boundary matters most.

The recurring pattern in Chalupa is that anything worth protecting gets a structural boundary, not a convention. The volume that must survive lives in a different stack, not behind a warning. The services that must not be public are unreachable by default, not reachable-but-documented. The irreversible operation has its own name, not a --force flag on the reversible one. In each case the safe behavior is the path of least resistance, and the dangerous behavior requires deliberately asking for it.

The Takeaway

None of this is a story about a clever infrastructure trick. It is a story about deciding, before writing the tool, which things are allowed to be ephemeral and which are not — and then making that decision structural instead of behavioral. Frame the boundary first: what is disposable, what survives, who can reach what. Build so the boundary is enforced by the shape of the system, not by operator care. Prove it by tearing environments down and back up until doing so is boring. Transfer the reasoning in writing, so the next engineer extending the tool knows which lines are load-bearing.

A client working with us should expect the same shape of thinking on their own infrastructure: not a longer checklist, but a clear account of which operations in their system are irreversible, which boundaries are structural versus conventional, and what it would take to make the destructive paths safe enough to be routine.

If your team needs real, disposable environments for testing or review without babysitting cloud infrastructure by hand, try Chalupa. For more of what we build this way, see our projects and our services, or get in touch.