A free RTMP server usually means that you can use the server software without paying a software licence fee. It does not make a reachable computer, internet service, electricity, or the work of keeping a public service secure and running free.
For a documented starting point, this guide uses SRS with OBS: first test locally, then decide whether a home connection or rented host is appropriate. OBS sends a stream to SRS over RTMP; you can check receipt with a player such as VLC before deciding how viewers should consume the stream.
What “free RTMP server” really means
RTMP is a protocol often used to send a live feed from a broadcasting application to a media server. In this example, OBS is the publisher and SRS is the server that receives the feed. The server can then make the content available using an output protocol such as RTMP, HTTP-FLV, or HLS, depending on the SRS configuration. In other words, the protocol used to ingest a stream need not be the protocol used by a viewer.
SRS describes its project as free and MIT licensed, and its current README recommends Docker as a way to get started. Those are statements about the software, not a promise about performance, availability, or the total cost of a public service. Check the SRS project README and its getting-started documentation for current instructions and configuration details before copying commands.
A machine that accepts streams from only itself is useful for learning, but it is not automatically a public server. Remote access brings other requirements: a host that remains on, a route to it from the internet, suitable network capacity, and measures to restrict who can publish. For home hosting, router setup and a changing public IP may also be part of the job. For a rented host, the software may be free while the host and its network service are not.
This differs from simply installing OBS. The OBS Project explains that “There are no OBS servers - the connection goes directly from your computer to the streaming service.” That describes OBS sending directly to a streaming service, not running a self-hosted SRS or nginx-rtmp server in between. If your actual aim is a continuous YouTube broadcast without keeping your own computer running, that is a separate operating model from hosting an RTMP server; a comparison of 24/7 streaming apps for mobile-only creators may help you assess it.
Choose where the server will run
Choose the host based on who needs to reach the stream and who will maintain the machine. A local test is the simplest first step because OBS and SRS can communicate on the same computer without exposing the server to the internet. It proves that you can configure a publisher and receive its stream, but does not prove that a remote device or public audience can reach the server.
| Location | Useful for | What you take on |
|---|---|---|
| Local computer | Learning SRS and testing OBS-to-server ingest | It must remain on during the test; outside devices cannot reach it unless you configure network access. |
| Home server | A stream endpoint you control at home | Power, internet service, router forwarding, firewall rules, and possible dynamic DNS if your public IP changes. |
| Rented host | A public endpoint without maintaining a home machine | A hosting bill may apply; you remain responsible for SRS configuration, access controls, updates, and monitoring. |
A dedicated or rented host can make sense when a public endpoint is required and you do not want to maintain a home machine. The OBS community’s private-hosting guide identifies a dedicated server as a prerequisite for its workflow. Treat that as guidance for that example, not a universal requirement for every RTMP setup. Check the host’s current terms and network details before committing; do not assume a low-cost plan has the capacity or configuration you need.
For a home machine, a router may need to forward TCP port 1935 to the computer running SRS for the documented RTMP example. Opening a port is not the same as securing it, and the correct router steps vary by equipment and internet provider. Some home connections use an address that changes or do not permit inbound connections; check that your service allows the access you plan to use before making the server public.
If you will use a rented virtual machine, choose the operating system and installation route by checking SRS’s current documentation and the host’s supported image options. Do not select a machine solely because it is described as a VPS. This is media software that needs a reachable endpoint, and you still need to understand how to access, update, and administer the host. If your broader plan is a YouTube loop rather than a general RTMP endpoint, the considerations in how much RAM a VPS needs for an FFmpeg YouTube loop address a different workload and should not be read as a sizing guarantee for SRS.
Install SRS using its documented route
Use the project’s current README and linked getting-started guide as the installation authority. SRS recommends Docker in its README and provides a Docker example with ports. Before running anything, check the current tag, the documented configuration, and what each published port is for. The README describes SRS 8.0 while its example refers to an image tag such as srs:6; do not treat those labels as interchangeable release instructions.
The exact steps depend on your operating system and whether you already use Docker. Follow the documentation for the environment in front of you rather than mixing an old tutorial’s commands with current project instructions. The SRS getting-started guide is the place to check how the documented example is launched and how to inspect or adjust its configuration. If you are uncomfortable exposing a service or changing a host firewall, keep the first run local until you can verify each step.
Once SRS is running, note the RTMP application and port used by the example you followed. The local OBS example uses live as the application name and the default RTMP port in its address. An application name is a path component in the RTMP URL; it is not a separate programme to install. If you edit SRS configuration, use the configuration reference that matches the version you actually run, and restart or reload it only as the documentation instructs.
There are other ways to build an RTMP server. The OBS community resource titled “How to set up your own private RTMP server using nginx” shows the basic idea of an RTMP application listening on port 1935 and testing with OBS and VLC. It was published and last updated in 2014, so its sample nginx version and compile steps should not be copied as current installation advice. NGINX Plus, meanwhile, is a commercial product; F5 documents an RTMP module for that offering, but it is not the free-software path described here. The F5 NGINX module documentation is useful for understanding that distinction.
SRS suits this guide because its project documentation includes a Docker route as well as OBS and playback examples. That does not make it the right choice for every reader. If you want to assemble and maintain a customised nginx build, the older community tutorial may help explain the architecture, but you will need current nginx, module, and operating-system documentation for a real deployment.
Configure OBS for the server
With SRS running locally, open OBS’s stream settings and choose Custom as the service. For the documented local example, set the server to rtmp://localhost/live and the stream key to livestream. OBS combines those fields into the publishing address rtmp://localhost/live/livestream: the host is local, live is the application, and livestream is the key.
For a remote SRS host, replace localhost with the address or domain name that OBS can reach. Do not replace the application or key unless your SRS configuration expects different values. The SRS README gives OBS settings and an FFmpeg publishing example; use the project’s version-matched documentation if your configuration differs from the simple local example.
The stream key should be treated as a credential, not as a descriptive label. Use a strong, hard-to-guess value for any endpoint that can be reached by others, and restrict publishing access where the software and your network setup support it. A key written in a shared note, visible screenshot, or public post is no longer secret; change it if it has been exposed.
OBS encoding settings affect the stream sent to the server, but this guide is about server setup rather than choosing a YouTube profile. Avoid changing several encoding values while debugging whether the server receives anything. First test with a simple, stable OBS scene and settings appropriate for your connection; then troubleshoot source, key, and server reachability separately. For a YouTube-bound broadcast, consult the practical keyframe interval guidance for YouTube live streaming as a separate configuration question.
OBS is a publisher in this setup. Starting a stream in OBS sends data to the configured SRS address; it does not itself make the SRS host reachable, create a viewer page, or guarantee that a downstream platform will accept the stream. Confirm each link in the chain independently: OBS can publish, SRS can receive, and the chosen playback route can be opened by a test player or viewer.
Make the server reachable
For local testing, localhost resolves to the computer on which the program is running. Therefore, an OBS configuration using rtmp://localhost/live only works as written when OBS and SRS are on that same machine. If SRS runs on a different computer on your local network, use that computer’s reachable local address instead. A successful local-network test still does not prove that an off-site viewer can connect.
To receive an RTMP stream over the public internet at home, you may need to forward TCP port 1935 through the router to the SRS machine and allow the traffic in the machine’s firewall. Confirm the applicable port and configuration in the SRS documentation. The older nginx community guide also discusses port forwarding and dynamic DNS for home setups, but it is not a current SRS installation guide. If your home public address changes, a dynamic DNS name can help you keep a stable name pointing to it; it does not itself open a port or fix an inbound connection blocked by your provider.
On a rented host, use the host’s public address or a DNS name you have set up, and make sure the host firewall and any provider-level network rules allow only the traffic you intend to accept. A server address being public does not mean the service is correctly listening on that interface. Check SRS’s configuration and the host’s current network controls rather than assuming that a port is reachable because the software started.
Test network access from outside your home network when the intended audience is outside it. A phone using mobile data, for example, is a different path from a laptop on the same Wi-Fi. If that test fails, separate the questions: does SRS listen on the expected port, does the firewall allow it, does the router forward it, and does the internet provider permit inbound traffic? Avoid making several changes at once, which makes it harder to identify the cause.
Test ingest and playback
Start with the local example and confirm that OBS can start publishing without an address or authentication error. SRS’s documented local playback address is rtmp://localhost/live/livestream; open it in VLC on the same machine to confirm that the server is receiving and relaying the stream. If VLC cannot play it, check that OBS is sending to the same application and key used in the playback address, and that SRS is running with the configuration you expect.
For a remote test, make sure the publishing URL uses the server address that OBS can reach and the playback test uses an address reachable from the player. localhost in VLC refers to the player’s own device, not the remote SRS host. Use the host’s address or name in the playback URL when testing from another device, and verify that the relevant firewall and routing rules are in place.
SRS also documents HTTP-FLV and HLS output routes, along with WebRTC options in its getting-started material. These are alternative playback paths, not evidence that every protocol is enabled by default in every SRS configuration. Follow the current documentation for the route you choose, and verify that the required configuration is enabled before testing its URL. RTMP is the ingest route in this example; viewers can consume a separate output route if that better fits the player or distribution method.
Work from the simplest symptom to the next. If OBS cannot connect, inspect its server address, key, SRS state, and network path. If OBS connects but VLC does not show a picture, check the playback URL and whether that route is enabled. If local playback works but an off-site test fails, investigate reachability rather than changing the encoder first. This avoids treating every fault as a bitrate problem.
A successful VLC test proves only that the tested player can receive that stream through that route at that moment. It does not establish that the service will remain available overnight, that it can serve a large audience, or that YouTube will accept a stream sent to YouTube from your setup. If your end goal is a YouTube broadcast, test SRS-to-YouTube as a separate publishing leg using YouTube’s current requirements, and keep the local SRS-to-VLC check as its own diagnostic step.
Security and ongoing administration
A server exposed to the internet needs ongoing attention. Restrict publishing to trusted users and addresses where your chosen software supports that, use a non-guessable stream key, and do not share it with viewers. In the OBS private-hosting wiki’s example, the stream key is not private and the author uses an IP whitelist. That is a property of that example’s configuration, not a universal claim about all RTMP servers; check how your own SRS setup handles publishing access.
Keep the host operating system, Docker setup if used, and SRS image or installation current according to their respective documentation. Updating without checking what version you are using can lead to mismatched configuration or a changed image tag, so record your chosen version and read relevant release notes before changing it. Back up configuration files and keep a recovery path to the host before making remote changes to firewall or network settings.
For a home host, account for power and internet interruptions, router changes, and the possibility that your public address changes. For a rented host, account for billing, account access, provider network rules, and recovery if the instance needs attention. Neither route removes administration; it changes which parts you manage directly. If your primary goal is a pre-recorded YouTube stream that continues without your own computer operating, a self-managed RTMP server adds work that may not solve the problem you have. StreamNeo removes that specific burden by letting you upload a file and run a YouTube broadcast without keeping your computer on.
Do not promise yourself a fixed viewing experience from a local test. Network routes, player support, configuration, and the host all affect what happens in use. Begin with a private or otherwise controlled test, verify ingest and output from the intended network locations, and only then decide whether to make the endpoint available to others. Check YouTube’s current Help pages and any applicable platform settings for requirements on a YouTube-bound stream.
Decide whether self-hosting fits
A self-hosted RTMP server is useful when you specifically want to control the ingest endpoint, test media-server behaviour, or build a workflow in which a separate server receives OBS output. It is less attractive when the only need is to keep one prepared video live on YouTube around the clock and you do not want to manage a host, network path, keys, or updates. The question is not simply whether SRS costs nothing to download; it is whether the work and hosting fit your goal.
Before making a public endpoint, write down the complete path: where OBS runs, where SRS runs, how OBS reaches it, how the stream is checked, and how a viewer or YouTube receives the output. For each connection, note the address, port, credential, and which device initiates it. That small map is more useful during a late-night fault than relying on memory or a single successful test.
A concise trial plan is to run SRS locally using the current documented route, publish a basic OBS scene, and verify it with the documented VLC address. Then test the chosen remote path from outside the local network, if remote access is genuinely needed. If you cannot explain which component must be reachable and who will maintain it, keep the setup private until that is clear.
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
Is SRS actually free to use?
The SRS project describes the software as free and MIT licensed. That does not cover the cost of a rented host, a home internet service, power, or your time administering a public server. Check the current licence and project documentation before use.
Can I test an RTMP server without opening a router port?
Yes. Run SRS and OBS on the same computer and use the local example address with localhost; this tests ingest and playback on that machine. It does not make the service reachable from the internet or prove that a remote viewer can connect.
Does OBS provide the RTMP server?
No. OBS sends its output to a configured destination; it is not the server in this setup. Here, SRS receives the OBS stream, while a separate player or output route checks or distributes it.
Is port forwarding enough to make a home server safe and reachable?
No. Port forwarding can direct incoming traffic to a machine, but firewall rules, SRS configuration, access controls, and your provider’s network conditions also matter. Check the current documentation for your router, host, and SRS setup, and test from outside the home network.