Best RTMP Server Software 2026: MediaMTX vs SRS vs nginx

You want an RTMP server of your own: a box that OBS pushes to, that records the stream, sends it on to Twitch and YouTube, or plays it on your own page. Four free projects keep coming up: MediaMTX, SRS, nginx with the nginx-rtmp-module, and Owncast. They overlap less than the search results suggest. This comparison covers licence, protocols, recording, relaying to several platforms, how actively each one is maintained (we checked every GitHub repository on 8 November 2026) and what each project's own documentation says about server resources.

Quick answer: For most new setups the best free RTMP server is MediaMTX: one MIT-licensed program that takes RTMP, SRT and WebRTC, records to disk and, since version 1.20.0, forwards a stream to Twitch, YouTube or any other RTMP or RTMPS target from its config file. Choose nginx with nginx-rtmp-module only for a plain RTMP relay you already know, because its newest tag dates from 2021. Choose SRS when you need HTTP-FLV, WebRTC playback, built-in FFmpeg transcoding or a cluster. Choose Owncast when you want your own viewer page with chat rather than a relay.

The four RTMP servers at a glance

Protocol lists come from each project's README and docs; release and commit dates from GitHub on 8 November 2026.

Maintenance status in November 2026

An RTMP server listens on a public port, so how often it gets fixes matters more than its feature list.

• MediaMTX shipped six releases between 5 August and 25 October 2026 (v1.20.0 to v1.21.3), and its main branch had commits until 7 November.
• SRS runs three lines at once. 6.0 is the stable one (v6.0-r3); 7.0 is in alpha and 8.0 in development, and all three got a release on the same day at the end of October.
• nginx-rtmp-module has not had a tagged release since v1.2.2, which points to a commit from 25 May 2021. Master has four commits after it, the last a build fix on 24 December 2024, and GitHub lists more than 1,100 open issues and pull requests. Ubuntu 24.04 (universe), Debian 12 and Debian 13 all package this same 1.2.2 as libnginx-mod-rtmp. It still does what it always did, and our own nginx guides use it, but do not wait for SRT, WebRTC or newer codecs there.
• Owncast released v0.3.0 on 3 September 2026, which added plugins and featured streams, and had commits until 25 October.

MediaMTX: the all-round pick

MediaMTX calls itself a "media router": it takes a stream in over one protocol and lets clients read it over another, converting automatically. It is a single executable with no dependencies; its install page recommends the Docker image (bluenviron/mediamtx:1) for production and the standalone binary for trying it out. Defaults: RTMP on TCP 1935, SRT on UDP 8890, HLS on 8888 and WebRTC on 8889.

What it does not do is re-encode. Its docs say to use FFmpeg or GStreamer next to it to change codec or bitrate, for example by starting FFmpeg from the runOnAvailable hook. For a relay that is a plus: the stream is copied, not encoded again.

A private ingest that records and forwards to two platforms takes one block in mediamtx.yml (MediaMTX v1.21.3). Replace the existing authInternalUsers section and add the live path above all_others:

authInternalUsers:
  - user: obs
    pass: use-a-long-random-password
    ips: []
    permissions:
      - action: publish
        path: live
  - user: any
    pass:
    ips: ["127.0.0.1", "::1"]
    permissions:
      - action: api
      - action: metrics
      - action: pprof

paths:
  live:
    record: yes
    recordDeleteAfter: 7d
    forward:
      - dest: rtmps://a.rtmps.youtube.com/live2#YOUR_YOUTUBE_KEY
      - dest: rtmps://ingest.global-contribute.live-video.net/app#YOUR_TWITCH_KEY
  all_others:

In OBS, under Settings, Stream, pick Custom, set Server to rtmp://YOUR_VPS_IP/live?user=obs&pass=use-a-long-random-password and leave the stream key empty; MediaMTX reads RTMP credentials from the user and pass query parameters. Open the port with sudo ufw allow 1935/tcp. Five things the docs point out that are easy to miss:

