LiveKit & WebRTC schalen: Live videoplatforms op een dedicated server

Het bouwen van een WebRTC-prototype is eenvoudig. Je schrijft een paar regels JavaScript, verbindt twee browsers op je lokale netwerk en de videostream werkt vlekkeloos.

Maar zodra je dat prototype naar een productieomgeving brengt om een krachtig webcam platform dedicated server of een applicatie voor live creators aan te sturen, verandert de situatie volledig. Het moment dat je schaalt naar gelijktijdige, bidirectionele 720p HD-streams, kunnen infrastructuurbeperkingen je gebruikerservaring volledig verpesten. Bij het routeren van realtime mediatrajecten zijn netwerkjitter, pakketverlies (packet loss) en een rigide contentbeleid je grootste vijanden.

Om een productierijp WebRTC server framework zoals LiveKit te draaien, heb je een nauwkeurige blauwdruk voor je infrastructuur nodig. Deze moet geoptimaliseerd zijn voor nul pakketverlies, een stabiele UDP-doorvoer en een slimme multi-regio netwerktopologie.

Netwerkjitter en pakketverlies maken een live videoplatform direct onbruikbaar. Test onze snelheid en begin met het bouwen van je live video servers.

SPEEDTEST

WebRTC media server eisen

Een moderne WebRTC SFU (Selective Forwarding Unit) zoals LiveKit codeert videostreams niet opnieuw. Hierdoor zijn dure, onderhoudsgevoelige GPU's overbodig. In plaats daarvan functioneert de server als een ultrasnelle netwerkpakket-router. Dit betekent dat de primaire knelpunten liggen bij de pure CPU-rekenkracht, systeem-interrupts en intensieve cryptoprocessen (SRTP-encryptie/decryptie) voor elke gelijktijdige stream.

Om een stabiele LiveKit dedicated server te draaien in een LiveKit hosting productieomgeving, moet je hardwareconfiguratie je mediaschakelknooppunten (media nodes) strikt scheiden van je centrale applicatielogica.

1. De LiveKit WebRTC Media Node

Elke actieve gebruiker in een 1-op-1 videosessie vertegenwoordigt meerdere inkomende en uitgaande mediatrajecten. Bij een doelbelasting van 50 tot 60 parallelle 1-op-1 sessies (tot wel 120 gelijktijdige deelnemers), moet de server miljoenen UDP-pakketten per seconde verwerken met microseconden-precisie.

CPU: AMD EPYC-processors met minimaal 16 fysieke cores (24+ cores sterk aanbevolen). De superieure architectuur van AMD EPYC verwerkt grote hoeveelheden cryptografische netwerkstromen zonder hypervisor-vertraging of vertragingen in de CPU-planning.
RAM & Opslag: 64GB tot 128GB snel RAM is ideaal. Omdat media nodes puur verkeer doorgeven en geen data opslaan, is een compacte, enterprise-grade 250GB NVMe SSD voldoende.
OS: Ubuntu 24.04 LTS, geoptimaliseerd voor moderne netwerkstacking op kernelniveau.

2. De Backend- & Applicatieserver

Je media nodes moeten niet worden belast met persistente databases of het beheer van gebruikerssessies. Een aparte, dedicated machine moet zaken afhandelen zoals token-generatie, API-endpoints, gebruikersauthenticatie, facturatie-engines, Redis en databasestatuses.

CPU: Een dedicated AMD EPYC (16 tot 24+ cores) zorgt ervoor dat je Node.js API's en realtime databasequery's de rekenkracht van het platform nooit leegtrekken tijdens piekuren.
RAM & Opslag: Minimaal 128GB RAM gecombineerd met een grotere 960GB+ enterprise NVMe SSD om constante I/O-acties te beheren zonder bottlenecks te veroorzaken.

Netwerkoptimalisatie

