IPTV panel server requirements: main server, LBs and bandwidth

Getting the IPTV panel server requirements right at the start saves you a migration later. The panel software itself is light. What is heavy is the stream traffic, the disk reads for video on demand and, if you do it, transcoding. This guide explains how to split those roles across servers, how to size each one with rules of thumb you can check against your own numbers, and what to monitor once it runs.

The advice applies to self-hosted panels such as Xtream UI and XUI One and to the load balancers you attach to a hosted panel. Software-specific steps are in the Xtream UI guide and the XUI One install guide; this article is about the hardware and network underneath.

Two roles: main server and load balancer

Almost every panel architecture separates two jobs.

The main server

The main server runs the panel’s web interface, its API (the Xtream Codes API that player apps use), the database, the EPG importer and the scheduler. It knows which customer may watch what, and it tells the apps which load balancer to connect to.

Its load is database queries and small HTTP requests, many of them at once when thousands of apps refresh their channel lists at the same moment. It needs:

• A fast disk for the database (NVMe or SSD; a hard disk is a mistake here).
• Enough RAM to keep the working set of the database in memory. For a small panel this is a few gigabytes; grow it with your customer and EPG volume.
• A modest number of fast CPU cores. Single-thread speed matters more than core count for a database and PHP or Go web stack.
• A reliable, not necessarily huge, network port.

The main server should not serve streams in production. If it does, a busy Saturday evening saturates its port and the login API slows down for everyone, including customers who only wanted to open the app.

Load balancers

Load balancers (also called stream servers or edge servers, depending on the panel) do the heavy lifting: they pull each source stream once and fan it out to every viewer who tuned in. They also serve VOD files and catch-up recordings.

Their load is network throughput first, disk reads second, CPU last (unless they transcode). You add load balancers as concurrent viewers grow; this is how a panel scales horizontally.

CPU: restreaming is cheap, transcoding is not

Be precise about the words.

Restreaming means taking an incoming stream and passing the same compressed video to viewers, repackaged into MPEG-TS or HLS but not re-encoded. In ffmpeg terms this is copy mode. The CPU cost per channel is small: a process that reads bytes and writes bytes. A rule of thumb, not a benchmark: a modern server core handles many restreamed channels before CPU becomes the limit; you run out of bandwidth long before you run out of CPU.

Transcoding means decoding the video and encoding it again, for example to produce a lower bitrate for mobile, to change HEVC to H.264 for old devices, or to burn in a logo. This is expensive. Software encoding of a single 1080p stream can occupy a full core or more, depending on preset and encoder. GPU encoders (NVIDIA NVENC, Intel Quick Sync, AMD) handle several streams per card and are the normal choice when you transcode more than a handful of channels.

Practical consequences:

• If you only restream, buy load balancers for network capacity and do not over-spend on CPU.
• If you transcode, put it on dedicated servers with GPUs or many cores and keep the load balancers as pure distribution. Mixing both on one box makes capacity planning guesswork.
• Count the number of channels you transcode, not the number of viewers. One transcode serves every viewer of that channel.

RAM

RAM needs are moderate on load balancers. Each active stream process uses a small amount of memory for buffers; the operating system uses the rest as a page cache for VOD and catch-up files, which is where RAM helps most. More RAM means more of the popular VOD files served from memory instead of disk.

On the main server, RAM is for the database. Size it so that indexes and the hot part of the tables fit in memory, and watch swap usage; swapping on the database server is the first sign you under-sized it.

Storage: NVMe for VOD and catch-up

Live restreaming barely touches disk. VOD and catch-up are the opposite: hundreds of viewers each reading a different file at a different position. That access pattern is random reads, and hard disks are bad at random reads. The result on an HDD-backed VOD server is buffering even when bandwidth and CPU are idle.

Rules of thumb:

• Put VOD and catch-up recordings on NVMe or at least SATA SSD.
• Size catch-up storage as the number of channels you archive, times the bitrate, times the retention in hours. As an example only: ten channels at 5 Mbps for 72 hours is about 10 × 5 Mbps × 259,200 s ≈ 1.6 TB of recordings before compression or overhead.
• Keep a large hard disk or object storage for cold archive and backups, not for serving.

Bandwidth: the number that sizes everything

Bandwidth decides how many load balancers you need and what they cost. The formula is simple; the inputs are what you must get right.

The formula

Required throughput = peak concurrent viewers × average stream bitrate × headroom factor

Then: number of load balancers = required throughput ÷ usable throughput per load balancer.

A worked example

These figures are examples to show the arithmetic, not recommendations.

