SRS

Videos

Overview: SRS Streaming Media Server on Ubuntu 24.04 on Azure: overview (watch on YouTube)

Launch and log in: SRS Streaming Media Server on Ubuntu 24.04 on Azure: launch and log in (watch on YouTube)

Deep Dive: SRS Streaming Media Server on Ubuntu 24.04 on Azure: deep dive (watch on YouTube)

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a reasonable starting size for a handful of concurrent streams. Choose a larger size for more publishers or viewers.

A public IP is required for WebRTC media to reach remote browsers. Azure assigns a new public IP on a full VM stop (deallocate) and start unless you attach a Static Public IP SKU. Use a static IP for any production WebRTC deployment.

Configure these NSG inbound rules:

• 22/tcp from your management network (SSH)
• 80/tcp for the web console, test players and JSON API (behind Basic Auth), and 443/tcp if you add your own TLS front end
• 1935/tcp for RTMP ingest (required to publish a stream)
• 8000/udp for WebRTC media (required for WebRTC publish and play to connect)

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for SRS by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Review the dedicated data disk on the Disks tab, then select Review + create and Create. After creation, add inbound NSG rules for TCP 1935 and UDP 8000 (see Step 3) so publishing and WebRTC media can flow.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:srs-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name srs \
  --image sac1647283583153:srs-ubuntu-24-04:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name srs --port 80 --priority 1010

Step 3 - Open the RTMP and WebRTC media ports (required)

RTMP ingest and WebRTC media cannot be proxied through nginx, so both must be reachable directly. Add the NSG rules with the Azure CLI:

az network nsg rule create \
  --resource-group <your-rg> \
  --nsg-name <your-nsg> \
  --name Allow-SRS-RTMP \
  --priority 1020 \
  --direction Inbound --access Allow --protocol Tcp \
  --destination-port-ranges 1935 \
  --source-address-prefixes '*'
az network nsg rule create \
  --resource-group <your-rg> \
  --nsg-name <your-nsg> \
  --name Allow-SRS-WebRTC \
  --priority 1030 \
  --direction Inbound --access Allow --protocol Udp \
  --destination-port-ranges 8000 \
  --source-address-prefixes '*'

Without these rules the web console still loads over port 80, but you cannot publish a stream over RTMP or connect WebRTC media.

Step 4 - Connect to your VM

Connect over SSH as the administrator user:

ssh azureuser@<vm-public-ip>

Step 5 - Confirm the services and listening ports

systemctl is-active docker.service srs.service nginx.service srs-firstboot.service
sudo docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

All four services report active, and the container shows Up. SRS runs with host networking, so RTMP (:1935), the HTTP API (:1985), the web console (:8080) and the WebRTC media port (UDP :8000) all bind directly on the VM.

Step 6 - Confirm the WebRTC candidate IP

WebRTC needs a routable address for its ICE candidate. On first boot the appliance detects this VM's public IP and writes it into the running SRS configuration. Check the value:

sudo sed -n '/rtc_server/,/^}/p' /etc/srs/srs.conf

The candidate value must equal your VM's public IP address exactly. If it does not, WebRTC publish and play fail to connect even though RTMP and the console work fine.

If you later reassign the VM's public IP or attach a Static Public IP SKU, re-run first boot so the new address is written in: sudo rm -f /var/lib/sac/data/srs-firstboot.done && sudo systemctl restart srs-firstboot.service.

Step 7 - Confirm the health endpoint and Basic Auth

nginx serves an unauthenticated health endpoint for load balancers and probes. It protects everything else with per-VM HTTP Basic Authentication. Check both:

curl -s http://localhost/healthz
curl -s -o /dev/null -w '%{http_code}\n' http://localhost/

/healthz returns ok with no credentials. A bare request to / returns HTTP 401 until you supply the per-VM admin password from Step 8. A wrong password also returns 401.

Step 8 - Retrieve your console password

The SRS console password is generated uniquely on the first boot of your VM and written to a root-only file. Read it with sudo:

sudo cat /root/srs-credentials.txt

The file contains SRS_ADMIN_USER (always admin), SRS_ADMIN_PASSWORD, the console URL and a ready-made RTMP publish URL. It is mode 0600 and owned by root, so only an administrator can read it. Store the password somewhere safe.

