How TorrentCDN works

Every delivery starts from an origin. A publisher uploads content to object storage; TorrentCDN builds torrent metadata for it and hands the viewer’s browser a magnet link. From there the player tries to fetch pieces from other viewers watching the same content (WebTorrent over WebRTC), and keeps the origin available as the authoritative fallback.

The consequence is a mixed path: a conventional origin (or CDN edge) remains responsible for first playback, for content nobody else is watching, and for every viewer that cannot participate in a swarm. Peers carry whatever share of the transfer they can.

Delivered files are stored in object storage and served from unlisted public object URLs. Production uses Supabase’s S3-compatible storage through the standard S3 API, so the origin can be changed to another S3-compatible provider without changing the delivery model.

Provider

Supabase (S3-compatible object storage)

Bucket

torrent-cdn-files

S3 region

us-east-1

Role

Origin and fallback source for every file

Not the origin

The application host — Render (Oregon, US West) runs the TorrentCDN backend/API, it does not store or stream the media bytes

Fallback

If no suitable peers are reachable, the player switches to direct origin delivery — the same file, fetched over HTTPS from the Supabase object-storage origin. The connect window is about 5 seconds before the fallback fires; when a peer connection has already been established the window extends to 15 seconds so a healthy swarm is not abandoned early. Playback continues either way.

Nothing is installed by the viewer: delivery runs inside the page, from the embed script or the hosted player. Peer-assisted delivery relies on two browser capabilities.

• WebRTC data channels — required for peer connections. Where they are unavailable the player does not fail; it delivers directly from the origin.
• MediaSource with a supported codec — allows progressive playback while pieces arrive. For a codec the browser cannot play through MediaSource, the file is buffered in full first and then played, so start-up is slower.

Current Chromium-based browsers, Firefox and recent Safari provide both. Our automated delivery tests run in Chromium; other engines are supported targets but are not covered by the same test matrix. In all cases the origin path keeps playback working — the difference is whether peers can share the load.

Traffic to a popular file is highly redundant: many viewers request the same bytes within the same minutes. In a purely origin-based model every one of those requests is served by the origin or an edge. In this model a viewer can serve neighbours instead — so as concurrency on a file grows, the potential supply of upstream capacity grows with it, and a larger share of the transfer can be satisfied between viewers.

This is what makes cost per viewer fall rather than rise. It is equally important to state the limit: peers only carry what they already have or are fetching, on connections they can sustain. First viewers of a file, viewers behind restrictive networks, and any poorly-seeded moment are still served by origin or edge. Peer assistance reduces origin load; it does not remove it.

TorrentCDN is not trying to replace traditional CDN infrastructure — the two solve different halves of the same problem. Peer assistance is strongest when many viewers watch the same content at the same time; it is weakest when a viewer is alone, early, or poorly connected. That is exactly where edge infrastructure is strongest.

A conventional CDN / edge provider can supply:

• · Origin and fallback delivery when peers are unavailable
• · Regional edge capacity close to viewers — lower latency on first playback and for cold content
• · Additional resilience when a swarm, network or region degrades
• · Coverage in regions where viewer uplinks are constrained

An East African edge or origin layer is a concrete example: it can shorten the first-fetch path for viewers there, while TorrentCDN’s peer path carries the repeated traffic that follows. Both paths can serve the same session — a viewer may start on edge/origin, then receive later pieces from peers, or fall back to edge/origin mid-playback.

Fallback / complementary path

same viewer, either path, at any point in the session