Your Stream, Your Edge: Media Placement Policy
When a broadcaster goes live in Europe and someone opens the stream in the United States, that viewer should be served from a healthy US edge. Until this release, the answer depended partly on which part of the platform happened to receive the viewer’s request: arrive at a European coordinator, and “nearby” was measured from Europe.
Media placement treats three locations separately: where a request is answered, where a stream originates, and where a viewer receives it. The viewer’s distance is measured from the viewer, and accounts can now state their own rules about which capacity their streams may use.
Nearby means near the viewer
Section titled “Nearby means near the viewer”Federation gave clusters a way to find streams and source them from one another. Placement decides where that capability should be used.
Every eligible edge is compared on the same facts: health, usable capacity, distance to the viewer, and whether the stream is already there or needs a source connection. A cluster boundary is not a distance penalty. An edge in Virginia does not become less attractive to a viewer in Virginia because the request reached a coordinator in the EU.
When the chosen edge does not have the stream yet, it is pulled there. The first viewer may pay some setup latency; later viewers reuse the copy. If the chosen edge cannot accept the work, the next permitted candidate is tried, rather than whatever node sits next to the coordinator that answered.
My own servers first
Section titled “My own servers first”Nearby is only part of the answer. Some accounts run their own edge servers and want the platform to treat them as the first choice, not one option among many.
Take a broadcaster who operates two edge servers in their own facility in Frankfurt and also has access to platform capacity. Their account rule says: serve viewers from my servers first, and use platform capacity only when mine are full or the viewer is too far away.
A viewer in Berlin is served from the broadcaster’s own servers, as they would expect. A viewer in Chicago is beyond the distance threshold the broadcaster configured, so the rule permits spillover and that viewer is served from a platform edge in the US, which pulls the stream across once. During a large event the Frankfurt servers fill up, and new European viewers spill onto platform capacity while existing sessions stay where they are.
The preview for that rule shows which capacity groups qualify, why a candidate was excluded, and which condition would permit spillover. It is careful about evidence: a self-hosted cluster that cannot be reached is not treated as proof that it is full, and a missing price is not treated as free.
The same rule could be stricter. “Prefer” and “never” mean different things: a preference can fall back, a prohibition cannot. If an account says never to use platform capacity and its own servers have no room, the stream is reported unavailable rather than moved onto paid capacity. Ingest and serving have separate rules, because the best place for a broadcaster to publish is not necessarily the best place for every viewer to watch. Account defaults cover the ordinary case; stream-specific rules can narrow them.
The choice is two-sided: a cluster owner can offer viewer capacity without accepting publishers, and your preference for a cluster does not grant you access to it.
Enforced where media actually starts
Section titled “Enforced where media actually starts”Placement is enforced at the two points where media starts: when a publisher connects and when a viewer connects.
For publishers, the policy is checked against the protocol the edge actually observed accepting the connection, never against the URL the encoder sent, because the encoder controls that URL and RTMP lets a client label a connection however it likes. A publisher that lands on a node the policy forbids is refused, and nothing is held for a session that never starts.
For viewers, the same policy that chose the destination admits the connection at the edge. A denied HLS request gets a complete refusal and a closed connection instead of a response that never finishes, so players fail over instead of stalling.
The rules reach the edge as signed authority, which matters during outages. A control-plane outage does not turn a deny into an allow. A publisher who is already live stays live, and edges keep enforcing the last rules they received. During an outage, availability can be limited, but policy is never widened.
What it does not cover yet
Section titled “What it does not cover yet”Saving a rule is not the same as every connection following it. A new rule takes effect once every cell that holds your content confirms it enforces placement, and the rollout status shows where that stands. A publisher who is already live stays on their current ingest cluster; changing the rule does not migrate them.
This release covers ingest and viewer delivery. Where recordings are stored and where processing jobs run are separate decisions on the roadmap, and viewer-serving rules do not control them today.
The media placement guide covers writing, reviewing and previewing rules, including the self-hosted-first example in the API Explorer demo. Cluster owners should read media placement controls for capacity permissions and rollout status.