Upload Once: The Bandwidth Shift That Changed Live Production

Home internet is usually built for downloading video, not sending several high-quality video feeds at once. That difference used to make multistreaming a bandwidth calculation before it was a content decision.

Server-side fan-out changed the calculation. The local setup sends one master feed to a cloud relay. The relay handles the separate destination connections. The creator still needs a stable upload, but the upload is no longer multiplied by every platform in the show.

The old math was simple and unforgiving

Take a 1080p stream at 30 frames per second using about 6 Mbps. One destination needs about 6 Mbps of upload. Three destinations need about 18 Mbps. Five need about 30 Mbps, before leaving room for network jitter, other devices, or a temporary change in ISP performance.

If a connection advertises 30 Mbps upload, using all of it for the streams is not a safe plan. A burst of background traffic can push the encoder into dropped frames, and the problem appears across every destination because every copy originates at the same house.

What “upload once” actually means

With ApexStream, Web Studio or an external encoder sends one incoming stream to the ApexStream ingest path. The relay then forwards it to the destinations you selected. A Free plan account can fan out to 2 destinations, Hobby to 3, Creator to 5, Scale to 8, and Enterprise up to 50, while the local connection still sends one master feed.

This is not magic bandwidth. If the one feed is unstable, the relay receives an unstable feed. The point is to solve the avoidable multiplication: your home connection should not have to carry five copies of the same program.

External encoders can send with RTMP or RTMPS. Creator and higher plans also support SRT and WHIP ingest. Web Studio uses a browser-based path. The choice of ingest protocol affects how the source reaches ApexStream; it does not change the basic fan-out model.

Why the relay is better than asking the laptop to do everything

Local multi-encoding adds two kinds of pressure:

• Network pressure: every destination consumes upload capacity.
• Computer pressure: the local machine has to create, manage, and send multiple outgoing streams.

Single ingest moves the distribution work to the relay. The computer can focus on making one clean program feed, while the relay manages the destination connections and any destination-specific handling. That is particularly useful when one platform has a tighter input expectation than another.

Leave headroom anyway

Upload once does not mean “use every available megabit.” Leave room for normal network variation and background traffic. A good test is to run the stream on the same connection and with the same other devices that will exist during the real show. A speed-test result taken in an empty house is not the same as a stable live path.

If the feed starts dropping frames, lower the source bitrate before adding more destinations. The relay cannot recover detail that never reaches it, and a sharp feed that keeps breaking is worse than a slightly smaller feed that stays continuous.

When single-ingest is the right answer

It is a good fit for a creator sending the same program to several social or video destinations, for a team with limited upload capacity, or for anyone who wants to add a destination without building another local encoder path.

It is not a replacement for a strong source connection, a plan’s bitrate limit, or a destination’s own rules. Facebook can cap the feed it accepts. A social key can expire. A platform can stop a broadcast at its own duration limit. Fan-out solves one part of the system, which is why it is useful.

The bandwidth shift was not “the cloud makes upload free.” It was “the home connection carries one program instead of five copies.” That is enough to make multi-destination production realistic for ordinary networks.

Size the connection for one dependable master, test it with the real show, and let the relay handle the repetition. The production decision becomes editorial again: which destinations deserve the feed, not whether the router can survive it.