Upload once, stream everywhere: the math of server-side fan-out

Multistreaming can exceed a home upload connection before the show even starts. If your encoder sends a separate 6 Mbps feed to five platforms, it needs roughly 30 Mbps of upstream capacity, plus room for Wi-Fi overhead and everything else happening in the house.

ApexStream changes that calculation. Your encoder sends one program feed to ApexStream. The relay receives it once and opens the outbound connections to the destinations. Five destinations still create five outbound streams, but they are no longer five copies competing for your home uplink.

The napkin math

Take a 1080p source at 6 Mbps, a bitrate that fits the Hobby ceiling. Without a relay, five full-rate destinations require about 30 Mbps upload. With server-side fan-out, your computer sends about 6 Mbps once; the relay carries the destination copies from its media nodes.

Destination counts are plan-scoped:

• Free: 2 simultaneous destinations
• Hobby: 3
• Creator: 5
• Scale: 8
• Enterprise: 50

At Creator, five destinations can mean roughly 30 Mbps of outbound relay traffic while your connection still sends one 6 Mbps source. At Scale, eight destinations do not change the amount you upload from home. The source still has to fit your plan; fan-out only moves the multiplication point.

What the relay does with that one source

ApexStream accepts RTMP, RTMPS, SRT, or WHIP depending on the plan and workflow. Free and Hobby use RTMP or RTMPS. Creator and above also unlock SRT and WHIP. Web Studio publishes over WHIP into the studio media path.

For each destination, the media node chooses a compatible path. It can copy the source when the platform accepts it, or transcode a destination leg when the rules require it. Those destination-specific paths handle Facebook's roughly 4 Mbps video ceiling, the Free-plan watermark, portrait 9:16 output where available, and audio differences such as Facebook's 44.1 kHz rate versus the default 48 kHz.

This means one source can feed a landscape YouTube stream, a capped Facebook copy, and other destinations without running several local encoders. The relay does not make every platform identical; it keeps their differences from multiplying your local workload.

What this means for a home connection

There is a useful monitoring consequence as well. Your local encoder has one upstream session to keep healthy. The relay still reports destination-specific failures, but a problem on one outbound leg does not automatically require you to rebuild the source profile for all the others.

Suppose your connection has 15 Mbps of usable upload after Wi-Fi overhead. One 6 Mbps program feed leaves room for normal variation, screen sharing, and other household traffic. Three separate 6 Mbps uploads leave no such margin. A short burst from another device can disturb every destination at once.

Fan-out also gives each destination its own failure boundary. If Twitch's ingest has a problem, that outbound leg can go unhealthy without automatically tearing down the single source connection from your home. You should still check the destination, but you do not have to restart the entire encoder because one remote socket had trouble.

Limits still apply at the source

Server-side fan-out is not an unlimited egress promise. The source-quality limits remain:

• Free: 3,000 kbps
• Hobby: 6,000 kbps
• Creator: 9,000 kbps
• Scale: 15,000 kbps
• Enterprise: 50,000 kbps

The source-quality enforcer checks bitrate and resolution after the session begins. A source over the plan limit can be stopped after the probe grace period; fan-out does not turn an over-cap source into a compliant one. Platform rules still apply on the way out, too. Facebook's limit and a plan's ingest limit are different constraints.

One upload is not one identical result

Fan-out also does not remove the need for a wired or stable local connection. One 6 Mbps upload can still fail if the connection is losing packets or competing with a large upload. The benefit is that you are solving one source connection rather than five independent destination connections at the same time.

Each platform still has its own compression, player, latency, and metadata behavior. Server-side fan-out solves the upload equation. It does not promise that every player will look or respond exactly the same.

Multistreaming is partly a bandwidth problem. Upload the program once, then let the relay handle the copies that your home connection should never have to carry.

Size your connection for one reliable feed, choose a bitrate inside your plan, and let the destination-specific work happen after ingest. That leaves you with one source to monitor instead of five local uploads fighting each other.