What Is an RTMP Server? How It Works, Setup, and Top Software Options

RTMP servers are the backbone of live streaming workflows worldwide. Despite being developed by Adobe in the early 2000s, RTMP remains the dominant ingest protocol for live video — used by OBS, Streamlabs, XSplit, Wirecast, and virtually every hardware encoder on the market.

If you’re building a live streaming app or setting up a broadcast pipeline, you need to understand what an RTMP server does, how to run one, and when a self-hosted server makes sense versus a managed alternative.

This guide covers what an RTMP server is, how the protocol works, the best open-source and commercial software options, a step-by-step setup guide using nginx-rtmp, and a protocol comparison to help you decide what’s right for your project.

What Is an RTMP Server?

An RTMP server is a media server that receives, processes, and distributes live video streams using the Real-Time Messaging Protocol. It acts as the central hub in a live streaming pipeline: encoders push video to the server, and the server relays that stream to viewers — either directly or through a CDN.

RTMP was originally developed by Macromedia (later acquired by Adobe) and runs over TCP on port 1935. The protocol splits audio and video data into small chunks — 128 bytes for video, 64 bytes for audio — and sends them in an interleaved stream. This chunk-based design keeps latency low, typically in the 2–5 second range.

Every time a streamer goes live on YouTube, Twitch, or Facebook using OBS, the encoder sends an RTMP stream to that platform’s RTMP server. The server then transcodes and packages the stream for delivery to viewers.

If you’re building your own streaming platform, you need your own RTMP server to receive those inbound streams before delivering them to your audience.

Key RTMP Server Functions

• Ingest: Accept incoming streams from encoders over TCP port 1935
• Authentication: Validate stream keys to authorize broadcasters
• Transcoding: Convert the raw stream into delivery formats (typically HLS)
• Packaging: Split the stream into segments for adaptive bitrate playback
• Distribution: Push the packaged stream to a CDN or directly to players

How Does an RTMP Server Work?

Understanding the flow from encoder to viewer helps clarify where the RTMP server fits — and what happens when something goes wrong.

1. The Encoder Connects

The broadcaster’s encoder (OBS, hardware encoder, or software SDK) opens a TCP connection to the RTMP server using the server’s IP address or hostname, port 1935, and a stream key. The stream key authenticates the broadcast and routes it to the correct channel.

2. The Three-Way Handshake

RTMP uses a specific handshake sequence before streaming begins. The encoder sends an initial 1,537-byte handshake packet, the server responds with its own, and both sides confirm the connection. This takes under one second under normal network conditions.

3. Video and Audio Chunks Arrive

Once connected, the encoder sends audio and video in separate chunk streams. The server receives these chunks and reassembles them into a continuous stream. Video is typically encoded as H.264; audio as AAC. The server maintains the chunk stream and handles any packet reordering.

4. Transcoding and Packaging

Most RTMP servers don’t just relay the raw stream — they transcode it. Video encoding converts the incoming stream into one or more output formats, usually HLS, and generates multiple quality renditions for adaptive bitrate streaming. This lets viewers on different devices and connection speeds watch the same stream without buffering.

5. Delivery to Viewers

The processed stream goes to a delivery layer — either directly served to video players or pushed to a CDN for live streaming that distributes it globally. The CDN caches the stream segments and serves them from edge locations close to each viewer.

Types of RTMP Server Software

RTMP server software falls into two categories: self-hosted open-source options and managed or commercial media servers. Each has different tradeoffs in cost, complexity, and scalability.

Open-Source RTMP Servers

nginx-rtmp

The nginx RTMP module (nginx-rtmp-module) is the most widely used open-source RTMP server. It turns an nginx web server into an RTMP ingest point with HLS output. It’s lightweight, well-documented, and free — but it requires manual setup, and transcoding requires an additional ffmpeg integration.

SRS (Simple Realtime Server)

SRS is a high-performance open-source media server written in C++. It supports RTMP, HLS, WebRTC, and SRT out of the box. SRS handles higher concurrent streams than nginx-rtmp and includes built-in HTTP API for stream management — but it has a steeper learning curve.

Ant Media Server

Ant Media Server is available as both a free community edition and a commercial product. It supports RTMP, WebRTC, HLS, and DASH with a web management UI, making it easier to operate than nginx-rtmp. The community edition handles most production use cases.

Red5

Red5 is a Java-based open-source RTMP server, one of the oldest in the ecosystem. It supports RTMP, RTMPS, and RTMPT but runs heavier than nginx-based options and requires Java. It’s better suited for legacy applications than new builds.

Commercial and Managed RTMP Servers

Commercial options include Wowza Streaming Engine (a self-hosted Java media server) and cloud services like AWS MediaLive, Mux, and LiveAPI. These remove infrastructure management entirely — you get an RTMP ingest endpoint, and the platform handles transcoding, CDN delivery, and scaling.

RTMP vs. Other Streaming Protocols

RTMP isn’t the only option for live streaming ingest or delivery. Here’s how it compares to the most common alternatives — and why most pipelines actually use multiple protocols together.

