Self-Hosted Streaming Server – NGINX + RTMP – YouTube + Facebook Live

Copying this here in case the original goes offline

Self-Hosted Streaming Server – NGINX + RTMP – YouTube + Facebook Live

Published by Anthony on 14th April 2020

I’m writing these notes up, mainly as a reference for me in the future – but they might just help others looking to do similar.


During the Coronavirus season, our church, like many, ventured into the world of streaming services, primarily to YouTube but with an eye to multiplexing to both YouTube and Facebook at the same time.

Initially, the plan was to stream from OBS Studio to an intermediate platform,

We tested with OBS sending the stream to restream and for the first week, everything worked fine.
Then, the second week about 10 minutes before due to go live suffered an outage. Fortunately, we were quickly able to flip to sending our stream directly to YouTube and our broadcast worked successfully.
However, for me, an issue with a shared service leaves a sour taste and so began the journey to discover what would be involved in running our own RTMP server.

It turns out the solution has been relatively straightforward…

Our solution:

Firstly, we signed up for a new VPS with
We opted for a 1 x vCPU, 2GB RAM, High-Frequency machine with 64GB SSD storage, and 2TB monthly bandwidth. Research suggested that RTMP streaming/multiplexing is not particularly CPU/RAM intensive and is more about bandwidth consumption.

Once the VPS was provisioned, we selected the Ubuntu 18.04 LTS install image. The machine was duly created and connected via SSH to its IP shown in the portal.

Basic Installation:

Update all packages:

root@hostname#    sudo apt-get update
root@hostname#   sudo apt-get upgrade

Then install NGINX:

sudo apt-get install nginx
sudo apt install libnginx-mod-rtmp

At this point you can test that NGINX has been installed correctly by testing with your browser:


If successful, you should see the NGINX default page:

Configuration for YouTube

Now, on to adding the RTMP config.

Edit the nginx.conf file as follows:

nano /etc/nginx/nginx.conf

Add a section at the bottom of the file as follows:

rtmp {
     server {
             listen 1935;
             chunk_size 4096;

             application live { 
                        live on; 
                        record off; 
                        # Edit and enable line below to push incoming stream to YouTube 
                        # push rtmp://<your-Stream-Key-Copied-From-YouTube>; 

If you aren’t familiar with YouTube Live stream settings the key can be obtained from the following screens:

Save the nginx.conf file (Ctrl +X ) and start the NGINX service

root@hostname# systemctl restart nginx

Best practice would suggest installing a firewall package on your VPS to minimise its exposure to the Internet.

For Ubuntu 18.04, UFW is perfectly acceptable and well documented. Vultr have a comprehensive document at

For me, I created 4 simple rules permitting inbound SSH from my home ISP’s fixed IP, and a friend’s IP plus equivalent rules permitting inbound TCP1935 from each of our addresses.

We chose to use OBS to create the stream footage, therefore we had to fill in the stream details within OBS Stream settings:

If you then click on Start Streaming within OBS, your OBS content should start appearing within your YouTube Studio account (albeit with a 30second delay).

Facebook Live

Facebook made some changes a little while back to only accepts RTMPS streams which NGINX and the RTMP can’t natively support. So, another jigsaw piece needs to be added to the puzzle. Enter stunnel!

Edit your nginx.conf file to include a new push statement.

push rtmp://<Facebook-persistent-stream-key>

restart nginx

systemctl restart nginx

Install Stunnel

apt-get install stunnel4 -y

Edit the stunnel boot configuration as follows (change ENABLE from 0 to 1)

nano /etc/default/stunnel4

Edit the stunnel config as follows:

nano /etc/stunnel/stunnel.conf
pid = /var/run/stunnel4/
output = /var/log/stunnel4/stunnel.log

setuid = stunnel4
setgid = stunnel4

socket = r:TCP_NODELAY=1
socket = l:TCP_NODELAY=1

debug = 4


client = yes accept = 1936 connect = verifyChain = no

Enable Stunnel and start it

systemctl enable stunnel4.service
systemctl restart stunnel4.service

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.