Why does creating a custom network start Ryuk (ResourceReaper) immediately?

[JaySabva]

I’m seeing testcontainers/ryuk start as soon as I create a custom network, even when launching a single container. In CreateNetworkCmd setup, Testcontainers calls ResourceReaper.instance().getLabels() to
add cleanup labels:

labels.putAll(DockerClientFactory.DEFAULT_LABELS);
//noinspection deprecation
labels.putAll(ResourceReaper.instance().getLabels());
createNetworkCmd.withLabels(labels);

This call appears to initialize ResourceReaper, which starts Ryuk even when reuse is enabled. Is this expected? Is there a way to avoid starting Ryuk when creating a network (without globally disabling Ryuk or relying on reuse)?

[rameshreddy-adutla]

This is by design! Here's why:

Ryuk (ResourceReaper) is the cleanup safety net. Its job is to ensure that Docker resources (containers, networks, volumes) created by Testcontainers are cleaned up even if your JVM crashes or tests are killed.

When you call Network.newNetwork(), Testcontainers adds cleanup labels to the Docker network:

labels.putAll(ResourceReaper.instance().getLabels());

Calling ResourceReaper.instance() triggers lazy initialization — this is the first time Testcontainers needs the Ryuk session ID to generate labels. The session ID is created by Ryuk at startup, so Ryuk must be running before any labeled resource is created.

Why not defer Ryuk until a container starts?
Because networks are also Docker resources that need cleanup. If your test creates a network but crashes before creating any container, Ryuk needs to already be running to clean up that orphaned network.

If you want to avoid early Ryuk startup:

1. Use @Testcontainers annotation — it manages lifecycle for you
2. Set TESTCONTAINERS_RYUK_DISABLED=true (only in CI where containers are cleaned up by the environment)
3. Avoid creating networks before containers — let Testcontainers handle networking

The overhead of Ryuk starting early is minimal (~1-2s, ~12MB RAM). It's a small price for guaranteed cleanup.