Site icon WpStream – A WordPress Video Streaming Plugin

Build Your Own Video Streaming Server: A Comprehensive Guide

Joe Shillito

Build Your Own Video Streaming Server (RTMP Server): A Comprehensive Guide

Last updated: June 28, 2026 | By the WpStream Editorial Team

To build a live streaming server, you install Nginx with the RTMP module on a Linux VPS, configure a server block that listens on port 1935 for an RTMP feed from your encoder, add an HLS output block so browsers can watch, and open the firewall. That core setup takes under an hour. But the box is the easy 10 percent; the other 90 percent is adaptive bitrate transcoding that nginx-rtmp will not produce for you, the CDN you will need past a few hundred concurrent viewers, and a total cost that often surprises. This guide covers every command for the Nginx build, maps the actively maintained server alternatives for 2026, runs the bandwidth cost math from a single VPS to 10,000 concurrent viewers, and gives an honest decision framework for when to build and when to hand the problem to a managed service instead.

What a live streaming server actually does

A streaming server is not one thing. It is a pipeline of four stages, each with a different job and a different cost as your audience grows. Get this model in your head and every later decision makes sense. The pipeline below shows the path a broadcast takes from camera to viewer.

The four-stage live streaming server pipeline: ingest, transcode, package, deliver.

Each stage owns this:

  1. Ingest. Receives the broadcaster’s feed. The dominant ingest protocol is RTMP, pushed over TCP on port 1935. Your encoder (OBS, vMix, Wirecast, FFmpeg, or hardware) captures H.264 video and AAC audio and pushes that to the ingest URL. This is what people mean by RTMP server. Here is what RTMP stands for.
  2. Transcode. Turns one feed into multiple bitrate and resolution renditions, say 1080p down to 360p, enabling adaptive bitrate where the player picks the rendition matching each viewer’s connection. It is heavy on CPU or GPU.
  3. Package. Chops the renditions into 2 to 6 second segments and writes the .m3u8 manifest for HLS. RTMP comes in; HLS goes out for browser playback.
  4. Deliver. Serves the HTTP segments to viewers. At small scale the origin serves directly; at real scale a CDN caches segments at edges close to the audience.

RTMP for ingest, HLS for delivery, is the standard modern combination. The reader who only thinks “I need a server” is picturing stage one. And that is the trap: the hard, expensive parts are stages two and four, transcode and deliver.

Hands-on: build an Nginx and RTMP server

One honesty note before a single command. The classic build is Nginx plus the RTMP module, but the original arut/nginx-rtmp-module repository is effectively unmaintained: its last meaningful release was around 2017. It still works and is everywhere, but reach for a maintained community fork such as sergey-dryabzhinsky, or the distribution package libnginx-mod-rtmp, which tracks a fork. Treat arut’s module as load-bearing legacy, not active software.

The real minimal build: Ubuntu target, OBS pushing in, HLS coming out.

Step 1: Install Nginx with the RTMP module

sudo apt update
sudo apt install libnginx-mod-rtmp

Ubuntu’s default Nginx package does not include RTMP. The distribution module package is the easiest path and spares you compiling from source. DigitalOcean’s nginx-rtmp setup tutorial walks the same install in more depth if you want a second reference.

Step 2: Add the RTMP server block

Add this at the top level of /etc/nginx/nginx.conf, not inside the http block:

rtmp {
    server {
        listen 1935;
        chunk_size 4096;
        allow publish 127.0.0.1;
        deny publish all;
        application live {
            live on;
            record off;
        }
    }
}

The directives that carry weight: listen 1935 opens the RTMP port; allow publish with deny publish restricts who can push, so a stranger cannot hijack your ingest; live on enables fan-out to viewers.

Step 3: Open the firewall and reload

sudo ufw allow 1935/tcp
sudo systemctl reload nginx.service

Step 4: Point OBS at it

In OBS, open Settings, then Stream. Set Service to Custom, Server to rtmp://YOUR_DOMAIN/live, and Stream Key to anything (say, stream). Add the broadcasting machine’s IP to the allow publish line if it is not local. Encoder settings: H.264, CBR, 2 second keyframe interval.

