How to Install an IPTV Panel on Ubuntu Server (2027)

Watch the Installation Video

The short version first. This walkthrough shows the whole installation from a bare Ubuntu server to a panel you can log into, with no commands typed on the server itself.

Everything below expands on what the video shows: the decisions you make before you start, and the checks you run afterwards.

Server Requirements Before You Start

Get this wrong and everything afterwards is harder than it needs to be. The panel installs happily on modest hardware, but a main server short on RAM starts hurting the moment real traffic arrives, and it hurts in ways that look like software faults rather than sizing mistakes.

Note what that last row means for your budget. Because one license covers unlimited balancers, the right architecture is a single well-specified main server handling the panel and database, with delivery pushed out to as many cheap balancers as your bandwidth demands. You are not paying per node. If you are still sizing hardware, the IPTV server requirements guide goes deeper on CPU, disk and bandwidth planning.

Which Ubuntu Version to Choose

Supported releases are Ubuntu 20.04, 22.04, 24.04 and 26.04 on x86 architecture. The question is not really compatibility, it is how long you want to go before rebuilding.

• Ubuntu 24.04 is the recommended choice for a new build, and it is what the official install instructions specify. Long remaining support window, modern kernel, good hardware support on current server generations.
• Ubuntu 26.04 is supported if your provider images it and you want the longest possible runway.
• Ubuntu 22.04 and 20.04 both work fine and are widely offered by hosts, but you are starting a new server with less time on the clock.
• Ubuntu 18.04 and older are legacy territory. They are only relevant to setups that cannot run FFmpeg v7 and have to stay on the older v5 build, which is not where you want a new install to be.

What matters as much as the version number is that the image is clean. A fresh operating system is the recommended install path for security reasons. Installing on top of an existing panel, or alongside a MySQL you set up yourself, causes failures that are far harder to diagnose than a five-minute reimage.

Installing the Panel, Step by Step

This is what the video shows. The install is driven by the Master CMS Panel, which connects to your server over SSH and does the work remotely. You never open a package manager.

1 Provision the Ubuntu server

Order a dedicated server with a clean Ubuntu image, ideally 24.04. Note three things: the IP address, the SSH port, and the root password. Nothing needs to be pre-installed, meaning no MySQL, no nginx, no PHP and no dependencies of any kind.

2 Log in to the Master CMS Panel

Sign in with your xm: account, which uses the format xm:********. The CMS is the control plane for every server you run: main servers, load balancers, and Sub-Main edge nodes if you use the Multi-Main addon. This is the single place you will manage infrastructure from now on.

3 Add your server for installation

Add a new server and enter its SSH details: IP address, SSH port and root password. Choose the role, either Main Server for the panel itself or Load Balancer for a delivery node. Start the install and leave it alone.

4 Set your panel port, if you want a custom one

The admin panel answers on port 7709 by default. If you want something else, the CMS dashboard has an Edit Port button. Read the next section first, because port confusion is where most first-time installs appear to go wrong when nothing is actually wrong.

5 Log in as admin

Open http://YOUR_SERVER_IP:7709, or your custom port, and log in with the admin account. You now have a clean, working panel: create your bouquets, add streams, set up resellers and configure authentication.

The Two Ports: 7709 and 8080

If you take one thing from this guide, take this. The panel runs two separate ports on two different web servers, and confusing them produces the single most common "my install failed" support ticket, from installs that succeeded perfectly.

Because the admin panel and streaming run on different services, they must use different ports. The defaults already keep them apart, so do not make them collide.

The failure mode looks like this: the install finishes, you open the server IP on port 8080, you see something that is clearly not a login page, and you conclude the installation broke. It did not. You are knocking on the wrong door. Browse to http://YOUR_SERVER_IP:7709 instead.

Changing the admin panel port

1. Log in to the Master CMS cPanel with your xm: account.
2. On the dashboard, click Edit Port.
3. Set the new port, and make sure it is not already used by another service.
4. Click Save. Changes take roughly two minutes to apply.

Installing Without Reinstalling the OS

The recommended path is always a fresh Ubuntu install. Only take this route if there is a genuine reason you cannot reinstall the server, such as hardware you do not control or an IP you cannot move.