• The default config lets anyone publish. It ships with the user any holding publish and read rights on every path, so lock that down before the server is public, as above. With that block nobody can watch the stream on the server itself; add a user with the read action if you want to check it in a player.
• Recordings delete themselves. recordDeleteAfter defaults to 1d. Set a longer time, or 0s to keep everything, and watch your disk.
• YouTube needs audio. The forward docs warn that YouTube silently rejects video-only streams.
• The password travels in plain text over RTMP. The authentication docs say to enable encryption or use a VPN. For RTMPS, OBS needs MediaMTX to use a certificate signed by a public certificate authority (or by a local one you install on the OBS machine) and silently rejects self-signed ones.
• Check the ingest URLs. The YouTube and Twitch addresses above are the ones in the MediaMTX docs, which ask you to confirm them in your own dashboard.

To run it as a service, the "Start on boot" page in the MediaMTX docs has a systemd unit. Native forwarding is new (v1.20.0, August 2026); older guides that start FFmpeg from a hook for every destination still work, but you no longer need that.

SRS: the most protocols and a cluster mode

SRS (Simple Realtime Server) supports RTMP, WebRTC, HLS, HTTP-FLV, SRT, MPEG-DASH and GB28181. Its README recommends Docker:

docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 \
    -p 8000:8000/udp -p 10080:10080/udp ossrs/srs:6

Port 1935 is RTMP, 1985 the HTTP API, 8080 the built-in web server with a test player, 8000/udp WebRTC and 10080/udp SRT. On top of the protocols, SRS has an FFmpeg transcoding engine configured inside SRS, which can output to any RTMP server; HTTP callbacks such as on_publish to accept or refuse a publisher; and edge and origin roles for clusters. To play an RTMP stream over WebRTC you switch on rtmp_to_rtc, which transcodes AAC audio to Opus.

Two limits for streamers. A static forward destination is written as ip:port and receives the stream under its own app and stream name, so to push to Twitch or YouTube with a stream key you either run the HTTP backend that answers SRS with full RTMP URLs, or use the transcode engine with copy codecs to output to each platform. And the DVR docs describe SRS recording as basic and point to Oryx, a separate project, for uploading recordings to S3 and merging several sessions into one MP4.

SRS fits best when you build a streaming service rather than a personal relay: several protocols, browser playback with low delay, transcoding and more than one server.

nginx with nginx-rtmp-module: the classic relay

The module adds an rtmp {} block to nginx with RTMP, HLS and MPEG-DASH, recording to FLV, push and pull relays, HTTP callbacks and an XML statistics page. Its README describes buffering designed to keep memory allocations low. A multistream relay is one application block with a push line per platform, and on Ubuntu and Debian it installs from the package libnginx-mod-rtmp.

We have two full guides for it, so we will not repeat the config here: the private RTMP ingest server covers authentication with on_publish, recording and the stats page, and restreaming with nginx-rtmp has a complete nginx.conf with a push line per platform.

Know the limits before you choose it. push speaks plain rtmp:// only (the relay code has no TLS), so a destination that requires RTMPS needs FFmpeg run through exec_push. Check this for Kick: the only ingest address Kick publishes is RTMPS on port 443 (see our Kick guide). There is no SRT or WebRTC, its README lists H264 and AAC, and maintenance is as described above. For a relay that already works, that is fine. For a new build, MediaMTX does the same job with RTMPS, SRT and active releases.

Owncast: your own viewer page, not a relay

Owncast is something else: an "open source, self-hosted, decentralized, single user live video streaming and chat server", in its own words. You stream to it from OBS over RTMP (TCP port 1935, app /live), and it serves a public page with a video player, chat, an admin area and HLS that most video players can open.

Install it with the official script, curl -s https://owncast.online/install.sh | bash, which also fetches FFmpeg if you have none. The docs advise against running it as root and suggest reading the script first. The web page runs on port 8080, and the admin password and the stream key both default to abc123, which the docs tell you to change right after your first login.

Owncast re-encodes by default (one quality to start with) and offers passthrough as an advanced option that saves CPU but can leave some viewers unable to play the stream. It can hand delivery to S3-compatible storage, so viewer traffic leaves from there instead of your server. Its docs do not cover sending your stream on to other platforms; their Restream page describes the opposite, adding Owncast as one destination of that paid service. Running it behind a reverse proxy with HTTPS is covered on its SSL proxies page.

What each one needs from the server

Owncast says there is no single answer to what you need, and the other three READMEs give no minimum spec. Their docs do agree on where the load goes:

