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

Goal: Decide whether to rely on Docker’s automatically created default bridge network or to create a user‑defined bridge network with a custom subnet in order to control the risk of IPv4 address exhaustion in environments with high container churn.

Constraint: The default bridge uses a fixed 172.17.0.0/16 subnet (~65 000 addresses) and does not reclaim IPs from stopped containers until they are removed with docker rm or the --rm flag. A user‑defined bridge lets the operator specify any subnet size (e.g., /20) and enables IP address reuse after container removal, but changing that subnet later requires deleting and recreating the network, which disconnects running containers.

Uncertainty: Teams must weigh the operational simplicity of the default bridge against the administrative overhead of managing custom networks and the need to recreate them when subnet adjustments are needed.

Which approach offers a better trade‑off between ease of use and exhaustion mitigation for a CI pipeline that launches thousands of short‑lived containers daily? Does the ability to choose a smaller subnet in a user‑defined bridge justify the extra step of deleting and recreating the network when the subnet size must be changed? How does automatic IP address reuse upon container removal compare to manual docker rm in preventing gradual address pool depletion?