Devon Aguirre

The question that decides this is not Docker versus microVM, it is: who writes the text that becomes a command? Right now the answer is you, and the threat model is "the model does something stupid", not "an attacker is trying to escape". A container is entirely adequate for stupid. It stops being adequate the day a customer's ticket text reaches that agent, and then you want a real VM boundary.

Ephemeral container per run, and specifically:

• fresh container each run, --rm, no reuse
• non-root user, --read-only rootfs with a writable tmpfs for the workspace
• --cap-drop=ALL, --pids-limit, a memory limit
• never mount the docker socket in, which is the one mistake that turns all of the above into decoration
• --network=none unless the run needs the network, and if it does, an allowlist proxy rather than open egress

At 200 runs a day the container start cost is irrelevant and you can build this in an afternoon. Do that, and revisit the day untrusted input enters the picture.

It is the single most common mistake and it is not obvious, because everything works and nothing warns you. Anything with the socket can start a privileged container mounting the host root, so you have handed it the machine. If a run needs compose, give it docker-in-docker or a nested runner, never the host socket.

Whichever you pick, deal with the bag juices. Chuck throws off a lot and they make an excellent sauce reduced in a pan with a spoon of the fat skimmed off, but they will also make your sear steam if you do not dry the meat first. Two separate jobs, do not skip either.

The soft feel throws everyone. You are used to judging doneness by firmness and that cue simply does not work here.