With the Docker backend, all user terminals attach to one bridge network (TERMINALS_NETWORK). A Linux bridge supports at most 1024 ports (BR_PORT_BITS=10, kernel compile-time constant). At ~1024 concurrently-running containers, provisioning fails hard:
failed to set up container networking: failed to create endpoint … on network <net>:
adding interface vethXXXX to bridge br-… failed: exchange full
New terminals can't start, and the failure surfaces as an opaque Docker error rather than a clear "network capacity reached" from the orchestrator.
Impact: any deployment expecting >~1000 simultaneous sessions hits an undocumented hard wall. (We reached it via a separate reaper bug leaking containers, but a legitimately busy install would hit it too.)
Requests:
- Document the ~1024-per-bridge ceiling for the Docker backend in the scaling docs.
- Fail clearly — detect the bridge is at/near capacity and return an explicit error/metric instead of the raw exchange full.
- Support scaling past it, e.g. shard across multiple bridge networks (round-robin users), or document/support an ipvlan/macvlan network driver that isn't bound by the bridge port cap.
Environment: Docker backend, single TERMINALS_NETWORK bridge, Linux host.
With the Docker backend, all user terminals attach to one bridge network (TERMINALS_NETWORK). A Linux bridge supports at most 1024 ports (BR_PORT_BITS=10, kernel compile-time constant). At ~1024 concurrently-running containers, provisioning fails hard:
New terminals can't start, and the failure surfaces as an opaque Docker error rather than a clear "network capacity reached" from the orchestrator.
Impact: any deployment expecting >~1000 simultaneous sessions hits an undocumented hard wall. (We reached it via a separate reaper bug leaking containers, but a legitimately busy install would hit it too.)
Requests:
Environment: Docker backend, single TERMINALS_NETWORK bridge, Linux host.