1. Back up your MySQL data. Create complete database backups and download them to your local computer. Do not proceed without verified backups.
2. Remove the existing MySQL server completely. Run these in sequence:
   sudo service mysql stop sudo apt-get --force-yes remove mysql-server mysql-client sudo apt-get --force-yes purge mysql-server mysql-client sudo apt-get --force-yes remove mysql-common -y sudo apt-get --force-yes purge mysql-common -y sudo apt-get --force-yes autoremove --purge -y sudo apt-get autoclean sudo rm -rf /etc/mysql sudo rm -rf /var/lib/mysql sudo rm -rf /var/log/mysql
3. Install the panel. Enter the server SSH details in the Master CMS Panel, start the installation and wait for it to finish.

Post-Install Checklist

A panel that loads is not the same as a panel that is ready. Work through these before you put a single subscriber on it.

• Change the admin password. First action, every time, no exceptions.
• Point DNS. Create an A record for your panel hostname so you and your resellers are not typing raw IP addresses, and so you can move servers later without reissuing every subscriber's configuration.
• Check the three DNS fields on the main server. Under Servers, edit the Main Server and review Users CDN, Private Users CDN and Proxy IP or DNS [All]. All three should point at the main server IP. Getting these wrong is the classic cause of a playlist that loads while nothing plays.
• Set up SSL. Streaming SSL runs on 8443 and the panel can install and auto-renew a free certificate with one click. The admin port is a separate job on HAProxy, either through Cloudflare or a one-time manual certificate setup.
• Enable access codes. See the security section below. This is the single highest-value hardening step the panel offers.
• Enable Server Guard on the main server and each load balancer.
• Connect cloud backup. xDrive is a free addon included with your license, and local backups on a dead server are worth nothing.
• Lock down the firewall and SSH. Open only the admin port, streaming ports and SSH. Use key-based authentication and a non-default SSH port.
• Verify the streaming port answers from outside your own network, not just from the server itself.

Locking the Panel Down

Competitors attack panels. That is simply part of operating in this market, and the panel ships with specific tools for it. Configure them now, not after the first flood.

Access codes, which stop brute force at the door

By default your login page sits at a predictable address and accepts login attempts from anyone. Access codes replace that with a secret entry link.

1. Go to System Security > Access Code in the admin panel.
2. Enable both options: Enable access code feature for panel logins and Disable panel login page without access code link.
3. Click Create New Code, generate the code, set Type to Admin Panel, select the admin groups, and optionally restrict by IP. Click Add.
4. Repeat for the reseller panel. Creating several codes for different reseller types helps you identify where an attack is coming from.
5. Distribute the resulting links, which look like yourdomain.tld:port/ac_XXXXXXX, to authorized users only.

Direct logins to yourdomain.tld:port are then refused, and only valid access code links grant access. The documented effect is a reduction in brute-force attempts of over 90 percent.

Server Guard, for when the flood arrives anyway

Go to Manage Server, edit the main server or a load balancer, open the Server Guard tab, and enable Server Guard along with under-attack mode. Use these thresholds as your trigger: sustained traffic above roughly 500 requests per second on the main server, or 200 per second on a load balancer, indicates an attack rather than organic demand.

Cloud backup, because local backups die with the server

The panel writes automatic backups to /home/xtreamaster/backups/, which is useless if the machine itself fails. xDrive is an encrypted cloud backup addon included free with your license: register at cloud.xtream-masters.com, create an API key under Profile, Account Settings, Developers, then in your admin panel open your Profile Icon, choose xDrive Backup Storage, paste the key and save. Dropbox is supported as an alternative or as a second destination.

Load Balancers and Multi-Main

Load balancers install exactly the same way as the main server: add the server in the CMS with its SSH details, choose the Load Balancer role, and let the CMS install it. Since the Pro license covers unlimited balancers, add them as bandwidth demands rather than rationing them.

Two operational details worth knowing up front, because they come back the moment you touch a balancer again:

• Each balancer needs its SSH password set on its entry in the Servers page.
• To bring one online or recover it, use Servers page, LB Option, then Restart Service or Re-install Balancer. Allow up to two minutes, then refresh.

For how traffic is distributed and how many balancers a given subscriber count needs, see the load balancer setup guide.

Multi-Main, for panels under real load

