What a TURN Relay Actually Costs to Run
Peer-to-peer transfer is free because nothing passes through our servers. A relay is the exception, and it is worth explaining honestly why that one part has a price on it.
Why a relay exists at all
Most browser-to-browser transfers connect directly. Two browsers discover how they appear from the outside, punch a hole through their respective routers, and send data straight to each other. Our servers introduce the two parties and then stop being involved, which is why an ordinary transfer costs us essentially nothing regardless of whether the file is 10 MB or 10 GB.
Some networks make that impossible. Corporate and campus Wi-Fi, hotel connections, and many mobile carriers are configured so that no direct path can be established at all — the symmetric NAT problem, which no amount of retrying solves. For those cases the only remaining option is a TURN server: a relay that both peers can reach outbound, which forwards the encrypted stream between them.
And that changes the economics completely, because now every byte of your file passes through a machine somebody is paying for.
Bandwidth is the whole cost
A relay does almost no computation. It does not decrypt anything — it cannot, because the encryption is negotiated end to end between the two browsers and the relay is not a party to it. Its job is to receive packets and forward them. The CPU cost of that is trivial.
What it consumes is data transfer, and at twice the rate you might expect. A 1 GB file relayed between two peers is 1 GB inbound to the relay and 1 GB outbound from it. Providers typically bill the relayed volume, but the underlying resource being consumed is both legs.
Managed TURN services price this per gigabyte. Cloudflare's Realtime TURN, which we use as our primary, is on the order of five cents per gigabyte at list price. That number sounds negligible until you multiply it by a service that offers unlimited file sizes to anonymous users. A single person relaying 200 GB in a month costs more than most SaaS subscriptions bring in, and they need no account to do it.
Self-hosting changes the shape but not the existence of the cost. A VPS with a TURN server on it has either a metered egress bill or a monthly transfer allowance that throttles hard when exceeded. You trade a per-gigabyte line item for a fixed cost plus an operational burden: certificate renewal, port configuration, and a service that has to stay up or the fallback silently isn't there.
Why nobody offers unlimited free relay
If you have used a "free, unlimited, no signup" file transfer service and found it worked from a restrictive office network, one of a few things is true. It may be routing everything through its own servers as a normal upload and download, in which case it is a cloud service with peer-to-peer branding and it has your file. It may cap relay usage quietly and degrade when you exceed it. Or it is absorbing the cost from another revenue line and will stop when the sums stop working.
None of those are dishonest, exactly, but they are worth recognising when comparing services. The relay cost does not disappear. It is either priced, hidden inside a subscription, funded by advertising, or paid for by an investor who expects it to stop.
Our choice was to keep every direct transfer free and unmetered — which is the overwhelming majority — and charge only for the case where we genuinely pay per byte. It means an anonymous user with no account can send a 50 GB file at no cost when their network permits a direct connection, and it means we are not quietly subsidising that from somewhere else.
The control that makes the cost bounded
Here is the part that took us longest to get right, and it is the most useful thing in this article if you are running a relay yourself.
Charging per gigabyte bounds what someone pays. It does not bound what they can consume. Those come apart the moment you issue a credential, because what a credential really grants is access to a pipe for a period of time. The consumption ceiling is roughly:
bandwidth ceiling × credential lifetime × number of times it can be reused
Every one of those three needs a deliberate value. Leave any of them unbounded and the worst case is unbounded too, no matter what the customer was charged.
A self-hosted TURN server gives you the first term directly. coturn exposes a per-session bandwidth cap, and setting it is what turns an open-ended bill into an arithmetic one: throughput times time is a number you can calculate in advance and decide whether you can afford.
Managed providers frequently do not give you an equivalent lever, and that asymmetry is worth knowing before you choose one. You get better reliability and global distribution, and in exchange the only ceiling is the network link itself. On a fast connection that is a very different exposure from a capped self-hosted server, for the same nominal price per gigabyte.
The remaining defence is time. Credentials should be short-lived and scoped to a specific transfer rather than issued open-endedly. Short lifetimes have a cost of their own, though, which we found the unpleasant way: set them too tight and a legitimate slow transfer expires partway through, having already been paid for. The right answer was renewing credentials mid-transfer rather than issuing longer ones — a long lifetime raises the worst case for every user in order to accommodate a case that renewal handles for free.
Measure before you set the limits
We sized our first set of limits against the documented throughput ceiling of our own relay, on the reasonable-sounding assumption that transfers would approach it. They did not — observed throughput was roughly three times below what the ceiling implied.
Every timeout derived from that assumption was consequently wrong, in the direction that hurts a paying user rather than the direction that hurts us. A cost control built on an unmeasured number is not a cost control; it is a guess that happens to be enforced.
If you are setting relay limits, spend an afternoon measuring real transfers on connections like the ones your users actually have. Ours are largely Indian mobile and home broadband, so a limit tuned for a fast office link would have stranded precisely the people most likely to need a relay in the first place. That is the group least able to route around the problem, and the group most likely to have paid.
What this means if you are choosing a tool
For the vast majority of transfers, none of this touches you. Direct connections work, cost nothing, and are the faster path anyway. The relay question only arises on networks that forbid a direct route, and the free workarounds are usually available: move one device to mobile data, put both on the same Wi-Fi, or try from a home connection. Any of those restores a direct path and costs nothing.
When none of those is possible — a locked-down corporate network, a deadline, a file that has to move now — a relay is what makes the transfer possible at all. It seemed more honest to price that visibly than to bury it in a subscription that everyone pays and most people never use.