RTMP vs HLS: These protocols handle different parts of the pipeline. RTMP is for getting video *into* a server (ingest); HLS streaming is for getting video *out* to viewers. Most live streaming pipelines use both — RTMP in, HLS out. You can read more about what HLS is and how it differs architecturally.

RTMP vs SRT: SRT vs RTMP is the most relevant ingest comparison. SRT is a newer UDP-based protocol designed for unreliable networks — cross-continent contribution links, cellular connections, or satellite uplinks. RTMP is more widely supported by encoders. SRT wins on network resilience; RTMP wins on compatibility.

RTMP vs WebRTC: WebRTC targets sub-500ms latency for real-time communication. It’s built for video calls, interactive broadcasts, and live auctions. RTMP is better suited for broadcast-style streams where encoder compatibility matters more than sub-second latency.

RTMP vs RTSP: RTSP is mainly used for IP cameras and surveillance systems. It controls media playback rather than delivering streams to large audiences. The two protocols overlap at the ingest layer for camera feeds but serve different use cases.

Hardware Requirements for an RTMP Server

Self-hosting an RTMP server requires the right infrastructure. Requirements depend on concurrent stream count and whether you’re transcoding.

RTMP ingest only (no transcoding):

• CPU: 2 cores
• RAM: 2 GB
• Bandwidth: 10 Mbps per 1080p stream ingest

RTMP ingest with transcoding (nginx + ffmpeg, H.264 to HLS):

• CPU: 4+ cores per concurrent transcoded stream
• RAM: 4–8 GB
• Bandwidth: 20–50 Mbps per stream (input + multiple HLS output renditions)
• Storage: Fast SSD for HLS segment buffering (≥100 GB recommended for live DVR)

A 4-core, 8 GB cloud VPS handles 3–5 concurrent transcoded streams. For more concurrent streams, you’ll need to scale horizontally — running multiple transcoding nodes behind a load balancer. This is where self-hosting complexity grows quickly. Good video streaming server resources go deeper on sizing decisions.

How to Set Up an RTMP Server with nginx-rtmp

This setup runs nginx with the RTMP module on Ubuntu 22.04 LTS. It creates an RTMP ingest endpoint and outputs HLS for browser playback — the foundation of most self-hosted live streaming setups.

Prerequisites

• Ubuntu 22.04 VPS (4 CPU, 4 GB RAM recommended)
• Root or sudo access
• Port 1935 open in your firewall

Step 1: Install nginx with the RTMP Module

sudo apt update

sudo apt install -y nginx libnginx-mod-rtmp

Step 2: Configure nginx

Open the nginx configuration file:

sudo nano /etc/nginx/nginx.conf

Add the RTMP block at the end of the file, outside the `http {}` block:

rtmp {

server {

listen 1935;

chunk_size 4096;

application live {

live on;

record off;

# Output HLS

hls on;

hls_path /var/www/html/hls;

hls_fragment 3;

hls_playlist_length 60;

}

}

}

Then update the `http` server block to serve HLS segments to players:

server {

listen 80;

location /hls {

types {

application/vnd.apple.mpegurl m3u8;

video/mp2t ts;

}

root /var/www/html;

add_header Cache-Control no-cache;

add_header Access-Control-Allow-Origin *;

}

}

Step 3: Create the HLS Output Directory

sudo mkdir -p /var/www/html/hls

sudo chown www-data:www-data /var/www/html/hls

Step 4: Open the Firewall

sudo ufw allow 1935/tcp

sudo ufw allow 80/tcp

sudo ufw reload

Step 5: Restart nginx

sudo systemctl restart nginx

sudo systemctl status nginx

Step 6: Configure Your Encoder

In OBS or any RTMP encoder, set:

• Server: `rtmp://YOUR_SERVER_IP/live`
• Stream Key: any string (e.g., `mystream`)

Your HLS output will be available at:

http://YOUR_SERVER_IP/hls/mystream.m3u8

This URL works in any HLS-compatible video player, including native iOS/macOS playback and browser-based players with HLS.js.

This setup handles live RTMP streams for development and small-scale use. For larger deployments, you’ll need to handle transcoding with ffmpeg (for multiple quality renditions), add stream key authentication, configure HTTPS for RTMPS, and integrate a CDN separately.

That added infrastructure work is what separates self-hosted RTMP from managed alternatives. Before deciding which path to take, it’s worth comparing the two approaches across the dimensions that actually matter for your project.

Self-Hosted vs. Managed RTMP Server

Choose self-hosted if: You have the DevOps resources to manage servers, you’re streaming at high enough volume that per-minute pricing exceeds VPS costs, or you need on-premises deployment for compliance.

Choose managed if: You’re building a product and need to ship fast, you need global CDN delivery, or you’d rather not maintain streaming infrastructure as your core competency.

Using a Managed RTMP Server with LiveAPI

Managed platforms like LiveAPI’s live streaming API handle RTMP ingest, transcoding, CDN delivery, and VOD recording without running any server infrastructure on your end.

