0Pricing
Real-Time Streaming Systems (WebRTC + Live Data) · Lesson

Deploying and Securing Your Own TURN Server

Learn to self-host a TURN server with coturn, configure credentials securely with time-limited tokens, and decide between self-hosting and managed TURN services.

Deploying and Securing Your Own TURN Server is a free Real-Time Streaming Systems (WebRTC + Live Data) lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Real-Time Streaming Systems (WebRTC + Live Data) learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

From Theory to Operation

You understand NAT challenges, STUN, and what TURN does. Now you will actually run a TURN server, secure it, and connect WebRTC to it. The most common open-source choice is coturn.

Why Self-Host TURN

Public STUN is free, but TURN relays media and consumes bandwidth, so it is rarely free. Running your own TURN server gives you control over capacity, cost, and privacy.

Installing coturn

On a Linux server you install coturn from the package manager. It runs as a background service.

sudo apt-get update
sudo apt-get install -y coturn
sudo systemctl enable coturn

Basic Configuration

coturn reads /etc/turnserver.conf. A minimal config sets the realm and listening ports.

listening-port=3478
tls-listening-port=5349
realm=turn.example.com
fingerprint

The Credential Problem

TURN requires authentication or anyone could relay traffic through your server at your expense. Hardcoding a static username and password is risky because clients can leak them.

Time-Limited Credentials

The secure approach is the REST/ephemeral credential mechanism. Your server generates short-lived usernames and passwords derived from a shared secret, so leaked credentials expire quickly.

use-auth-secret
static-auth-secret=your_long_shared_secret

Generating a Credential

Your backend creates a username as an expiry timestamp and signs it with HMAC-SHA1 using the shared secret. The signature becomes the password.

const crypto = require('crypto');
function turnCredential(secret, ttl) {
  const username = String(Math.floor(Date.now() / 1000) + ttl);
  const hmac = crypto.createHmac('sha1', secret);
  hmac.update(username);
  const password = hmac.digest('base64');
  return { username, password };
}

Wiring It Into WebRTC

Pass the TURN URL and ephemeral credentials into the peer connection's ICE server list. WebRTC uses them when direct paths fail.

const pc = new RTCPeerConnection({
  iceServers: [{
    urls: 'turn:turn.example.com:3478',
    username: cred.username,
    credential: cred.password
  }]
});

Use TLS and TCP Fallback

Some restrictive networks block UDP entirely. Offer turns: over TCP on port 443 so media can tunnel through firewalls that only allow HTTPS traffic.

// add a TLS/TCP TURN entry alongside the UDP one
urls: 'turns:turn.example.com:443?transport=tcp'

Self-Host vs Managed

Self-hosting coturn is cheaper at scale but means you handle uptime, bandwidth, and security. Managed TURN providers cost more per GB but remove operational burden. Pick based on your team and traffic.

Operating Responsibly

Monitor bandwidth, rotate the shared secret periodically, restrict relay to authenticated users, and place the server geographically near your users to minimize latency. A well-run TURN server is the safety net that makes calls connect everywhere.

Quick Check

Test your understanding of TURN deployment.

Recap

You learned to deploy and secure TURN:

  • Install and configure coturn with a realm and ports
  • Use use-auth-secret with HMAC-based ephemeral credentials
  • Wire credentials into the ICE server list
  • Offer TLS/TCP on 443 for restrictive networks
  • Weigh self-hosting against managed services

A secure TURN server ensures calls connect even behind tough NATs.

Frequently asked questions

Is the “Deploying and Securing Your Own TURN Server” lesson free?

Yes — the full text of “Deploying and Securing Your Own TURN Server” is free to read here on the web, and the Real-Time Streaming Systems (WebRTC + Live Data) course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Real-Time Streaming Systems (WebRTC + Live Data) course, upgrade to CoddyKit PRO.

What will I learn in “Deploying and Securing Your Own TURN Server”?

Learn to self-host a TURN server with coturn, configure credentials securely with time-limited tokens, and decide between self-hosting and managed TURN services. You practise Real-Time Streaming Systems (WebRTC + Live Data) with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Real-Time Streaming Systems (WebRTC + Live Data)?

No prior experience is required. Real-Time Streaming Systems (WebRTC + Live Data) on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Deploying and Securing Your Own TURN Server” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Real-Time Streaming Systems (WebRTC + Live Data) lesson?

Yes. Every Real-Time Streaming Systems (WebRTC + Live Data) lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. NAT and Firewall Challenges
  2. STUN Server Functionality Explained
  3. TURN Server for Relayed Connections
  4. Deploying and Securing Your Own TURN Server
← Back to Real-Time Streaming Systems (WebRTC + Live Data)