Load balancers deliver streams, but playlist, EPG and portal generation still lands on the main server, and that is what falls over at peak time or under a Layer-7 flood. The Multi-Main addon moves that work onto dedicated Sub-Main edge nodes, leaving the main server with two light jobs: managing the database and redirecting stream requests to the load balancers.

• Roughly 50,000 requests per second per node, with no CPU or RAM spike.
• Each node needs its own dedicated server: fresh Ubuntu 24.04 or newer, 32 GB RAM minimum.
• An automatic copy of the database is kept on the Sub-Main, holding the latest 7 days at /home/xtreamaster/backups.
• No DNS or proxy changes are needed. Traffic routes with one click after install.
• €199 one-time, after which unlimited nodes can be added. One node is usually enough.

Find it under Menu, Manage Servers, Multi-Main Server, then use Install Sub Main to deploy a node. Be clear on what it is not: a Sub-Main is not a standalone panel, so if the main server goes down the Sub-Main will not run the service alone. It protects the main server from load, it does not replace it.

Why This Is Not a Bash-Script Install

If your reference point is installing XtreamUI or XUI.ONE, this process will feel unfamiliar, so it is worth naming the difference.

The classic install is: SSH into the box, pull a bash script from somewhere, run it as root, answer prompts, and hope the dependency chain resolves against whatever Ubuntu release you happen to be on. When it fails, because a repository moved or a Python version shifted or a package got renamed, you are debugging someone else's shell script on a production server at midnight. That is the experience the XtreamUI install guide and the XUI.ONE install guide exist to walk people through.

Here the CMS holds the installation logic centrally and pushes a tested stack over SSH. The consequences are practical rather than philosophical: installs are repeatable across Ubuntu releases, you are not running unaudited root-level scripts of unknown provenance, and rebuilding a server is a CMS action rather than an archaeology project.

Troubleshooting a Failed Install

"The install will not start, the CMS cannot reach the server"

An SSH problem, essentially always. Check the IP, check the SSH port, since providers frequently ship non-standard ports, check the root password, and check that the provider's firewall or your own ufw rules are not blocking SSH from outside. Confirm you can SSH in manually from your own machine first. If you cannot, the CMS cannot either.

"The install finished but I cannot reach the panel"

Try http://YOUR_SERVER_IP:PANEL_PORT directly, remembering the default is 7709 and not the streaming port. If it still does not answer, you likely have a port conflict: either disable the other service using that port, or change the panel port from the Master CMS. Also confirm the port is open at both the server firewall and your provider's edge firewall, since some hosts filter non-standard ports by default and never mention it.

"The login page shows a Login Key field"

The server IP configured in the Master CMS does not match the server's primary outgoing IP, and the panel treats that mismatch as a security signal. Find the real outgoing IP:

Then in the Master CMS click Edit on your main server, enter that primary IP, making sure not to use a secondary or additional IP, and save. Wait one to two minutes and the field disappears.

"The install failed partway through"

Almost always a dirty image. Something was already on the server: a previous panel, a manually installed MySQL, or a control-panel stack from the provider's template. Reimage to clean Ubuntu and run the install again, or follow the existing-OS procedure properly. Do not remove the conflicting software halfway and retry on top, because leftovers cause failures that are much harder to diagnose than a fresh start.

"The service is down after installing"

Work through it in this order. Check for a full disk with df -h and clear space if any mount is at 100 percent. Restart the database with service mysql restart. Then run the service scripts and read the error, which usually names the problem directly:

In Manage Servers, re-enter the SSH password on the server entry and do a full reload. Rebooting the server is the last resort, not the first move.

"Everything installed but performance is poor from day one"

Check the RAM against the 32 GB minimum, and confirm you are on dedicated hardware rather than a contended VPS. Poor performance on an otherwise idle new panel is a sizing symptom, not a software one.

Next Step: Migrating Your Existing Data

If this is a brand-new service, you are finished, so go and build your bouquets. But most people installing a panel on a new server are moving, whether off an overloaded box, off a cracked build, off a host that keeps null-routing them, or off a panel that stopped getting updates.

In that case the install is only half the job. The other half is getting your users, lines, bouquets, streams and VODs onto this new server without your subscribers noticing, and that has its own video and its own guide.