You get a dedicated RTMP ingest endpoint (plus SRT support), automatic transcoding to HLS with adaptive bitrate output, delivery through CDN partners including Akamai, Cloudflare, and Fastly, and an embeddable player. The entire pipeline is ready in minutes.

The integration looks like this:

const sdk = require('api')('@liveapi/v1.0#5pfjhgkzh9rzt4');

sdk.post(‘/live-streams’, {

name: ‘My Live Event’,

record: true

})

.then(({ data }) => {

console.log(‘RTMP URL:’, data.rtmpUrl);

console.log(‘Stream Key:’, data.streamKey);

});

Once you have the RTMP URL and stream key, point OBS (or any encoder) at those credentials and you’re live. LiveAPI handles the rest: transcoding, packaging, CDN distribution, and automatic VOD creation when the stream ends.

For teams that want to stream to multiple platforms at the same time, the multistream API rebroadcasts to 30+ destinations from a single ingest — no separate encoder configurations needed.

Is RTMP Server Right for Your Project?

RTMP ingest is still the right choice for most live streaming pipelines. Nearly every encoder — software or hardware — supports RTMP. If your use case involves any of the following, you need RTMP ingest:

• Receiving streams from OBS, Wirecast, or hardware encoders
• Broadcasting to a custom OTT or streaming platform
• Accepting streams from IP cameras or other RTSP/RTMP sources
• Building a live video streaming platform that needs broad encoder compatibility

RTMP is not the right choice if:

• You need under 500ms latency — use WebRTC instead
• You’re streaming over satellite or unreliable cellular links — SRT handles packet loss better
• You only need to deliver existing video files — RTMP is a live ingest protocol, not for VOD

For the viewer-facing delivery layer, RTMP is almost never the answer. Browsers don’t support RTMP natively, so the standard approach is always RTMP in, HLS out.

RTMP Server FAQ

What is an RTMP server?

An RTMP server is a media server that receives live video streams from encoders using the Real-Time Messaging Protocol, processes or transcodes the stream, and delivers it to viewers. It’s the ingest layer in a live streaming pipeline, sitting between the broadcaster’s encoder and the CDN that serves content to viewers.

What port does an RTMP server use?

RTMP uses TCP port 1935 by default. RTMPS (RTMP over TLS) runs on port 443 — the same as HTTPS — which is useful when port 1935 is blocked by firewalls. RTMPT (RTMP tunneled over HTTP) can also use port 80 or 443 as a fallback.

Is RTMP still relevant?

Yes. RTMP remains the standard ingest protocol for live streaming. Flash Player (which originally required RTMP for browser playback) is long gone, but RTMP’s role as a low-latency encoder-to-server transport protocol is unchanged. Virtually every live streaming workflow today — YouTube, Twitch, Facebook, Kick — still accepts RTMP ingest.

What is the difference between RTMP and RTMPS?

RTMPS is RTMP encrypted with TLS. It prevents interception of the stream between the encoder and server and runs on port 443. Most major platforms — including YouTube, Facebook, and Twitch — now require RTMPS. When building your own RTMP server, you’ll need a valid TLS certificate and nginx or Stunnel configured to handle RTMPS termination.

Can you run an RTMP server on Windows?

Yes. Ant Media Server, Red5, and Wowza Streaming Engine all run natively on Windows. nginx-rtmp is Linux-primary but runs on Windows via WSL (Windows Subsystem for Linux). For local development on Windows, a Node.js video streaming server can also handle RTMP ingestion as a lighter alternative.

How many concurrent streams can an RTMP server handle?

It depends on hardware, transcoding load, and bandwidth. A 4-core VPS running nginx-rtmp (ingest relay only, no transcoding) can handle 30–50 concurrent streams. Add transcoding and that drops to 3–5 streams per 4-core server. Managed platforms handle unlimited concurrent streams through automatic horizontal scaling.

What’s the latency of an RTMP server?

End-to-end RTMP latency — from encoder to viewer — is typically 3–15 seconds. The protocol itself adds 1–2 seconds; transcoding and HLS packaging add the rest. Reducing chunk sizes and HLS segment lengths can get you to the 2–4 second range. For true sub-second latency, you’d need WebRTC or CMAF with chunked transfer encoding.

What’s the difference between RTMP ingest and RTMP delivery?

RTMP ingest means the encoder sends video *to* the RTMP server over port 1935. RTMP delivery (pushing the processed stream to viewers) was common in the Flash era but is now rare since browsers don’t support it natively. Modern pipelines use RTMP ingest and HLS delivery — the server converts the incoming RTMP stream to HLS for viewer playback.

Getting Started with Live Streaming

An RTMP server is the entry point for any live streaming pipeline. Whether you run your own nginx-rtmp instance on a VPS or use a managed platform, the fundamentals are the same: your encoder pushes video to the server, the server transcodes and packages it, and a CDN delivers it to viewers.

For developers building a streaming app, a managed RTMP server removes the infrastructure work and gets you live faster — no server provisioning, transcoding pipelines, or CDN configuration required.

Get started with LiveAPI to set up RTMP ingest, transcoding, and global CDN delivery with a few lines of code.