Step 5: Add HLS output for browsers

Browsers cannot play RTMP. Extend the live application block:

application live {
    live on;
    record off;
    hls on;
    hls_path /var/www/html/stream/hls;
    hls_fragment 3;
    hls_playlist_length 60;
}

Create that directory, serve it from an http server block, and viewers load the .m3u8 playlist in an HLS player such as hls.js, Video.js, or native Safari/iOS.

Step 6: The honest next steps

That is a working RTMP server, not a finished one. You still owe TLS for the player page, an FFmpeg exec step for the adaptive bitrate ladder (the module will not build it), a CDN once you pass a few hundred viewers, and monitoring. This is where a weekend project quietly becomes an ops job.

Which streaming server should you run in 2026?

The nginx-rtmp module is the default everyone reaches for and also the least maintained option on the list. Here are the actively-developed alternatives plus the honest commercial choices. Maintenance status and licenses were checked June 2026; confirm each on the project’s own repository or pricing page before you commit.

Software License Ingest Output Built-in ABR Scaling Best for
nginx-rtmp-module BSD-2, free RTMP HLS, DASH, RTMP No, FFmpeg DIY None native Classic single-server hobby and learning
MediaMTX MIT, free RTMP, SRT, WebRTC, RTSP HLS and more No No Tiny footprint, zero-config RTMP-to-HLS repackaging
SRS MIT, free RTMP, SRT, WebRTC HLS, FLV, DASH Limited Yes, origin and edge Fuller open server with a scaling story
Owncast MIT, free RTMP HLS Optional multi-variant (CPU cost) No Drop-in self-hosted “own Twitch”
Ant Media CE and EE Open core RTMP, WebRTC, SRT HLS, LL-HLS, WebRTC Yes, mostly EE Yes, EE Dashboard and low latency, paid for the good parts
Wowza Streaming Engine Commercial, about $195/mo, June 2026 RTMP and more HLS and more Yes Yes Supported commercial self-host

Three things the table cannot show. First, nginx-rtmp and MediaMTX do not do adaptive bitrate transcoding; you wire up FFmpeg yourself. Second, “Ant Media is free” is half true: the ABR, low-latency, and scaling features sit largely in the paid Enterprise edition. Third, Wowza’s roughly $195 per month (from its own pricing page, June 2026; confirm before buying) buys software plus support and does not make the bandwidth bill disappear.

The bandwidth wall: what it actually costs at scale

This is the math most build-versus-buy guides skip. The rule: origin egress equals concurrent viewers times stream bitrate times overhead. Delivering one stream to many viewers grows egress linearly with the audience. Double the crowd, double the pipe.

A worked illustration (figures as of June 2026; confirm current cloud pricing before budgeting): 500 concurrent viewers at 5 Mbps each with a 1.2 overhead factor equals about 3,000 Mbps, roughly 3 Gbps of sustained egress from your origin. A typical VPS realistically serves about 200 simultaneous 1080p viewers before it saturates. So a few hundred viewers is the wall where single-box DIY breaks.

The moment you outgrow one box, scaling DIY means standing up multiple origin and edge servers and load-balancing them yourself. You are now building and operating a small CDN. Large platforms solve this with a CDN for live streaming that caches segments at edges close to viewers, lifting the load off the origin.

A single small cloud instance runs around $5 to $50 per month but caps at a few hundred viewers. Egress is the dominant cost at scale, not compute or storage. As an illustrative rate, AWS CloudFront runs around $0.085 per gigabyte for the first 10 TB. At roughly 10,000 concurrent 1080p viewers, egress alone can run around $8,000 to $15,000 per month depending on provider and region. DIY is genuinely cheapest at small scale. The cost curve and the ops curve both bend sharply upward the moment you need adaptive bitrate plus multi-region delivery plus redundancy. That bend is the entire build-versus-buy decision.

Failure modes a beginner will actually hit

These are the traps that turn a working demo into a dead stream, each with its fix:

Build vs buy: an honest decision framework

Both sides win something real here. This is not a setup for a predetermined answer.

DIY wins are real: maximum control of the full stack, the cheapest cost at small scale, no per-stream royalties, no vendor lock-in, full control of your data location.

The costs are just as real. You own adaptive bitrate transcoding, packaging, delivery scaling, security patching, uptime, and redundancy. You own the linear bandwidth wall and fork management for partly-maintained tooling. A self-managed deployment can quietly eat hundreds of developer-hours a year on patching alone.

Managed flips that load: multi-CDN delivery and adaptive bitrate are handled for you, scaling and reliability become the vendor’s job. The tradeoff is less control, per-usage pricing, and potential lock-in.

One honest number: once you price in people, uptime risk, and scale, self-managed streaming total cost of ownership is frequently 3 to 5 times higher than an autoscaling managed service. Treat it as a rule of thumb, not a quote.

The decision heuristic: for learning, a hobby stream, an internal tool, or a one-off event under a few hundred viewers, DIY on nginx-rtmp, MediaMTX, or SRS is a great fit. For a real audience, a business that depends on uptime, regional viewers, or a team that would rather build product than operate a CDN, managed wins and is usually cheaper once ops time is counted.

The managed option on WordPress: WpStream

Full disclosure first: this guide is published by WpStream, one of the managed options in the comparison above. You should know who is writing before we describe our own product.

WpStream is a WordPress live streaming and pay-per-view plugin: broadcast live and charge for access, on a site you already control. As of June 2026 the WordPress.org listing shows 4,000-plus active installs at 4.8 out of 5; re-check the live listing, since active installs only tick upward in coarse buckets.

Mapped onto the four-stage pipeline, the trade is clean. For ingest, WpStream takes the same RTMP push from OBS, vMix, Wirecast, or StreamYard the DIY reader just learned and replaces the server you would otherwise run. RTMP ingest is on every tier, including the Free plan, which serves up to 50 concurrent viewers via external RTMP ingest; browser-based broadcasting is a paid feature.

Transcoding and the adaptive bitrate ladder are handled for you. For delivery, WpStream runs a multi-CDN across multiple continents. That is the bandwidth wall from the cost section, removed.

The honest tradeoff: you give up low-level server control in exchange for never solving transcoding, ABR, multi-CDN delivery, or the origin-bandwidth problem yourself. If you want to learn the stack or need absolute control, the DIY route above is the right call. If you would rather stream and monetize on WordPress without running infrastructure, developers can wire it in with the WpStream API documentation. Pricing starts with a Lite tier at $24 per month or $36 one-time; the other tiers are on the pricing page.

Key Takeaways

Frequently Asked Questions

What is the difference between an RTMP server and an HLS server?

RTMP is the ingest side, where your encoder pushes a feed in on port 1935. HLS is the delivery side, where browsers pull small segments. A live streaming server, whether the Nginx build above or a managed service like WpStream, does both: RTMP in, HLS out.

Is nginx-rtmp-module still safe to use in 2026?

It works and is widely deployed, but the original module is effectively unmaintained, so use a maintained community fork or the distribution package. A managed service like WpStream removes that maintenance concern entirely.

How many viewers can one streaming server handle?

Roughly a few hundred 1080p viewers per typical VPS before egress saturates, after which you need a CDN. WpStream delivers over a multi-CDN, so you do not hit that single-box ceiling.

Can I run a streaming server for free?

The software (nginx-rtmp, MediaMTX, SRS, Owncast) is free, but you still pay for the server and the bandwidth it sends. WpStream accepts external RTMP ingest if you would rather not run a box at all.

The real question is not how, it is whether

You now know how to build the box, and you know the box was always the easy 10 percent. The decision that matters is whether streaming infrastructure is your product or just a feature you need. If you are learning, experimenting, or serving a small room, build it; the walkthrough above teaches the whole pipeline. If a real audience and real uptime are on the line, hand the transcode-and-deliver problem to a managed service, and on WordPress that is the conversation WpStream is built for.

Exit mobile version