• Peak concurrent viewers: 1,000
• Average stream bitrate: 5 Mbps (a typical figure for 1080p H.264; your mix may be lower or higher)
• Headroom factor: 1.25 (25 percent for protocol overhead, bursts and sources that run hotter than their nominal bitrate)

Required throughput = 1,000 × 5 Mbps × 1.25 = 6,250 Mbps, about 6.25 Gbps.

If each load balancer has a 1 Gbps port and you treat about 800 Mbps of it as usable, you need 6,250 ÷ 800 ≈ 8 load balancers. If you can get 10 Gbps ports, a single server could carry the traffic in theory, and you still want at least two for redundancy.

Monthly transfer

Some providers meter traffic per month. Convert throughput to volume: 1 Gbps sustained for one hour is 3,600 seconds × 1 Gbps = 3,600 Gb = 450 GB. The example above at a sustained 6.25 Gbps during a three-hour peak moves roughly 6.25 × 450 × 3 ≈ 8.4 TB in that evening alone. Multiply by your busy hours per month and compare with the quota before you sign.

Ingest counts too: each source channel is pulled at least once per load balancer, and hundreds of channels add up on the inbound side. Lower bitrates reduce cost directly; a well-encoded stream at a lower bitrate halves your port count.

Network and ports

The main server and the load balancers talk to each other constantly: the load balancers check line permissions and report stats, the main server tells them which streams to start. Put that traffic on private networking or an internal VLAN when the provider offers it.

Expose to the internet only what has to be exposed:

• The panel’s customer-facing ports for the API and stream URLs (on Xtream UI the defaults are 25461 for client access and 25500 for the admin interface; XUI One and hosted panels use their own defaults, commonly behind 80/443 with a reverse proxy).
• 80 and 443 if you terminate TLS in front of the panel.
• SSH, ideally from your own IPs only, with key authentication.

Keep closed to the internet:

• The database port on the main server. Only the load balancer IPs may reach it.
• Any internal API between main and load balancers.
• RTMP or other ingest ports, unless you accept pushes from outside, and then only from known IPs.

Use the provider’s firewall plus a host firewall, and put a reverse proxy in front of the admin interface. DDoS protection at the provider level is worth having; streaming services attract attacks.

Where Hetzner, OVH and similar providers fit

Dedicated servers are the common choice for load balancers because they combine unmetered or high-quota bandwidth with decent hardware. Hetzner and OVH are the names you will hear most in Europe; several smaller hosts specialise in high-bandwidth lines. Prices change too often to quote; check these points instead:

• Bandwidth terms. Unmetered 1 Gbps with a fair-use clause is different from a 10 Gbps port with a monthly quota. Read the acceptable-use policy on streaming and sustained traffic.
• Port speed and upgrade path. Can you move to 10 Gbps on the same server later?
• Private networking between your servers in the same location.
• DDoS mitigation included or optional.
• Location relative to your viewers. Latency does not matter much for HLS, but packet loss across continents does. Put load balancers near the audience.
• Hardware for the role. NVMe options for VOD servers, GPU options if you transcode.

Cloud instances with per-gigabyte egress pricing are usually the wrong fit for streaming at scale; the bandwidth bill dominates. They can still be a good home for the main server, where traffic is small and reliability matters.

Monitoring

You cannot size what you do not measure. Before customers arrive, set up:

• Per-server metrics: CPU, RAM, disk usage and disk I/O, network in and out. Prometheus with node_exporter plus Grafana is the usual open-source stack; Netdata or a hosted monitoring service works too.
• Stream health: number of active streams per load balancer, stream restarts, sources offline. Most panels expose this in their admin interface; export it to your dashboards where possible.
• HTTP errors: 5xx responses on the API and stream endpoints are an early warning of an overloaded main server or a dead load balancer.
• Uptime checks from outside your network on the API and on a test stream URL.
• Alerts on thresholds: port utilisation above 70 to 80 percent, disk above 85 percent, swap in use on the main server, a load balancer unreachable.

Review the graphs weekly. When port utilisation at peak creeps toward your limit, order the next load balancer before, not after, the Saturday it is needed.

Sizing summary

Split main server and load balancers from the start. Give the main server fast disk, RAM for the database and no streams. Buy load balancers for bandwidth, with NVMe for VOD and catch-up, and add CPU or GPUs only where you transcode. Size bandwidth as peak viewers × bitrate × headroom, divided by usable port capacity. Keep internal traffic private, expose few ports, and have monitoring with alerts running before launch.

Every number in this guide is a rule of thumb or a labelled example. Replace them with measurements from your own channels and viewers after the first busy weekend. For the software side of the setup, continue with the guides index or, if you are weighing a hosted panel instead of running the stack yourself, the IPTVOS review.