Default bridge network versus user‑defined bridge network for managing Docker IP address exhaustion

Answer

For a CI pipeline that launches thousands of short‑lived containers each day, creating a user‑defined bridge network with a subnet sized to hold the peak concurrent container count is the preferred approach because it lets you control the IP pool size and enables automatic reuse of addresses after containers are removed, whereas the default bridge’s fixed /16 pool cannot be resized and retains IPs until containers are explicitly deleted.

Confirmed facts

The default bridge (docker0) uses a fixed 172.17.0.0/16 subnet (~65 000 addresses) and does not reclaim an IP from a stopped container until the container is removed with docker rm or the --rm flag. A user‑defined bridge lets you specify any subnet via --subnet, and Docker’s IPAM reallocates freed addresses immediately after a container disappears, but changing the subnet later requires deleting and recreating the network, which disconnects any running containers.

Steps to mitigate exhaustion

1. Estimate the maximum number of containers that may run simultaneously in your CI jobs.
2. Choose a subnet that provides at least that many usable IPs (e.g., 10.0.0.0/16 for ~65 k addresses, or a larger block if you expect more).
3. Create the user‑defined bridge:

   docker network create --subnet 10.0.0.0/16 ci-bridge

4. Run CI containers on that network, preferably with auto‑cleanup:

   docker run --rm --network ci-bridge …

5. Monitor usage periodically:

   docker network inspect ci-bridge

   and check the IPAM.Config and Containers sections.
6. If the subnet ever needs to be enlarged, schedule a maintenance window, delete the network (docker network rm ci-bridge), then recreate it with a larger subnet and reconnect the running containers.

To size the subnet accurately, please confirm the typical peak number of concurrently running containers in your CI jobs (or the observed IP exhaustion rate).