Hardwarekracht is waardeloos als de netwerpijplijn geen line-rate UDP-prestaties kan leveren. Wanneer je LiveKit op bare metal implementeert, moet je netwerkarchitectuur expliciet geconfigureerd zijn om pakketbuffering en routeringscongestie te voorkomen.

Poort- en Protocolconfiguratie

Een productierijpe WebRTC-omgeving vereist een specifieke matrix van poorten die direct op het bare-metal firewallniveau zijn geopend en geoptimaliseerd:

Poort / Protocol	Richting / Type	Doelservice en verkeersprofiel
TCP 443	Inkomend	HTTPS / TURN TLS (Beveiligde WebSocket-verbinding)
TCP 7880	Inkomend	LiveKit API (Signaling & Sessie Setup)
TCP 7881	Inkomend	WebRTC ICE TCP Fallback (Firewall omzeilen)
UDP 3478	Inkomend/Uitgaand	STUN / TURN-server (NAT-gat-ponsen)
UDP 50000-60000	Inkomend / uitgaand	WebRTC-mediaverkeer (grote audio-/videostreams)

Het Voordeel van een 20 Gbps Burst-poort

Voor een platform dat 50 parallelle 1-op-1 HD-sessies op 720p draait, ligt de uitgaande bandbreedte rond de 500 Mbps, met een gecalculeerde piekruimte van 800 Mbps (wat neerkomt op zo'n 60 tot 100 TB aan data per maand).

Hoewel een standaard 1 Gbps-poort dit volume technisch gezien dekt, nodigt het draaien van een realtime communicatieplatform nabij de fysieke limieten van een netwerkkaart (NIC) uit tot micro-congestie. Door te kiezen voor een dedicated, niet-gedeelde 20 Gbps-poort heeft je server massale burst-ruimte. Dit voorkomt dat pakketten in de wachtrij (queuing) komen te staan op NIC-niveau, waardoor de latentie volledig vlak blijft—zelfs wanneer er tientallen nieuwe videokamers tegelijkertijd openen.

Jitter en Pakketverlies Elimineren

Realtime video vereist een wereldwijde netwerkcapaciteit van 18+ Tbps gecombineerd met intelligente routering (zoals Noction-optimalisatie). Door gebruik te maken van premium Tier-1 transitproviders (zoals Arelion, Cogent en NTT) en directe verbindingen met grote internetknooppunten (zoals AMS-IX), vermijdt je UDP-verkeer het overbelaste openbare internet. Deze architectuur garandeert nagenoeg nul pakketverlies en een ultra-lage jitter, waardoor streams perfect synchroon lopen zonder haperingen tijdens piekuren.

Ontwerpen van een wereldwijde topologie

Als je platform een wereldwijd bereik heeft—bijvoorbeeld gebruikers in Europa die verbinding maken met creators of deelnemers in Latijns-Amerika (zoals Brazilië, Colombia, Argentinië en Mexico)—dan zal één centrale serverlocatie tekortschieten. De fysieke beperkingen van trans-oceanische routering introduceren vertraging (latency) die het "realtime" gevoel van een 1-on-1 gesprek verstoort.

De ideale architectuur rust op een intelligente, geografisch verspreide infrastructuurtopologie:

De Centrale Hub (Europa/Nederland): Host je gecentraliseerde backend, API en facturatie-architectuur in premium Tier-III datacenters in Amsterdam of Rotterdam. Nederland biedt een van de dichtste netwerkconnectiviteiten ter wereld, waardoor het de perfecte basis is voor je kerngegevens.
De Edge Media Nodes (VS/LATAM Gateways): Start onafhankelijke LiveKit edge nodes op in strategische geografische knooppunten zoals New York of Miami. Deze steden beschikken over directe, hoogwaardige onderzeese glasvezelroutes die rechtstreeks naar Zuid-Amerika lopen.

Voordat een videokamer wordt geopend, controleert je backend de latentie tussen beide deelnemers en selecteert dynamisch de dichtstbijzijnde regionale node. Omdat individuele LiveKit media nodes onderling niet in realtime hoeven te communiceren, kan een gebruiker in Bogotá of São Paulo rechtstreeks verbinding maken met een edge node in New York of Miami. Zo blijft de verbinding ultra-laag in latentie, terwijl je Europese backend de sessie-autorisatie en billing tokens op de achtergrond afhandelt via een afgeschermd, privat intern VLAN-netwerk.

Contentbeleid en compliance

Naast de technische specificaties hangt de levensduur van je platform af van het bedrijfsbeleid van je hoster. Veel bedrijven die realtime videonetwerken, creatorplatforms of legale, op leeftijd geverifieerde adult-vriendelijke applicaties bouwen, worden plotseling geconfronteerd met contractbeëindigingen door beperkende, reguliere publieke cloudproviders.

Wanneer je een infrastructuurpartner kiest voor een webcam platform dedicated server, moet je technische roadmap aansluiten bij de Acceptable Use Policy (AUP) van je provider. Enterprise videoplatforms moeten zoeken naar infrastructuurpartners die onder duidelijke, stabiele Europese wetgeving vallen (zoals GDPR-compliance) en schriftelijk bevestigen dat legale, volledig conforme, op leeftijd geverifieerde creator-content expliciet is toegestaan op hun netwerk. Dit beschermt je onderneming tegen willekeurige de-platforming en waarborgt de stabiliteit van je business.

De productie checklist

Wanneer je je WebRTC SFU server hostingomgeving verplaatst van ontwikkeling naar productie, zorg er dan voor dat je infrastructuurpartner de volgende vakjes afvinkt:

Dedicated Hardware: AMD EPYC-processors met exclusieve core-toegang om hypervisor-vertraging te elimineren.
Netwerkruimte (Headroom): Dedicated poorten (tot 20 Gbps) om zware UDP-verkeerspieken op te vangen.
Routeringsoptimalisatie: Multi-homed Tier-1 transitstromen om jitter dicht bij nul te houden.
Geografische Voetafdruk: Datacenters gepositioneerd op cruciale internetknooppunten (bijv. Nederland en de Amerikaanse oostkust) voor intercontinentale routering.
Beleidsafstemming: Een transparante, schriftelijke AUP die legale, creator-gedreven entertainmentplatforms verwelkomt.

NovoServe is gespecialiseerd in high-bandwidth, latency-kritische bare metal hosting, specifiek ontwikkeld voor streaming, WebRTC en realtime communicatieplatforms. Met een wereldwijde netwerkcapaciteit van 18+ Tbps, premium Noction-geoptimaliseerde routering en op maat gemaakte AMD EPYC-configuraties in Nederland en de VS, bouwen wij het fundament dat jouw streams live houdt. Neem vandaag nog contact op met ons engineeringteam om een aangepaste LiveKit-testomgeving op te zetten.

Praat met ons. Wij helpen je bij het ontwerpen van een krachtige, op maat gemaakte bare-metal server die exact is afgestemd op jouw WebRTC- of LiveKit-implementatie.

CONTACT

Veelgestelde vragen

Wat is een WebRTC server?

Een WebRTC server is een infrastructuurknooppunt dat verantwoordelijk is voor het tot stand brengen van realtime audio-, video- en datacommunicatie direct tussen webbrowsers en mobiele applicaties. Hoewel standaard WebRTC peer-to-peer (P2P) kan werken bij eenvoudige videogesprekken tussen twee personen, is in productieomgevingen een gecentraliseerde server nodig om twee cruciale taken uit te voeren:

Signaling en NAT-traversal: Het helpen van apparaten om elkaar te vinden achter firewalls en routers met behulp van STUN/TURN-protocollen.

Media-routering: In plaats van het apparaat van een gebruiker te dwingen zijn videostream herhaaldelijk naar elke afzonderlijke kijker te uploaden (wat de uploadbandbreedte volledig platlegt), ontvangt een WebRTC mediaserver de stream één keer en stuurt deze op een slimme manier door naar alle andere deelnemers.

Wat is een LiveKit server?

Een LiveKit server is een modern, krachtig en open-source WebRTC-ecosysteem dat is ontworpen om realtime audio- en video-ervaringen te bouwen en te schalen. LiveKit is geschreven in Go en fungecht als een uiterst efficiënte Selective Forwarding Unit (SFU). Het stelt ontwikkelaars in staat om videokamers voor meerdere gebruikers, live streaming-applicaties en ruimtelijke audio-omgevingen te creëren. In tegenstelling tot oudere WebRTC-frameworks is LiveKit vanaf de basis ontworpen om cloud-native te zijn. Dit betekent dat het kan worden gedistribueerd over meerdere regionale edge nodes, terwijl het centrale beheer van de kamerstatus behouden blijft.

Wat zijn de hardware-eisen voor een WebRTC server?

Omdat WebRTC mediaservers enorme hoeveelheden realtime cryptografische bewerkingen (SRTP-pakketversleuteling en -ontsleuteling) en intensieve netwerkpakketschakelingen verwerken, hebben ze specifieke hardwareconfiguraties nodig:

CPU: Processors met een hoog aantal cores, zoals AMD EPYC (16 tot 24+ fysieke cores), hebben de voorkeur boven een hoge pure kloksnelheid. De Linux-kernel heeft namelijk dedicated cores nodig om netwerk-interrupts met hoge frequentie (SoftIRQ's) zonder vertraging te verwerken.

Geheugen: 64GB tot 128GB snel DDR5 RAM om duizenden gelijktijdige in-memory mediatrajecten soepel te stroomlijnen.

Opslag: Compacte maar snelle NVMe SSD's (250GB+). Mediaservers routeren verkeer in realtime en slaan videodata niet lokaal op. Hierdoor is de pure opslagcapaciteit minder kritisch dan de I/O-snelheid.

Hosting WebRTC op VPS vs dedicated servers?

Traditionele cloud Virtual Private Servers (VPS) maken gebruik van gedeelde fysieke bronnen die worden beheerd door een hypervisor. Deze architectuur is gebouwd voor TCP-verkeer (zoals reguliere websites), waarbij een paar milliseconden vertraging geen impact heeft. WebRTC leunt zwaar op UDP-verkeer, dat uiterst gevoelig is voor latentie, pakketverlies en jitter. Op een gedeelde VPS kunnen "noisy neighbors" (buur-VM's) die zware databasetaken op dezelfde fysieke host uitvoeren, zorgen voor micro-pieken in de CPU-beschikbaarheid. Dit vertaalt zich direct in haperende videobeelden, robotachtige audio of verbroken verbindingen binnen je WebRTC-streams. Dedicated bare metal elimineert dit risico volledig omdat je 100% exclusieve toegang krijgt tot de fysieke hardware en de netwerkkaart (NIC).

Welke invloed heeft netwerkroutering op WebRTC-streams tussen verschillende regio's?

Voor realtime video moet de end-to-end latentie onder de 200ms blijven om een natuurlijk gesprek mogelijk te maken. Als jouw kerninfrastructuur zich in Europa bevindt en een gebruiker zit in Colombia of Brazilië, dan zal het routeren van UDP-verkeer via standaard openbare internetpaden leiden tot aanzienlijk pakketverlies en hoge jitter. Om dit op te lossen, moet je infrastructuurprovider gebruikmaken van multi-homed, premium Tier-1 netwerktransit (zoals Arelion, NTT en Cogent) in combinatie met slimme routeringssoftware. Bovendien zorgt het inzetten van regionale edge nodes in grote transit-gateways—zoals New York of Miami—ervoor dat Zuid-Amerikaans verkeer direct op hoogwaardige onderzeese glasvezelroutes springt, waardoor de intercontinentale latentie wordt geminimaliseerd tot het optimale niveau.