LiveChat 
Support 
Running Ant Media Server on the Same Server as Plesk: Ports, Conflicts, and Best Practices
Running a real-time streaming engine and a hosting control panel on the same machine sounds efficient, and it can be, but only if you understand where the two collide. Ant Media Server is a Java-based streaming platform that delivers WebRTC and RTMP streams with sub-second latency, while Plesk is a full web hosting control panel that manages domains, mail, databases, and TLS. Both want to bind to network ports, both expect firewall openings, and streaming in particular is hungry for CPU and memory. Put them on the same server without planning and you will hit port collisions, blocked handshakes, or a control panel that crawls under streaming load.
This guide walks through exactly what to watch for when you place Ant Media Server on the same server as a Plesk control panel: the port map, firewall rules, resource contention, and reverse proxy strategy, plus why a dedicated or VPS environment is the right home for this combination.
Key Takeaways
• Plesk defaults to ports 8443 (panel) and 8880 (panel over HTTP), while Ant Media Server defaults to 5080 (HTTP) and 5443 (HTTPS/WebRTC signaling) — no direct collision, but both compete for 443 if you add a reverse proxy.
• WebRTC needs a wide UDP port range open for media; this is the most commonly missed firewall rule.
• Streaming is CPU and RAM heavy, so resource contention, not port conflict, is the bigger long-term risk on a shared box.
• Shared hosting cannot run Ant Media Server at all; you need root access on a VPS or dedicated server.
• Plesk and cPanel differ in firewall tooling, but the port-planning logic is identical.
Do Ant Media Server and Plesk actually conflict on ports?
By default, no, the two products were designed with different port ranges, but the picture changes the moment you put a public-facing web server in front of either.
Plesk runs its administration panel on 8443 (HTTPS) and 8880 (HTTP), and it manages the standard web ports 80 and 443 through its bundled web server (nginx in front of Apache on most Linux installs). Ant Media Server listens on 5080 for HTTP and 5443 for HTTPS, where the WebRTC signaling websocket also lives. Out of the box these never overlap.
The friction appears in three places. First, both stacks consider 443 their natural home for clean public URLs, so something has to arbitrate. Second, WebRTC media does not travel over 5443 at all, it uses a large UDP port range that must be explicitly opened. Third, if Ant Media tries to bind 80 or 443 for a Let’s Encrypt challenge while Plesk already owns those ports, the bind fails.
The core port map you need
| Service | Port | Protocol | Purpose | Conflict risk |
|---|---|---|---|---|
| Plesk panel (HTTPS) | 8443 | TCP | Control panel UI | Low — unique to Plesk |
| Plesk panel (HTTP) | 8880 | TCP | Panel redirect/HTTP | Low |
| Plesk websites | 80 / 443 | TCP | Hosted sites + Let’s Encrypt | High if Ant Media also wants 443 |
| Ant Media (HTTP) | 5080 | TCP | Dashboard + REST API | Low |
| Ant Media (HTTPS) | 5443 | TCP | Secure dashboard + WebRTC signaling | Low |
| WebRTC media | ~50000–60000 | UDP | Actual audio/video packets | High — often forgotten |
| RTMP ingest | 1935 | TCP | OBS / encoder publishing | Medium |
| TURN/STUN (if used) | 3478 | TCP/UDP | NAT traversal | Medium |
The two rows in bold are where most failed installs originate. A panel and a streaming server can coexist all day on distinct admin ports; what breaks is the UDP media range silently dropped by the firewall and the 443 tug-of-war.
How do you handle the firewall rules with Plesk in the mix?
Plesk ships its own Firewall extension, and on most Linux distributions it sits on top of `firewalld` or `iptables`. The trap is that Plesk’s firewall rules and any rules you add manually for Ant Media must agree, or one will silently override the other.
Open these for Ant Media Server in addition to whatever Plesk already manages:
- TCP 5080 and 5443 for the dashboard and signaling.
- TCP 1935 if you ingest RTMP from encoders like OBS.
- The full UDP media range (commonly 50000–60000) for WebRTC playback and publishing.
- TCP/UDP 3478 if you run a co-located TURN server for clients behind strict NAT.
Add these through the Plesk Firewall extension rather than raw `iptables` where possible, so Plesk does not flush your custom rules on its next ruleset rebuild. If you must use the command line, confirm Plesk’s firewall service is reloaded, not regenerated, after your changes.
The single most common “Ant Media works locally but viewers see a black player” support case on a Plesk box is not a signaling failure, it is the UDP media range being closed while TCP signaling on 5443 is open. The browser completes the handshake, the player connects, and then no audio or video packets ever arrive because the firewall drops the UDP flow. Always test with an external client on a different network, never just from the LAN, because LAN tests can mask a missing UDP rule entirely.
Will streaming starve Plesk of resources?
This is the question that matters more than ports. Ant Media Server transcoding is CPU-intensive, and holding many concurrent WebRTC sessions consumes significant RAM and network throughput. Plesk itself is comparatively light, but the websites, databases, and mail it hosts are not, and they will fight the streaming engine for the same cores and memory.
Consider this compatibility and capacity checklist before committing both workloads to one server:
| Consideration | Why it matters | What to verify |
|---|---|---|
| Root / SSH access | Ant Media installs as a system service via Java | Confirm full root, not jailed shell |
| CPU headroom | Transcoding and WebRTC scale with cores | Reserve cores for Plesk-hosted sites |
| RAM | JVM heap + concurrent sessions | Size JVM so Plesk + MySQL still breathe |
| Java runtime | Ant Media needs a supported JDK | Avoid conflicts with Plesk’s own Java |
| 443 arbitration | Only one process can bind 443 | Decide reverse proxy strategy first |
| UDP range open | WebRTC media transport | Test from an external network |
| Dedicated resources | Streaming spikes are bursty | Prefer VPS/dedicated over shared |
| Bandwidth | Live video is throughput-heavy | Confirm uplink and any data caps |
If transcoding is enabled and concurrency climbs, the streaming process can pin every core and leave Plesk-hosted sites timing out. The clean fix is to pin a clear floor of resources for the control panel and its websites and treat the streaming server as the workload that must live within the remainder, or better, give it its own machine.
What is the right reverse proxy setup?
Most teams want viewers to reach the stream at a tidy `https://stream.example.com` rather than `:5443`, which means a reverse proxy. On a Plesk server you have two sane paths.
The first is to let Plesk’s nginx proxy a subdomain to Ant Media’s 5080/5443 ports. Plesk supports custom nginx directives per domain, so you create a subdomain, point its `proxy_pass` at the local Ant Media instance, and let Plesk continue to own 443 and issue the Let’s Encrypt certificate. This keeps one TLS authority on the box and avoids the 443 tug-of-war.
The critical detail: WebRTC signaling rides a websocket, so your proxy block must pass the `Upgrade` and `Connection` headers, or the player connects then immediately drops. And remember the proxy only carries signaling and HTTP, the UDP media still flows directly to the open port range, bypassing nginx entirely. The reverse proxy never sees your video packets.
The second path is to give Ant Media its own ports and not proxy at all, accessing it directly on 5443. Simpler, but you expose a non-standard port and manage a second certificate. For a clean production setup alongside Plesk, proxying a subdomain through Plesk’s nginx is usually the better answer.
Does it matter that this is Plesk and not cPanel?
The conflicts are nearly identical, only the tooling differs. cPanel typically pairs with WHM and CSF for firewalling and uses different default panel ports (cPanel on 2083, WHM on 2087), so it does not collide with Plesk’s 8443/8880 because you would never run both. The port-planning logic, the WebRTC UDP requirement, and the resource contention concerns are the same on either panel. If you read this guide on a cPanel box, swap “Plesk Firewall extension” for “CSF” and “Plesk nginx” for “the EasyApache/nginx setup,” and everything else holds.
Why is shared hosting the wrong place for this?
You cannot run Ant Media Server on shared hosting at all. Shared plans give you a constrained account on a multi-tenant server with no root access, no ability to install a system-level Java service, no control over the firewall’s UDP range, and no guarantee of CPU or RAM. Streaming is exactly the bursty, resource-heavy workload shared hosting is engineered to forbid.
To run Ant Media Server beside Plesk you need root access, dedicated resources, and full firewall control — the defining features of a VPS or dedicated server.
The right environment from DarazHost
Resource-heavy streaming apps deserve an environment built for them. DarazHost Linux SSD VPS plans (Bronze through Titan) and dedicated servers ship with full root access, so you can install Ant Media Server, tune the JVM, open the WebRTC UDP range, and run Plesk side by side with complete control. You get dedicated CPU and RAM rather than shared scraps, SSD-backed performance for both the panel and the stream, and 24/7 support when a firewall rule or reverse proxy block needs a second pair of eyes. Whether you are testing with a single Bronze VPS or scaling concurrent WebRTC sessions on a Titan-class machine or dedicated hardware, it is the right foundation for streaming alongside a control panel.
How to plan the deployment in practice
Start by mapping every port before you install anything, using the table above as your baseline. Decide your 443 strategy first, because it dictates whether Plesk or Ant Media owns TLS. Install Plesk, confirm the panel answers on 8443, then install Ant Media Server and verify its dashboard on 5443. Only then open the firewall, and crucially, open the UDP media range and test from a network outside your own. Finally, if you want clean URLs, add the reverse proxy subdomain in Plesk with the websocket headers in place.
The pattern that fails is installing both, testing from the LAN, seeing green, and shipping, only to find external viewers get a frozen player because UDP was never opened. Plan the ports, open the UDP range, test externally, and the combination is stable.
Frequently asked questions
Can Ant Media Server and Plesk really run on the same server? Yes. Their default ports do not collide (Plesk on 8443/8880, Ant Media on 5080/5443). The real considerations are opening the WebRTC UDP range, deciding who owns port 443, and ensuring enough CPU and RAM for both. On a VPS or dedicated server with root access, it is a supported and common setup.
Why does my stream connect but show no video on a Plesk server? Almost always the WebRTC UDP media port range is closed in the firewall. Signaling completes over TCP 5443, so the player connects, but the actual audio and video packets travel over UDP and get dropped. Open the UDP range (commonly 50000–60000) and test from an external network, not the LAN.
Do I need a reverse proxy for Ant Media Server behind Plesk? Not strictly. You can reach Ant Media directly on 5443. But a reverse proxy through Plesk’s nginx gives you a clean `https://` subdomain, lets Plesk manage the TLS certificate, and avoids exposing non-standard ports. Just remember to pass the websocket `Upgrade` headers for signaling.
Can I do this on shared hosting? No. Ant Media Server requires root access to install a Java system service and open custom firewall ports, neither of which shared hosting allows. You need a VPS or dedicated server.
Is the setup different on cPanel instead of Plesk? The logic is the same. cPanel uses different panel ports (2083/2087) and CSF for firewalling instead of the Plesk Firewall extension, but the WebRTC UDP requirement, port planning, and resource contention concerns are identical.
