Embed: make per-node sandbox limits configurable without LaunchDarkly (max-starting-instances-per-node, max-sandboxes-per-node) #3693

Problem

On a deployment without LAUNCH_DARKLY_API_KEY (every E2B Embed install), feature flags resolve to their compiled-in fallbacks for the life of the process. Two of them are hard per-node ceilings that an operator currently can't change without rebuilding the orchestrator:

• max-starting-instances-per-node, fallback 3 (packages/shared/pkg/featureflags/flags.go). Creates and resumes beyond 3 in flight get 503: not enough capacity for the requested resources right now.
• max-sandboxes-per-node, fallback 200. The 201st running sandbox is refused regardless of host size.

On a larger host, start throughput and the running-sandbox cap become the limit long before CPU or RAM do. Operators should be able to raise both with the host.

Embed already handles this for other flags with env fallbacks: PAUSE_ADMISSION_DISK_HEADROOM_MIB, PAUSE_REFUSAL_RESTORE, ENVD_BINARY_CACHE. These two have no equivalent.

Proposal

#3654 already implements this: MAX_STARTING_INSTANCES_PER_NODE and MAX_SANDBOXES_PER_NODE replace the fallback. A defined LaunchDarkly flag still wins, and zero, negative or unparseable values keep the default. envIntOr has since landed on main, so the PR probably only needs a rebase.

Would you accept this direction? If it helps, we can rebase #3654 or open a fresh PR, and add both variables to the Embed .env and the reference docs.

Environment

• E2B Embed via Docker Compose, orchestrator v0.16.202610051633-d1cd3db3890
• EC2 m8i.2xlarge (8 vCPU / 32 GiB) with nested virtualization, Ubuntu 24.04, kernel 7.0