Repository navigation
Conversation
Re: e2b-dev#3681. TCPFirewallMaxConnectionsPerSandbox (egress TCP firewall) and SandboxMaxIncomingConnections (ingress HTTP proxy) both defaulted to -1 (unlimited). connlimit.TryAcquire treats maxLimit < 0 as always-admit, so the per-sandbox connection limiters that already exist in the orchestrator are INERT in any deployment that does not set these flags — including, by default, a self-hosted / OSS deployment with no LaunchDarkly override. That is exactly the unbounded shared-host-resource boundary e2b-dev#3681 asks about: a sandbox can hold unlimited host connections/goroutines/fds with no per-sandbox accounting. Default both to a generous finite cap (1024) so the limiters are active out of the box. The limiters, metrics, and refusal paths already exist; this only flips the default so they engage. Blast radius: e2b's own deployments set these via LaunchDarkly, which overrides the code default, so prod behavior is unchanged except where LD returns null. Deployments with no override go from unbounded to a 1024 ceiling — strictly safer. Operators raise or disable (-1) per team via the flag. Note on the value: 1024 is a conservative starting point, well above any normal per-sandbox connection count (the e2b-dev#3681 PoC used 32) and in line with existing finite caps in this file (MaxSandboxesPerNode=200, RemoteClusterInstancesPerConnection=64, freeze-guest-hierarchy-max-cgroups=512). The exact number is a deployment policy call — happy to adjust to whatever the maintainers prefer; the flag makes it a one-line change and a runtime override.
AdaAibaby
requested review from
ValentaTomas,
dobrac and
jakubno
as code owners
November 11, 2026 06:02
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fix(featureflags): default per-sandbox connection limits to a finite cap
Re: #3681. TCPFirewallMaxConnectionsPerSandbox (egress TCP firewall) and
SandboxMaxIncomingConnections (ingress HTTP proxy) both defaulted to -1
(unlimited). connlimit.TryAcquire treats maxLimit < 0 as always-admit, so the
per-sandbox connection limiters that already exist in the orchestrator are
INERT in any deployment that does not set these flags — including, by default,
a self-hosted / OSS deployment with no LaunchDarkly override. That is exactly
the unbounded shared-host-resource boundary #3681 asks about: a sandbox can hold
unlimited host connections/goroutines/fds with no per-sandbox accounting.
Default both to a generous finite cap (1024) so the limiters are active out of
the box. The limiters, metrics, and refusal paths already exist; this only flips
the default so they engage.
Blast radius: e2b's own deployments set these via LaunchDarkly, which overrides
the code default, so prod behavior is unchanged except where LD returns null.
Deployments with no override go from unbounded to a 1024 ceiling — strictly
safer. Operators raise or disable (-1) per team via the flag.
Note on the value: 1024 is a conservative starting point, well above any normal
per-sandbox connection count (the #3681 PoC used 32) and in line with existing
finite caps in this file (MaxSandboxesPerNode=200, RemoteClusterInstancesPerConnection=64,
freeze-guest-hierarchy-max-cgroups=512). The exact number is a deployment policy
call — happy to adjust to whatever the maintainers prefer; the flag makes it a
one-line change and a runtime override.