Self-hosted LiveKit for a university, which cloud/bare-metal provider fits this bandwidth-heavy load?

Self Hosting
,
1

Hi everyone, planning a self-hosted LiveKit deployment for live university classes and would love input from anyone running LiveKit at a similar scale.

Our setup:

  • Use case: live classes + on-demand recording (Egress), not AI agents
  • Scale at full rollout: ~60–70 simultaneous classes, ~40 students/class average (~2,400–2,800 concurrent participants at peak)
  • Bandwidth: projected 10–13 Gbps sustained at peak load
  • Region: users are in the West Bank, Palestine — so latency from Europe/Middle East data centers matters more than US ones for us
  • Architecture: 2+ SFU nodes (scaling out), separate Egress/recording nodes, Redis for multi-node coordination, all self-hosted (not LiveKit Cloud)

What we’re deciding between: Hetzner, OVHcloud, DigitalOcean, and InterServer (bare metal, US-only DCs) all offer bundled/unmetered-style bandwidth rather than per-GB billing, which matters a lot at our traffic volume.

Our questions:

  1. Has anyone run production LiveKit SFU nodes on any of these three providers? How was real-world packet loss/jitter under load, not just benchmark numbers?
  2. At ~10+ Gbps sustained, did you hit any surprise bandwidth caps or throttling on “unmetered” plans that weren’t obvious from the pricing page?
  3. For a Europe/Middle East audience specifically, did going with a European provider (vs. US) make a noticeable difference in call quality?

Any real production numbers, war stories, or “avoid this provider for X reason” are hugely appreciated. Happy to share our final setup back with the community once we land on something.

2

@Mohammad_Khdour I run LiveKit on OVH, so I will speak to that one and leave Hetzner, DigitalOcean, and InterServer to others.

The LiveKit spec that filters the list: scaling is bound by CPU and bandwidth, and the docs want 10 Gbps ethernet or faster per node (deployment). So shop on port speed, not the word “unmetered.” At 10-13 Gbps aggregate that means true 10GbE ports, roughly two SFU nodes of headroom for your 2-plus plan. A class runs entirely on one node (distributed), so more nodes spread your 60-70 classes but never split one; keep Egress on its own boxes.

Two OVH-specific things matter more than the pricing page. “Unmetered” on OVH means not billed by volume, not a guaranteed rate: the default public bandwidth is best-effort burst, and constant throughput is a paid guaranteed-bandwidth add-on (OVH bandwidth). So buy guaranteed bandwidth or a 10GbE range; do not trust “unmetered” for a sustained 10 Gbps SFU.

The bigger one: OVH’s always-on Anti-DDoS can read your sustained high-packet-rate RTP as attack-like and mitigate it. The documented fix for high-rate UDP nodes is a support ticket with your node IPs and UDP port ranges so OVH builds a custom mitigation profile, the same process they publish for Solana validators (OVH anti-DDoS for UDP). Also keep RTP under path MTU, since OVH drops fragmented UDP by default. Do both before you load-test, or you will chase phantom packet loss.

Region: OVH has no Middle East DC, so for a West Bank audience the closest low-RTT options are the French sites (Marseille is their Mediterranean edge) or Frankfurt. That also rules InterServer (US-only) out for your users. Confirm bare-metal stock in the specific city before you commit.

3

Thanks a lot for this; the DDoS/UDP point especially would’ve cost us days of confused debugging if we’d hit it blind during load testing.

Two things that would help a lot:

  1. Guaranteed bandwidth add-on: roughly what does it cost on top of the base server, and is it per-server or account-wide?
  2. The Anti-DDoS support ticket: how long did OVH take to turn it around, and do you have to redo it every time you add a new server IP, or is it one-time per range?
4

@Mohammad_Khdour, Guaranteed bandwidth is per server. You add it on each dedicated server in the Control Panel, not once for the account (OVH bandwidth). OVH does not publish the price; it only appears in the order funnel, so the real number is what you see when you configure the box. Whatever it costs, it is the one thing that takes you out of OVH’s fair-usage rule and their stated right to cut a server’s outgoing public bandwidth by up to 50% when it affects other users (OVH bare-metal). For a sustained 10 Gbps SFU, that 50% clause is the risk you are buying out of.

The Anti-DDoS profile is per IP, not per range. The Edge Network Firewall protects one IP at a time, and multiple IPs are configured separately (OVH network firewall); the custom-mitigation ticket also asks you to list each node’s IPv4 and ports. So a new SFU node means adding its IP to the profile, and OVH does not document automatic coverage of a later IP. On timing, OVH publishes no SLA for building the profile itself, only general first-response targets by support tier (8 business hours on Standard down to 15 minutes on Enterprise) (OVH support levels). Time it into your rollout rather than assuming it is instant.