• Copying a stream is cheap; encoding is not. The MediaMTX scalability page says that when you stream without re-encoding, the bottleneck is "almost always" the bandwidth between server and viewers. The nginx-rtmp README describes buffering that keeps memory allocations low. Both only copy unless you add FFmpeg.
• Every transcoded quality costs CPU. Owncast's requirements page gives, as a rough measured example, one CPU core per transcoded output quality at 30 fps, says 60 fps takes about twice the CPU of 30 fps, and that CPU use stays the same whether one or a thousand people watch. SRS forks an FFmpeg process to transcode.
• Bandwidth grows with copies. A relay sends one copy per destination: a 6 Mbps stream to three platforms is 18 Mbps out, 8.1 GB an hour, about 970 GB a month if you stream four hours a day. A viewer page sends one copy per viewer: Owncast's docs estimate that a 1 Gbps port carries roughly 200 viewers at 5000 kbps.
• WebRTC wants bigger UDP buffers. SRS's performance page calls the kernel's UDP buffer size the first and most important setting for WebRTC and raises it to 16 MB.

So a relay or private ingest runs on a small VPS with enough monthly transfer; add cores only for transcoding. The bandwidth sums for a public viewer page, and when a CDN becomes worth it, are in our video streaming server guide.

Which RTMP server fits which job

If you are not sure you need SRT at all, read RTMP vs SRT vs SRTLA first. For IRL streams over bonded mobile links, our BELABOX and SRTLA guide puts MediaMTX behind an SRTLA receiver.

Running your RTMP server on a VPS

All four run on a Linux VPS with a public IP. Our VPS plans run in an EU data center with full root access, NVMe storage and a 1 Gbps port. As of 8 November 2026 both tiers can be ordered: Premium (Ryzen 9 9950X) starts at €4.20 a month for VPS-XS with 2 vCores, 2 GB RAM and 5 TB of monthly transfer, and Standard (AMD EPYC 7452) at €4.99 for VPS-S with 3 vCores, 4 GB RAM and 10 TB. A MediaMTX or nginx relay fits the smallest plan; give Owncast or an SRS transcode more cores.

FAQ

What is the best free RTMP server?

For a new setup, MediaMTX: MIT licence, RTMP, SRT and WebRTC in one program, recording, native forwarding to several platforms and regular releases. All four servers here are free and open source; SRS is the stronger pick for a larger multi-protocol service, and Owncast for a viewer page with chat.

Is nginx-rtmp-module still maintained?

Barely. The newest tag is v1.2.2 on a commit from May 2021, the last commit is from December 2024, and Ubuntu and Debian still package 1.2.2. It works for RTMP, HLS and DASH with H264, but do not count on new protocols or codecs.

Can MediaMTX restream to Twitch and YouTube?

Yes, since v1.20.0. Add a forward list to a path with one dest per platform, written as rtmps://host/app#streamKey. Older versions needed FFmpeg started from a hook for each destination.

What is the difference between MediaMTX and Owncast?

MediaMTX moves streams between protocols and servers without re-encoding them. Owncast is a finished website for one streamer: it takes RTMP, transcodes it, and shows it to viewers with chat. Use MediaMTX to record and relay, and Owncast when your audience should watch on your own domain.

How big a server does RTMP server hosting need?

For a relay that only copies the stream, CPU barely matters; plan for bandwidth, which is bitrate times the number of destinations or viewers. Add about one CPU core per transcoded quality at 30 fps, the rough figure in Owncast's docs.

Sources

All opened on 8 November 2026:

• MediaMTX: README, releases, v1.20.0 release notes, default mediamtx.yml for v1.21.3, docs on install, forward, record, authentication, re-encoding, scalability, start on boot, RTMP clients and OBS Studio
• SRS: README and release list, releases, docs on getting started, forward, DVR, SRT, WebRTC, FFmpeg transcoding, HTTP callbacks and performance
• nginx-rtmp-module: README, tags, commits, licence, relay module source; packages for Ubuntu 24.04, Debian 12 and Debian 13
• Owncast: README, v0.3.0 release, docs on installation, broadcasting, video, resources and requirements and Restream
• UFW manual page (Ubuntu 24.04): manpages.ubuntu.com