A managed TURN server is a hosted NAT-traversal relay run by a provider, so you skip deploying and scaling coturn yourself. It relays WebRTC media when a direct peer connection fails behind firewalls or symmetric NATs. You use one when reliability, global regions, and predictable operations matter.
This guide defines the category and gives you a seven-point framework for choosing a provider.
TURN sits at the unglamorous center of every real WebRTC product. When your video call works on your laptop but dies on a customer's corporate network, TURN is the missing piece. The question is rarely whether you need it — it's whether you host it or buy it.
TL;DR: A managed TURN server is TURN-as-a-service: a provider hosts, scales, and secures the relay infrastructure WebRTC needs to cross firewalls. Choose one on seven criteria — regions, ports 80/443 + TURNS, documentation and API, bundled signalling, SLA, support, and data residency.
What is a managed TURN server?
A managed TURN server is TURN relay infrastructure that a vendor runs for you, delivered as a paid or free-tier cloud service. You get credentials and an endpoint; the provider owns the servers, the bandwidth, the ports, the TLS certificates, and the uptime.
TURN stands for Traversal Using Relays around NAT. It is defined in IETF RFC 8656, and it exists because most devices sit behind network address translation that blocks unsolicited inbound traffic.
Here's the short version of how WebRTC connects two peers. First it tries a direct connection. When that fails, STUN helps each peer discover its public address.
When that still fails — think symmetric NAT or a locked-down firewall — TURN relays the media through a public server both peers can reach.
STUN only discovers addresses. TURN carries your actual audio and video, which is why it is the piece that has to be engineered for scale.
Managed TURN vs raw TURN vs STUN — the three-way distinction worth getting straight:
- STUN tells a peer its public IP. It relays nothing.
- Raw (self-hosted) TURN is coturn on your own servers. Free software, but you own the ports, certs, patching, scaling, and bandwidth bill.
- Managed TURN is that same relay function bought as a service, with regions, SLAs, and credential APIs handled for you.
A managed TURN server matters most for the sessions that can't connect directly — a share measured at roughly 8–20% of WebRTC sessions. That share varies by audience: consumer apps on home Wi-Fi fare better; enterprise, healthcare, and mobile-carrier networks fare much worse. When relay fails, the call simply doesn't connect, so TURN is not optional for a serious product.
Managed TURN vs self-hosted coturn — which do you actually need?
If you are building a serious product, buy the relay. Self-hosting coturn is always available, but it is not free, and it does not become the cheaper option as you grow — it becomes the more expensive one.
Running your own coturn server carries three distinct costs: the hosting bill for every region you deploy to, the bandwidth fees for the media you relay, and the DevOps hours to build, secure, and keep it running.
The first two are visible on an invoice. The third is the one that decides this.
The engineering burden is not a fixed startup cost you pay once and then outgrow. It grows with your own product — every sign that things are going well is also more relay work.
Launch in one region and you have one server to patch. Pick up users on another continent and you need relays near them, plus the routing to send each session to the right one.
Some of your users will be on locked-down office Wi-Fi or restrictive mobile networks, so you add TURNS on port 443 and inherit certificate rotation with it. And once enough of your traffic depends on relay, a relay outage is an outage of your app — so somebody on your team is carrying a pager for it at 3am.
If your product touches payments or health data, the region-pinning and fixed-IP work lands on you as well, because it is your compliance story now, not a vendor's.
None of that is a one-time build. It is a permanent line item that grows as your product does — which means it arrives fastest exactly when you are busiest shipping the features people came for.
DATED FACT BLOCK — the self-hosting reality (2026-08-11)
- You own the patch treadmill. Example: CVE-2025-69217 (published Dec 2025) affected coturn 4.6.2r5 through 4.7.0-r4 — a weak random-number generator let an attacker predict nonces after ~50 unauthenticated allocation requests and spoof authenticated traffic. It's fixed in current releases, but you have to notice and patch it. (Sources: NVD, coturn GHSA-fvj6-9jhg-9j84.)
- You own the ports, the TLS certs, the DDoS exposure, and the bandwidth bill on every region you deploy to.
To be clear about what is and isn't being claimed here: coturn is excellent software. We maintain a full guide to deploying it.
The question isn't whether coturn is good. It's whether running relay infrastructure is your product. For a serious player it almost never is — and every hour spent on certificate rotation and CVE triage is an hour not spent on the thing customers actually pay you for.
Self-hosting "to save money" is where the savings turn notional. The infrastructure bill you avoided shows up as engineering salary, on-call fatigue, and a security surface you now own — and it arrives on the Friday a CVE lands, not on a schedule you chose.
How to choose a managed TURN provider
Pick a managed TURN provider on seven criteria, in this order: regions, ports, documentation and API, bundled signalling, SLA, support, and data residency. Price is a tiebreaker, not the headline — the cheapest relay that can't traverse your customer's firewall is worthless.
Here's the checklist in detail.
1. Regions and PoPs. Relay latency is dominated by distance. A provider with points of presence near your users adds far less delay than one routing every call through a single continent. Ask how many regions, and whether you can pin traffic to specific ones.
2. Ports 80/443 and TURNS/TLS. This is the criterion that separates a demo from a product. Restrictive corporate firewalls block UDP and odd ports but allow 443. A TURN server that speaks TURNS (TURN over TLS) on port 443 looks like ordinary HTTPS and gets through where a 3478-only server fails. If a provider can't do 443, it can't serve locked-down networks. See our TURN over ports 80 and 443 guide for the deep dive.
3. Documentation, API, and AI-readability. This is the criterion that decides how fast you ship. Buying a managed relay should mean one afternoon of integration and then nothing: read the docs, call the credential endpoint, hand the ICE servers to your peer connection, and move on to your actual product. The relay is the provider's job to run from that point forward.
Ask what the API actually gives you. You want a REST surface that mints short-lived, per-session credentials, scopes them per project, and reports your usage.
Then ask the 2026 question: are the docs machine-readable? Your coding assistant is writing the integration alongside you, and it can only be as accurate as what it can retrieve. Providers that publish plain-text reference files for LLMs get correct generated code on the first pass; providers whose API sits behind JavaScript-rendered pages get confidently invented endpoints.
Metered documents 28 REST endpoints and publishes a full set of machine-readable .txt references at metered.ca/docs/build-with-ai, including a complete TURN reference — so you and your assistant both have the entire surface in front of you from the first line of code.
4. Bundled signalling. TURN is only half the job. Every WebRTC app also needs signalling — the exchange that carries SDP offers, answers, and ICE candidates between peers before any media flows. Most dedicated TURN providers sell relay only and leave that half to you, which means a second vendor, a second bill, and a second thing to operate.
So ask whether signalling is included, and if it is, ask the two follow-ups that decide whether it's real: is the client open-source, and are TURN credentials injected automatically at connect time — or are you back to embedding them yourself? Metered's paid TURN plans carry a bundled Realtime Messaging allowance that handles SDP/ICE exchange, presence, and pub/sub, with your TURN credentials auto-injected into the connection's welcome message. The client is @metered-ca/realtime, MIT-licensed and open-source, so nothing about the arrangement locks you in.
5. SLA. A published uptime guarantee (and the credits behind it) tells you whether the provider treats relay as a product or a side feature.
6. Support. Every so often a user sits behind a network nobody has seen before — an unusual corporate proxy, a carrier-grade NAT, a country-level filter. You want someone on the other end of the line who has seen that network before, at the hour it happens, not a ticket queue measured in business days.
7. Data residency and fixed IPs. Regulated workloads (payments, healthcare) often need traffic to stay in a region and to originate from fixed, allowlistable IPs. Anycast networks are fast but can't promise either. If you need GDPR or HIPAA alignment, this criterion can outrank price entirely.
The evaluation matrix — what to ask before you sign
Take this table into every vendor conversation. The middle column is the question to ask; the right column is why the answer decides the purchase. Providers churn their pricing pages constantly, so score the capabilities — they change far more slowly than the rate card.
| Criterion | Ask the provider | Why it decides the purchase |
|---|---|---|
| Regions & PoPs | How many regions, how many edge PoPs, and can I pin a session to one? | Relay adds a hop; distance is the dominant term in added latency. No nearby PoP means audible delay. |
| Ports 80/443 + TURNS | Do you serve TURNS over TLS on 443 — on the free tier as well as paid? | 3478-only relay fails on exactly the restrictive corporate networks that made you buy TURN. |
| Docs, API & AI-readability | Is there a REST API for short-lived per-session credentials — and are the docs published as machine-readable references an LLM can retrieve? | Decides how fast you ship. Static-only credentials can't be rotated or revoked; unretrievable docs mean your coding assistant invents endpoints. |
| Bundled signalling | Is signalling included? Is the client open-source, and are TURN credentials auto-injected at connect time? | TURN is half the job. Buying the other half separately means a second vendor, a second bill, and a second thing to operate. |
| SLA | What uptime is contractually guaranteed, and what credits back it? | Distinguishes a relay product from a relay side-feature. |
| Support | 24/7 human support, or ticket queues measured in business days? | A user who can't connect from a network you can't reproduce is a same-day problem. |
| Data residency & fixed IPs | Can you guarantee in-region traffic and give me fixed, allowlistable IPs? | Anycast can't promise either. For payments and healthcare this can outrank price entirely. |
Scope note: this guide covers dedicated TURN — relay bought as a managed service, and coturn self-hosted.
What you actually get
Metered gives you fixed, allowlistable IPs, region pinning and data residency (GDPR/HIPAA), a standalone TURN product, an **SLA up to 99.999%, and 24/7 human support.
For a payments or healthcare product or anyone that has to route traffic through a specific region from a known IP, that control is the product.
Managed TURN in the AI-agent era
Managed TURN matters more, not less, as AI voice and video agents ship. Server-to-server and headless agent connections can't lean on the browser-side direct-path optimizations that consumer calls use, so a much larger share of agent traffic ends up relayed through TURN (InfoQ, 2026).
That shift is already visible in the market: through 2026, dedicated TURN providers have been repositioning their messaging around AI voice and video agents. The reliability bar for an always-on agent is higher than for a human call.
For agents you want the same things, turned up: relay near the model and the user, ports 443/TURNS so the agent works from inside restricted networks, and short-lived credentials minted per session. We go deeper in TURN for AI voice agents.
Getting started with Metered's managed TURN
If you want a managed TURN server with fixed IPs, region pinning, and 24/7 human support behind it, Metered's TURN service is built for exactly that.
METERED TURN — capabilities (single reference block, verified against
/stun-turn)Free to start
- Open Relay: 20 GB/month free TURN — openrelay.metered.ca
- Metered TURN product: 500 MB free trial, then paid plans — current tiers on the TURN service page
Platform
- 31+ regions, 100+ edge PoPs, sub-30 ms typical latency
- Ports 80 and 443, TURNS/TLS, TCP + UDP
- Fixed IPs, region pinning, auto-geo routing, data residency
- REST credential API (short-lived, per-session credentials) + machine-readable docs for AI coding assistants
- Bundled signalling — Realtime Messaging allowance on paid plans: SDP/ICE exchange, presence, pub/sub, TURN credentials auto-injected at connect time; MIT-licensed open client
- Up to 99.999% uptime (Enterprise), 24/7 support
Getting a working relay takes minutes. free turn server is also available via Open Relay project, then request dynamic credentials from the REST API so every user session gets its own short-lived TURN credentials — no static secret in your client.
TURN is only half the stack: every WebRTC app also needs signalling. Metered includes managed signalling free with TURN, and the open-source MIT-licensed @metered-ca/realtime SDK is the client for it — it connects to Metered's stack and injects your TURN credentials for you. Before you ship, test your TURN server to confirm relay candidates actually appear.
Teams building in security, payments, and healthcare choose managed TURN for the parts a feature list never captures: a fixed IP to hand their own security reviewers, traffic that provably stays in-region, and a human to call when a user's network misbehaves.
[IMAGE_PLACEHOLDER: getting-started]
Frequently Asked Questions
[IMAGE_PLACEHOLDER: faq]
What is a managed TURN server?
A managed TURN server is TURN relay infrastructure hosted by a provider and consumed as a service. It relays WebRTC audio and video when peers can't connect directly through firewalls or symmetric NATs. You get an endpoint and credentials; the provider owns the servers, bandwidth, ports, TLS certificates, scaling, and uptime, so you never deploy or patch coturn yourself.
Managed TURN vs self-hosted coturn — which should I choose?
Compare all three costs, not just the bandwidth line. Self-hosting coturn means paying for hosting in every region you serve, paying the relayed-media bandwidth bill anyway, and funding the DevOps hours to configure TLS on 443, rotate certificates, track security advisories, run an on-call rotation, and scale relays. Managed TURN collapses all of that into one predictable number.
The engineering half doesn't shrink as you grow. More regions, more users on restrictive networks, and a higher uptime bar each add work — so for a serious product, buying is cheaper where it counts.
Do I need a TURN server, or is STUN enough?
Try STUN first — it's nearly free and handles most connections. But a meaningful minority of WebRTC sessions can't connect directly, and for those you need TURN to relay the media; the share is higher on enterprise, healthcare, and mobile-carrier networks. Without TURN, those calls simply fail, so any production app needs a TURN server available.
Which managed TURN provider is best?
It depends on your constraints, so score every candidate on the seven criteria above and treat price as the tiebreaker. If you need fixed allowlistable IPs, region pinning, data residency, a published SLA, a predictable flat bill, and 24/7 human support, that is precisely what Metered is built for. A relay that can't traverse your customer's firewall is not the cheaper option, whatever its rate card says.
Does a managed TURN server work on ports 80 and 443?
Yes, and it's essential. Restrictive firewalls block UDP and non-standard ports but allow 443, so a managed TURN server that speaks TURNS (TURN over TLS) on port 443 looks like ordinary HTTPS traffic and traverses locked-down corporate networks. Metered ships 80/443 plus TURNS; providers that only offer port 3478 will fail on the exact networks where you most need relay.
Is there a free tier for a managed TURN server?
Yes. Open Relay gives you 20 GB/month of free TURN bandwidth, on ports 80 and 443 with TURNS — no port restrictions. Free tiers are available; move to a plan with an SLA before production. Start with Open Relay's free tier.
The bottom line
A managed TURN server buys you out of the least rewarding part of WebRTC: running relay infrastructure. If you are building a serious product, that is the right trade — the engineering cost of self-hosting grows with your own product, arriving exactly when you are busiest shipping the features people came for.
Choose on regions, ports 80/443 + TURNS, documentation and API, bundled signalling, SLA, support, and data residency. Price is the tiebreaker, not the decision.
When you're ready, Use the free turn server on Open Relay, then move to Metered's managed TURN service when you need fixed IPs, region pinning, and a predictable bill.
About the author: this article has been written by James Bordane an Open Source Enthusiast
Top comments (1)
thank you for reading. I hope you like the article