coturn is the most widely used open-source TURN and STUN server for WebRTC, relaying audio, video, and data when direct peer-to-peer connections fail behind restrictive NATs and firewalls. It handles NAT traversal through ICE, supports UDP, TCP, TLS, and DTLS transports, and scales to thousands of concurrent relays on modest hardware. For teams that prefer not to self-host, VideoSDK's managed WebRTC infrastructure includes TURN fallback automatically, so calls connect even on hostile networks. Start with the VideoSDK quickstart to see managed connectivity in action, or read on to master coturn yourself.
Every WebRTC engineer hits the same wall eventually: the demo works perfectly on your laptop, then a user on a corporate network or mobile carrier can't connect at all. Roughly 10 to 20 percent of real-world peer-to-peer connections fail without a media relay, depending on whose network measurements you trust. That failure rate is why TURN servers exist, and why coturn, the open-source TURN and STUN implementation, has become the default answer for teams building real-time communication.
This guide covers what coturn is, how it fits into the WebRTC media path, how to deploy and secure it, and how to scale it for production. Whether you're self-hosting or evaluating managed alternatives, you'll finish with a clear picture of what TURN actually costs in latency, complexity, and operations.
What is coturn and How It Fits Into WebRTC
coturn is defined as a free, open-source implementation of TURN (Traversal Using Relays around NAT) and STUN (Session Traversal Utilities for NAT), the two IETF protocols WebRTC uses to establish connectivity between peers on different networks. coturn works by first helping peers discover their public network address through STUN, and then, when direct connection proves impossible, relaying all media packets through the server itself via TURN.
In a WebRTC session, each participant gathers "candidates": possible network routes for sending media. ICE (Interactive Connectivity Establishment) tests these candidates in pairs, trying direct routes first. STUN just tells a peer its public IP and port, which works for simple home routers. When both peers sit behind symmetric NATs, strict corporate firewalls, or carrier-grade NAT, direct routes fail and ICE falls back to a TURN relay. At that point every audio and video packet flows through your coturn server, which is why its performance and placement matter so much.
The TURN versus STUN distinction is really about cost. STUN is nearly free: a tiny request and response, no ongoing traffic. TURN is expensive: the server becomes a full media relay, consuming bandwidth for every packet of every session that needs it. A typical deployment uses both, with coturn serving STUN for the easy cases and TURN for the hard ones.
Understanding coturn in WebRTC Deployments
Understanding coturn in WebRTC deployments starts with recognizing that TURN sits in the middle of the media path only when it must. In peer-to-peer topologies, both clients allocate relay addresses on the same coturn instance and exchange media through it. In server-topology deployments, a TURN server can sit in front of an SFU (Selective Forwarding Unit) or media server, letting participants behind restrictive networks reach the conference infrastructure.
The diagram below shows where coturn intervenes in a typical WebRTC connection attempt:
Most production teams deploy coturn on a public cloud VM with a public IPv4 address, opening a UDP port range for media relay plus TCP and TLS ports for fallback. Docker has become the dominant deployment method because it packages the server, its configuration, and its port mappings into a reproducible unit.
Core Features Relevant to WebRTC
coturn's feature set covers everything WebRTC connectivity requires. It supports NAT traversal across IPv4 and IPv6, relays media over UDP, TCP, and TLS, and encrypts DTLS for secure media transport. Authentication supports long-term credentials (the standard username-and-password mechanism) and the TURN REST API short-term credential scheme, which most WebRTC backends generate dynamically per session. Bandwidth and allocation controls let operators cap per-user throughput and expire idle allocations, protecting the server from abuse.
Performance Characteristics
A TURN relay adds latency because every packet makes an extra network hop through the server. In practice, a well-placed coturn instance adds single-digit milliseconds within the same region, but cross-region relays can add 50 to 100 milliseconds or more, which is why server placement near your users matters. A single modern CPU core can typically sustain hundreds of concurrent relay allocations, and a modest multi-core VM handles thousands, with bandwidth, not CPU, usually becoming the bottleneck first. Docker adds negligible overhead versus bare metal since coturn is network-bound, though host networking mode avoids container networking overhead on high-traffic deployments.
Setting Up coturn for WebRTC
Setting up coturn for WebRTC follows a consistent path whether you install from a Linux package manager or run the official Docker image. The steps below describe the process in plain language so you understand what each stage accomplishes.
Step 1: Install the Server
Install coturn either through your distribution's package manager on a Linux VM or by pulling the official coturn Docker image. Docker is the recommended path for most teams because it pins a known version and simplifies upgrades. Choose a host with a public IP address, since TURN fundamentally requires the server to be reachable from arbitrary networks.
Step 2: Configure the Basics
The configuration file defines your listening ports, the public IP address the server advertises, your authentication realm, and the credential mechanism. The external IP setting is the one that bites most people: on cloud VMs behind NAT, coturn must be told its public address explicitly, or clients receive relay candidates pointing at an unreachable private address. Configure the UDP relay port range to match what your firewall allows.
Step 3: Start and Verify
Start the service and verify it responds to STUN binding requests from an external network. Then test a full TURN allocation using a browser-based ICE candidate test or your application's own connectivity diagnostics. The deployment flow looks like this:
Common Pitfalls
The most frequent failures are unopened firewall ports (coturn needs its listening ports plus the entire relay port range), incorrect external IP detection on NAT-based cloud instances, and missing TLS certificates when clients require secure TURN. Each produces a distinct symptom: total connection failure, unreachable relay candidates, or successful allocation followed by media blackness.
Choosing the Right Docker Image Tag
Docker image tags for coturn generally split between Alpine-based variants (smaller downloads, faster cold starts) and Debian-based variants (broader runtime compatibility). For latency-sensitive media relay, the base image matters far less than running with host networking so packets don't traverse Docker's internal bridge. Pin a specific version tag rather than latest so upgrades are deliberate, since TURN protocol behavior and defaults have changed across coturn releases.
Configuring Ports for Media Relay
coturn opens a wide UDP port range for relay allocations because each TURN session needs its own relay port pair. The default range spans tens of thousands of ports, which suits large deployments but often collides with cloud provider firewall defaults. Narrow the minimum and maximum port values to a range sized for your expected concurrent relays, roughly two ports per session, and mirror that exact range in your firewall and any Docker port mappings.
Securing coturn in a WebRTC Environment
An open TURN server is an open relay for anyone who finds it, and unauthenticated relays get discovered and abused for traffic laundering within days. Security is not optional.
Start with TLS and DTLS. WebRTC media is always encrypted end-to-end between peers, but enabling DTLS on the relay and TLS on the TCP listener lets clients on networks that block plain UDP still connect securely, and it prevents middleboxes from interfering with TURN signaling itself. You'll need a valid certificate for your TURN domain, which is another reason to run coturn behind a stable hostname rather than a bare IP.
Use short-term credentials generated per session via the TURN REST API mechanism rather than static long-term credentials. Your backend issues a time-limited username and secret to each client when it creates its meeting token, and coturn validates them using a shared secret. This ties relay access to authenticated application users and expires automatically. Set a distinct authentication realm so credential scoping is unambiguous.
Restrict exposure at the network layer. Firewall the listening ports to the IP ranges your users actually come from where feasible, disable unused transports, and reject allocations from unexpected source addresses. Finally, keep structured logs of allocations, source IPs, and bandwidth consumed. When abuse happens, and on public relays it eventually does, those logs are what let you identify and block the offending traffic.
Optimizing coturn for Production WebRTC Apps
Production optimization is about distributing load and seeing problems before users do.
For scale, run multiple coturn instances behind DNS round-robin or a TCP-level load balancer such as HAProxy for the TLS listener. Because each TURN allocation is stateful on one server, load balancing happens at allocation time, not per packet, which makes horizontal scaling straightforward. Place instances in each geographic region where you have users, since relay latency is dominated by distance. For credential management across multiple instances, back coturn with a persistent user database in Redis or PostgreSQL so every instance validates the same credentials without local duplication.
Tune allocation lifetimes and bandwidth caps to your workload. Shorter allocation timers reclaim ports from abandoned sessions faster; per-allocation bandwidth limits prevent a single user from saturating a shared instance. Enable coturn's built-in status and health-check endpoints so your orchestrator can restart unhealthy instances, and export metrics on active allocations, relayed bytes, and authentication failures into your monitoring stack. Alert on allocation counts trending against your capacity, because bandwidth exhaustion on TURN manifests as sudden, widespread media quality degradation.
A practical note from production experience: teams that operate their own TURN fleet routinely discover that operational cost, not license cost, dominates. Monitoring, certificate rotation, and capacity planning across regions add up. That's the honest trade-off to weigh against managed platforms. VideoSDK, for example, handles TURN fallback, network-adaptive streaming, and global infrastructure as part of its video calling SDK, so the relay layer is never something you operate. Its REST APIs also expose session analytics you'd otherwise have to build yourself.
Common Issues and Troubleshooting
Most coturn problems fall into four recognizable patterns.
NAT-related connectivity failures usually show up as ICE completing with only relay candidates, or failing entirely. Diagnose by checking whether the external IP configuration matches the server's actual public address, and whether relay candidates returned to clients are reachable from outside your network.
Port blocking by corporate firewalls appears as clients who can authenticate and allocate over UDP but never receive media, or who can only connect via TURN over TLS on port 443. If your user base includes enterprise networks, offering TLS TURN on 443 is the standard remedy, since almost no corporate firewall blocks it.
Authentication mismatches produce allocation rejections in the server log. The usual causes are a mismatched shared secret between your backend and coturn, an expired time-based credential, or a realm configured differently on client and server. Compare the exact realm string and secret across both sides.
High latency spikes typically mean the relay is geographically distant from one peer, the instance is bandwidth-saturated, or a container network bridge is adding overhead. Check relayed-bytes metrics against your instance's network capacity first, then verify server region placement, and prefer host networking for high-traffic deployments.
When to Use coturn vs Alternative Solutions
coturn shines when you want full control: it's open source, free of per-minute fees, endlessly configurable, and runs anywhere from a single VM to a container fleet. Teams with predictable regional user bases and existing DevOps capability often find it the most economical option.
Managed TURN services and communication platforms win when you need global edge coverage, an SLA, or simply don't want to operate media infrastructure. If your users span continents, a fleet of self-managed relays in every region costs more to run well than most managed options. Platforms like VideoSDK bundle TURN fallback with the full real-time stack, including recording, transcription, and adaptive streaming, which you can explore in the VideoSDK documentation and code samples.
The honest verdict: use coturn when control and cost predictability matter most, and use a managed platform when global reach and operational simplicity matter most.
Definitions Glossary
TURN (Traversal Using Relays around NAT): An IETF protocol that relays WebRTC media through a server when direct peer-to-peer connection fails. coturn is the most widely deployed open-source TURN implementation.
STUN (Session Traversal Utilities for NAT): A lightweight protocol that lets a WebRTC client discover its public IP and port. It handles the easy NAT cases and costs almost nothing to serve.
ICE (Interactive Connectivity Establishment): The WebRTC framework that gathers candidate routes (direct, STUN-assisted, and TURN relay) and tests them in pairs to find a working connection.
Allocation: A TURN session resource that reserves relay ports on the server for one client. Allocations expire after a timeout and consume bandwidth while active.
Long-term and short-term credentials: The two TURN authentication schemes. Long-term uses static usernames and passwords; short-term (TURN REST API) issues time-limited credentials per session, which is the recommended approach for WebRTC.
DTLS: Datagram Transport Layer Security, the encryption layer protecting WebRTC media over UDP, including media relayed through a TURN server.
Key Takeaways
- coturn is the standard open-source TURN/STUN server for WebRTC, relaying media when direct peer connections fail behind restrictive NATs and firewalls, typically affecting 10 to 20 percent of real-world sessions.
- TURN relays add an extra network hop, so server placement near users matters more than raw CPU; bandwidth, not processing power, is usually the first bottleneck.
- Secure coturn with TLS and DTLS, short-term per-session credentials, restricted firewall rules, and allocation logging, because open relays get abused quickly.
- Scale horizontally with multiple regional instances, DNS round-robin or HAProxy, and a shared Redis or PostgreSQL credential store, since TURN allocations are stateful per instance.
- If operating a global TURN fleet costs more than it's worth, managed platforms like VideoSDK include TURN fallback, adaptive streaming, and session analytics as part of the SDK.
Conclusion
coturn remains the backbone of self-hosted WebRTC connectivity in 2026: a proven, free, and flexible TURN and STUN server that solves the NAT traversal problem for the minority of users who can't connect directly. Deploy it with a correct external IP, a properly firewalled relay port range, per-session credentials, and regional instances, and it will serve production traffic reliably. If you'd rather focus on your product than on relay operations, try VideoSDK's managed real-time infrastructure instead, starting from the quickstart guide or the free tier at app.videosdk.live/login. What are you building with WebRTC? Drop a comment, I'd love to hear whether you're self-hosting coturn or going managed.
Free $20 Balance for AI Voice Agents & Video Calls
FAQ