Storybook on-demand builder network connection limits

Short answer

There is no documented Storybook configuration option that sets a connection pool size for the on-demand builder, and no builder-specific default limit is published. In practice, the ceiling you hit is almost never a Storybook setting — it is the Node.js HTTP agent defaults, the dev server's own socket handling, or the operating system's file descriptor limit. So the fix is to tune those layers, not to look for a Storybook flag that does not exist.

What is confirmed vs. what is likely

Confirmed: Storybook's dev server and its builders (Webpack via webpack-dev-server, or Vite) run on Node.js, so outbound and inbound connection behavior is governed by Node's HTTP stack. Node's classic http.Agent historically defaulted to maxSockets: Infinity for the global agent in modern versions (older Node capped it at 5 per host), while keepAlive is off by default for the global agent — meaning sockets are opened and closed aggressively rather than pooled. Vite's dev server and webpack-dev-server each manage their own middleware and WebSocket channels for HMR; HMR itself primarily rides a single long-lived WebSocket per browser tab, not a pool of short connections.

Likely explanation for your exhaustion: during rapid HMR cycles or large story renders, the browser and the builder issue many parallel asset/module requests. Each request consumes a socket and a file descriptor. In resource-constrained environments (containers, CI runners, low ulimit -n), the OS descriptor ceiling is reached long before any application-level pool limit. This matches the symptom pattern better than an internal Storybook cap.

How to verify which layer is the bottleneck

1. Check the descriptor ceiling: ulimit -n in the shell that launches Storybook (containers often default to 1024).
2. Watch live connections during an HMR burst: lsof -p <storybook-pid> | grep -c TCP or ss -s. If the count climbs toward the ulimit, the OS is your limit.
3. Check for socket churn in TIME_WAIT: ss -tan state time-wait | wc -l. High churn suggests missing keep-alive rather than a pool cap.
4. Reduce the story count or disable on-demand loading (storyStoreV7/lazy compilation behavior varies by version) and see whether exhaustion disappears — that confirms correlation with request fan-out.

Practical mitigations

• Raise the descriptor limit: ulimit -n 65535 before starting Storybook, or set the equivalent in your container/systemd unit.
• Limit parallel browser tabs against the dev server; each tab holds its own HMR socket and asset requests.
• If you proxy Storybook through nginx or a corporate proxy, check the proxy's connection limits — they are a common hidden bottleneck.
• Pin and record your Storybook version: connection handling differs meaningfully between v6 and v7 and between Webpack and Vite builders, so any tuning advice should be re-verified after an upgrade.

Uncertainty note: because no documented pool setting exists in current stable releases, treat any blog post claiming a builder.connectionLimit-style option as unverified. If you can share your Storybook version, builder type, and the exact error text seen at exhaustion, the recommendation can be narrowed further.