How does Testcontainers make sure its containers are removed if the test JVM crashes?

## The problem Ryuk exists to solve A container started by a test outlives the test process by default. If the JVM exits normally, Testcontainers can stop what it started — the JUnit integration calls `stop()`, and there is also a JVM shutdown hook. But test runs die in ways that skip all of that: you hit the stop button in the IDE, CI cancels the job, the kernel OOM-kills the JVM, or the machine loses power. None of those run Java code. Without a second mechanism, a developer laptop or a CI agent slowly fills with orphaned Postgres, Kafka and Redis containers, along with the networks and volumes they were attached to, until Docker runs out of disk or ports. ## What Ryuk is Ryuk (image `testcontainers/ryuk`, project name moby-ryuk) is a tiny Go daemon that Testcontainers starts once per session, before your first container. It runs as a container itself, with the host's Docker socket mounted into it so it can talk to the same daemon your test containers live on, and it publishes its own port to a random host port. When Testcontainers creates any resource — a container, a user-defined network, a volume, or an image built on the fly — it stamps session-scoped labels on it. It then opens a TCP connection to Ryuk and sends a filter expressing "everything with these labels". Ryuk acknowledges the filter and then does nothing except hold the connection open. ## The connection is the heartbeat This is the key design idea, and the thing interviewers want you to articulate: **the open socket is the liveness signal**. Ryuk does not poll, does not run on a timer keyed to your test duration, and does not need the JVM to announce that it is finishing. The operating system closes the socket whenever the JVM process disappears, for any reason at all — clean exit, uncaught error, SIGKILL, container-of-the-build-being-torn-down. Ryuk sees the connection drop and issues the delete calls against the Docker API for everything matching the filter it was given. Because the signal is the absence of a process rather than an action by a process, it survives exactly the failures that shutdown hooks do not. A shutdown hook is code you have to be alive to run; a closed socket is something you cannot avoid emitting once you are dead. ## Ryuk versus the normal path On a healthy run both paths fire, harmlessly. The JUnit integration stops containers at the end of the class or the method, so the resources are already gone by the time the JVM exits and Ryuk finds nothing left to reap. Ryuk removes itself afterwards. Treat Ryuk as insurance, not as your primary lifecycle: a test that leaks containers for minutes inside a long run is still a leak, because Ryuk only acts when the whole process ends. Containers explicitly marked as reusable are deliberately kept out of session-scoped reaping — the entire point of a reusable container is to survive the run that created it, so it is not labelled for the session reaper. ## Requirements and failure modes Ryuk needs to talk to the Docker daemon, which means the socket must be reachable from inside a container. In hardened or rootless environments that is sometimes not permitted, and Testcontainers offers a switch to run without the reaper; the trade-off is that abnormal exits then leak, and you take on cleanup as an operational concern. The other thing worth knowing is that Ryuk is per session, not per container — one reaper watches everything a single JVM created, which is why you see exactly one extra container regardless of how many services your suite starts. ## What to say in an interview A strong answer names the sidecar, explains that cleanup is driven by a dropped socket rather than by cooperative shutdown, notes that it therefore covers `kill -9` and cancelled CI jobs, and adds that labelling is what lets one reaper find every container, network and volume belonging to that session. A weak answer says "Testcontainers uses a shutdown hook" and stops there — which is true of the happy path and useless in the case the question is actually about.