Step 9 - Sign in to the web console

Browse to http://<vm-public-ip>/. At the browser's Basic Auth prompt, enter the username admin and the password from Step 8.

The console home page confirms that SRS is working and links to the built-in test players.

Step 10 - Publish a test stream over RTMP

From any remote machine with ffmpeg installed, you can publish a live stream over the internet. OBS Studio works too: point it at rtmp://<vm-public-ip>:1935/live with stream key livestream. The NSG rule from Step 3 makes this possible.

To prove ingest works without leaving your SSH session, publish a short test pattern from the VM itself over loopback:

ffmpeg -re -f lavfi -i "testsrc=size=1280x720:rate=30" -f lavfi -i "sine=frequency=1000" \
  -t 20 -c:v libx264 -preset veryfast -c:a aac -f flv \
  rtmp://127.0.0.1:1935/live/livestream & sleep 4

Confirm that the stream is live in the authenticated HTTP API. Substitute your own password for <SRS_ADMIN_PASSWORD>:

curl -s -u "admin:<SRS_ADMIN_PASSWORD>" http://127.0.0.1/api/v1/streams/ | python3 -m json.tool

The response lists your stream by name with "publish": {"active": true} and the video and audio codec details SRS negotiated. This confirms the pipeline works end to end, from RTMP ingest to the HTTP API.

The same check works for a remote publisher. Replace 127.0.0.1 with the VM's public IP once you publish from outside the VM.

Step 11 - Watch the stream in the built-in test player

Browse to http://<vm-public-ip>/players/srs_player.html. Enter the HLS URL for your stream (http://<vm-public-ip>/live/livestream.m3u8) and select Play.

SRS automatically generates HLS segments from any published RTMP stream, so the stream you published in Step 10 is watchable within a few seconds.

Step 12 - Inspect the live streams and clients list

The authenticated /api/v1/streams/ endpoint from Step 10 also lists SRS's streams and clients. Open it in a browser and enter the Basic Auth credentials from Step 8.

http://<vm-public-ip>/api/v1/streams/

Step 13 - Confirm the server version through the API

Open this URL in a browser to read the SRS server version:

http://<vm-public-ip>/api/v1/versions

Step 14 - Confirm data lives on the dedicated disk

Live HLS segment output is stored under /var/lib/srs on the dedicated Azure data disk. The disk is separate from the OS disk and can be resized independently. Confirm the mount:

findmnt /var/lib/srs

This mount is backed by a separate Azure data disk that is captured into the image and re-provisioned on every VM.

Maintenance

• Console password. The console password is set on first boot and stored in /root/srs-credentials.txt. To rotate it, run sudo htpasswd -bc /etc/nginx/.srs_htpasswd admin '<new-password>' and then sudo systemctl reload nginx.
• WebRTC candidate and public IP. WebRTC media needs the VM's public IP in /etc/srs/srs.conf and UDP 8000 reachable. If you reassign the public IP, clear the first-boot marker and restart the first-boot service so the new address is detected: sudo rm -f /var/lib/sac/data/srs-firstboot.done && sudo systemctl restart srs-firstboot.service.
• Your own domain and TLS. The appliance serves plain HTTP on port 80. For production, put your own domain and a trusted certificate (for example from certbot and Let's Encrypt) in front of nginx at /etc/nginx/sites-available/sac-srs, then reload nginx.
• Configuration. All SRS settings live in /etc/srs/srs.conf. See the SRS documentation for the full reference. After any change, restart the container with sudo systemctl restart srs.service.
• Storage. Live HLS segment output lives under /var/lib/srs on the data disk.
• Security patches. Unattended upgrades stay enabled, so the OS continues to receive security updates automatically.

Licensing

SRS (Simple Realtime Server) is distributed under the MIT license, a permissive license with no source-disclosure obligation. SecureAnyCloud ships the pinned upstream ossrs/srs:v6.0-r0 Docker image unmodified, together with appliance packaging: systemd units, the nginx front end and the first-boot configuration.

Support

SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com.

Deploy on Azure

Launch SRS Streaming Media Server on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com