An RTMP server receives a stream from software such as OBS and makes it available at a stream path for another service or viewer to read. For a first test on Windows, Linux, or Mac, MediaMTX offers a direct route: download the matching executable, launch it, and publish from OBS to a local URL.
This is a guide to running a server on a computer you control, not a guide to sending a file directly to YouTube. A local test can confirm that OBS reaches MediaMTX; making the stream reachable from another network requires deliberate network configuration. If your goal is simply to keep a prerecorded YouTube channel live while your computer is off, StreamNeo has a separate hosted YouTube workflow, rather than a self-hosted RTMP server.
What an RTMP server does
RTMP is a protocol for sending audio and video from a publishing application to a receiving endpoint. In a typical setup, OBS encodes the scene or media and sends it to a server address plus a stream path. The server accepts that incoming connection and makes the stream available to a client or to a further destination.
That receiving role is easy to confuse with YouTube’s ingest service. When you stream directly to YouTube, YouTube receives the connection. When you run MediaMTX locally, your own computer receives it. A local MediaMTX server does not automatically relay its contents to YouTube; forwarding is a separate configuration, and your local server must be reachable from wherever it needs to send or receive video.
For example, a local test can use OBS on your computer to publish to rtmp://localhost/mystream. Here, localhost means the same computer that is running MediaMTX, and mystream is the path. This verifies a basic publishing path without requiring a public IP address, a router change, or a paid host.
For an always-on devotional, music, or ambience channel, consider what the server is meant to accomplish before installing anything. A private RTMP server can be useful for learning, receiving a feed inside a studio network, or building a pipeline you manage. If the requirement is only to keep a prerecorded programme live on YouTube, compare the workflow with a 24/7 prerecorded-stream setup before taking on a server you may not need.
Choose MediaMTX, Docker, or NGINX
MediaMTX is a practical starting point because its official introduction lists Windows, macOS, and Linux compatibility and describes it as a standalone executable without a separate dependency or interpreter. It supports several media protocols, including RTMP, so you can begin with one process and a local OBS test. Read the MediaMTX introduction for its current scope and protocol notes.
Docker is the documented alternative when you already manage containers or want a more repeatable deployment. MediaMTX recommends its Docker approach for production environments. The example on its installation page maps TCP port 1935 for RTMP and includes mappings for other protocols; a simple RTMP-only use case does not need to expose every port in that example. Follow the current official instructions rather than copying an old command or image tag.
NGINX with an RTMP module fits a different situation: you specifically need an NGINX-based stack or already operate NGINX and want to integrate the RTMP module with it. NGINX’s current documentation page describes its NGINX Plus dynamic module. Older community guides can explain the general shape of an NGINX RTMP setup, but their operating-system package instructions may no longer match current releases.
| Route | Useful when | What to plan for |
|---|---|---|
| MediaMTX executable | You want a straightforward local test across Windows, Linux, or macOS | Choose the correct operating system and CPU architecture; run the process while testing |
| MediaMTX in Docker | You already use containers or need a more managed deployment | Install and operate Docker, map only the ports and transports you need, and consult the current MediaMTX example |
| NGINX with RTMP module | Your deployment specifically calls for an NGINX-based configuration | Check the current NGINX module documentation and platform/package availability |
There is no need to choose based on a supposed speed or latency winner: the cited setup material does not provide a controlled performance comparison. Choose based on how you want to install, operate, and maintain the receiving endpoint. If you only need a YouTube destination, a custom-thumbnail service comparison can help frame a hosted workflow instead of building an RTMP stack.
Download the matching MediaMTX binary
Start at the MediaMTX installation page and select the release artifact matching both your operating system and CPU architecture. A Windows computer, an Intel Mac, an Apple silicon Mac, and different Linux machines should not be assumed to use the same download. The release page is the appropriate place to verify the available artifact names as they can change.
Extract the downloaded archive before running the executable. Keep the extracted files together: the configuration and any accompanying files are easier to locate when you start the program from its own folder. For a first test, use the default configuration rather than changing listener ports, authentication, or protocols before you know the basic connection works.
On Windows, the documented basic path is to double-click mediamtx.exe. On Linux and macOS, open a terminal in the extracted directory and run ./mediamtx. The exact way you open a terminal or approve software varies by system, so use your operating system’s current guidance if it blocks an executable. Do not assume that installing the binary also makes it run in the background after you log out or restart.
This is an interactive test setup, not yet a 24/7 operating plan. Keep the process window open while testing and note where its output appears. If you later need the server to start automatically, run under a service manager, or survive a machine reboot, that becomes a separate operating-system administration task. You should make and test that change deliberately rather than treating a successful manual launch as proof of unattended operation.
Launch the server
Start MediaMTX from the extracted folder. On Windows, launch mediamtx.exe; on Linux or macOS, run ./mediamtx from a terminal in that directory. Leave the window or terminal available, because it is where you can see whether the process starts and how it responds when OBS connects.
For the first local test, do not change the configuration. The default setup is enough for the documented OBS publishing example. The installation documentation’s Docker example includes RTMP on TCP port 1935, but that does not mean you must manually open that port on your router for a same-computer test. A local address and a publicly reachable address are different things.
If MediaMTX reports that a port is already in use, another process may already be listening there. Do not respond by opening more ports indiscriminately. Identify whether you have another media server or a previous MediaMTX process running, then either stop the conflict or consult the current configuration documentation to choose a different listener port and use that same port in OBS.
Docker changes how the process is packaged and launched, not the basic publishing idea. Use the current MediaMTX Docker directions, including their current image reference and required options. Map TCP port 1935 for RTMP if RTMP is the protocol you need; map other ports only for services you intend to use. Docker’s port mappings expose container services through the host, so understand which interface and network can reach them before using a container in a shared or public environment.
Point OBS to the local RTMP URL
Open OBS Studio’s stream settings and choose the custom service option. In the Server field enter rtmp://localhost/mystream, leave Stream key empty, save the settings, and select Start Streaming. These steps follow the MediaMTX OBS publishing guide; the exact wording or placement of OBS controls may change between versions.
The address is composed of the RTMP scheme, the host, and a path. rtmp:// identifies the protocol. localhost directs the publishing connection back to the same computer. /mystream identifies the stream path MediaMTX serves. It is not a YouTube stream key, and you do not need to paste your YouTube credentials into this local test.
If OBS and MediaMTX run on separate devices on the same local network, localhost is wrong: it would refer to the OBS device itself. Replace it with the reachable local address of the computer running MediaMTX and keep the stream path consistent. The devices must be able to communicate over the network, and host firewall rules may affect whether the connection succeeds.
Once the test works, decide what the output should do. A viewer on your network may read the path from MediaMTX, or you can configure a forward to another destination if that fits your design. For a continuous programme, the media itself and its encoding choices still matter; this recorded-class video quality guide covers choices for a YouTube-oriented use case. Do not assume that a locally received stream is automatically being relayed to YouTube.
Check connectivity and logs
Keep the MediaMTX output visible while you press Start Streaming in OBS. A successful connection should produce activity showing that a publisher connected and is writing to the stream path. If OBS reports a connection failure, compare the server address and path first, then confirm the MediaMTX process is still running. Those checks catch the simplest mismatch without changing network settings.
If the server and OBS are on the same machine, test with localhost exactly as documented. If they are on different devices, verify that the address points to the MediaMTX host and that the devices are on a network where communication is allowed. A public address is not required just because the phrase “RTMP server” sounds remote; it is only relevant when a remote publisher or viewer must reach your endpoint.
For LAN or internet access, assess the exposure before changing a firewall or router. Configure the host firewall and any router or cloud firewall deliberately, restrict allowed source addresses where practical, and avoid sharing credentials in screenshots, chat, or stream descriptions. Networks differ, so there is no universal set of port-forwarding steps that makes every server reachable safely. If you do not need remote access, leave it local.
MediaMTX documents RTMPS using a TLS certificate and key, as well as RTMP authentication through credentials or tokens in URL query parameters. Check the current authentication documentation and RTMP-specific features before enabling either. Query parameters can appear in logs or copied URLs, so treat them as secrets. MediaMTX also notes a limitation around RTMPS support in major players; verify that your intended publishing and reading clients support the protocol before relying on it.
A server that is reachable beyond your computer should not be left as an anonymous open endpoint by accident. Authentication, encryption, firewall scope, and the intended clients all need to be considered together. A local-only learning test is a smaller problem than an internet-facing relay, and the simplest safe choice may be not to expose the service publicly at all. Local use does not require paid hosting; a VPS is only a possible later choice if you need a public endpoint that remains available independently of your home computer.
Keep the local setup separate from an always-on YouTube channel
MediaMTX is useful when you want to receive or relay an RTMP feed under your own control. That is different from uploading a finished video to a hosted service that publishes it to YouTube. In a self-hosted arrangement, your computer or a host you administer must stay available, the network path must remain usable, and you are responsible for the server’s configuration and access.
If your actual objective is to run an always-on prerecorded stream while your own computer is switched off, a local MediaMTX process does not meet that requirement by itself. StreamNeo turns an uploaded video into a 24/7 YouTube live stream, so the particular burden of leaving your own computer on to run that broadcast is removed. It is YouTube-only and is not a self-hosted RTMP server.
For a self-managed pipeline, keep the stages clear: OBS publishes to the receiving endpoint, the server accepts that input, and a reader or forwarding rule consumes it. For direct YouTube publishing, configure YouTube’s own live stream workflow and follow its current guidance for stream keys and ingest. If you are deciding whether an existing YouTube channel can sustain a continuous prerecorded programme, the discussion of YouTube revenue on continuous prerecorded livestreams is a separate question from setting up an RTMP receiver.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does MediaMTX work on Windows, Linux, and Mac?
MediaMTX’s official introduction lists Linux, Windows, and macOS compatibility. Download the artifact for the operating system and CPU architecture you actually have, then follow the current installation page rather than reusing a binary from another machine.
What should I enter in OBS for a local test?
Choose the custom stream service, set Server to rtmp://localhost/mystream, leave Stream key empty, save, and start streaming. Use the MediaMTX output to check whether the publisher connects; localhost only points to the same computer.
Do I need Docker or NGINX?
No. The standalone MediaMTX executable is sufficient for a basic local test. Docker is useful when your deployment already uses containers or needs a repeatable managed process, while NGINX is relevant if your design specifically calls for an NGINX-based stack.
Does this setup make my RTMP server public or stream to YouTube?
No. A local test is not public by default, and receiving a stream in MediaMTX does not automatically forward it to YouTube. Public access and forwarding require separate network and server configuration, which you should verify against current official documentation.