Red5 Open Source Media Server on Ubuntu 24.04 on Azure User Guide

Overview

Red5 is an open source media server for real time live streaming. It ingests live audio and video over RTMP and RTMPS from encoders such as OBS Studio, FFmpeg and hardware broadcasters, relays it to viewers, and can record incoming streams for later playback. Red5 2.0.40 runs on an embedded Apache Tomcat 11 servlet container and ships a browser landing page plus a catalog of demo applications (live broadcast, video on demand, chat, bandwidth checking and more). The cloudimg image installs the pinned Red5 2.0.40 release running under systemd as the red5 service, then locks it down for a marketplace appliance: Red5's HTTP interface is bound to loopback 127.0.0.1:5080 so it is never exposed directly, and an nginx reverse proxy on port 80 adds a per-VM HTTP Basic Auth gate in front of it. Red5's bundled default demo and JMX credentials are removed at build time, and a unique administrator password is generated on the first boot of your VM, so no shared or baked credential ever ships. The RTMP (1935) and RTMPS (8443) media ports are served directly by Red5 for stream ingest and playback. Backed by 24/7 cloudimg support.

What is included:

• Red5 Open Source Media Server 2.0.40 installed from the official release and running as the red5 systemd service
• Red5's HTTP web interface fronted by nginx on port 80, with Red5 itself bound to loopback 127.0.0.1:5080
• Per-VM HTTP Basic Auth (user admin) protecting the web interface, with a unique password generated on first boot
• All bundled default credentials removed (tomcat-users.xml emptied, realm.properties and the JMX password rotated per VM) - no known credential ships
• RTMP on 1935 and RTMPS on 8443 for live stream ingest and playback, with a self-signed keystore generated at build so RTMPS starts cleanly
• Java 21 (OpenJDK headless) with Red5 auto-tuning its GC and heap for the VM size
• An unauthenticated /healthz endpoint for Azure Load Balancer health probes
• red5.service + nginx.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting point; scale up for higher concurrency. NSG inbound: allow 22/tcp from your management network, 80/tcp for the web interface, 1935/tcp for RTMP ingest and playback, and 8443/tcp for RTMPS. Red5 serves the web interface over plain HTTP on port 80; for production, terminate TLS in front of it with your own domain, and restrict the media ports to your encoders and viewers (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Red5 by cloudimg, and select Create. On Basics 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) (add 1935 and 8443 afterwards for streaming). Then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name red5 \
  --image <marketplace-image-urn> \
  --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 red5 --port 80   --priority 1010
az vm open-port --resource-group <your-rg> --name red5 --port 1935 --priority 1020
az vm open-port --resource-group <your-rg> --name red5 --port 8443 --priority 1030

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

systemctl is-active red5.service nginx.service

Both report active. Red5 serves its web interface on the loopback address 127.0.0.1:5080; nginx fronts it on port 80 and adds the per-VM HTTP Basic Auth gate. The RTMP and RTMPS media ports are served directly by Red5. You can see the listening sockets with:

ss -tln | grep -E ':(80|1935|5080|8443)'

Port 80 (nginx) and 1935 / 8443 (Red5 media) listen on all interfaces, while the Red5 HTTP interface on 5080 listens on loopback only, so it is reachable only through the authenticated nginx proxy.

Step 5 - Retrieve your web UI password

nginx protects the Red5 web interface with HTTP Basic Auth. The username is admin and a unique password is generated on the first boot of your VM and written to a root-only file:

sudo cat /root/red5-server-credentials.txt

This file contains RED5_ADMIN_USER, RED5_ADMIN_PASSWORD and the RED5_URL to open in a browser, along with the RTMP and RTMPS publish URLs. The password is stored on disk only as a bcrypt hash in /etc/nginx/.red5.htpasswd, so no plaintext password ships in the image. The bundled Red5 default credentials (admin/admin, tomcat/tomcat and the JMX red5user account) are removed at build time. Store the password somewhere safe.

Step 6 - Confirm the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes:

curl -s http://localhost/healthz

It returns ok. This endpoint never requires authentication, so it is safe for an Azure Load Balancer health probe.

Step 7 - Confirm authentication and reach the web interface

Because a password is set on first boot, an unauthenticated request to the web interface returns HTTP 401, so nobody reaches Red5 without the password. The following reads the per-VM password from the credentials file and proves the round-trip - unauthenticated is rejected, a wrong password is rejected, and the correct password returns the Red5 landing page:

PW=$(sudo grep '^RED5_ADMIN_PASSWORD=' /root/red5-server-credentials.txt | cut -d= -f2-)
echo "healthz : $(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1/healthz)"
echo "unauth  : $(curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1/)"
echo "wrongpw : $(curl -s -o /dev/null -w '%{http_code}' -u admin:wrong-pw http://127.0.0.1/)"
echo "authed  : $(curl -s -o /dev/null -w '%{http_code}' -u admin:$PW http://127.0.0.1/)"

It prints healthz : 200, unauth : 401, wrongpw : 401 and authed : 200. The whole web interface is only reachable with the per-VM password because Red5 itself is bound to loopback and nginx is the only way in.

Step 8 - Publish a live stream

Red5's core job is live streaming. Point any RTMP encoder at rtmp://<vm-public-ip>:1935/live/<stream-name> to publish, and clients pull the same URL to play. For example, with FFmpeg publishing a test pattern and ffprobe pulling it back to confirm Red5 ingested and relays it:

# On any machine with FFmpeg (the appliance itself does not ship FFmpeg):
ffmpeg -re -f lavfi -i testsrc=size=640x360:rate=25 -f lavfi -i sine=frequency=1000 \
  -c:v libx264 -preset ultrafast -tune zerolatency -c:a aac -f flv \
  rtmp://<vm-public-ip>:1935/live/teststream

# Confirm the live stream is being served by Red5:
ffprobe rtmp://<vm-public-ip>:1935/live/teststream

ffprobe reports the live h264 video and aac audio streams flowing through Red5, confirming end to end ingest and playback. In OBS Studio, set Server to rtmp://<vm-public-ip>:1935/live and Stream Key to your stream name to publish the same way. Use the rtmps://<vm-public-ip>:8443/live/<stream-name> URL for encrypted RTMPS.

Step 9 - Sign in to the Red5 web interface

Browse to http://<vm-public-ip>/. Your browser prompts for a username and password: enter admin and the password from Step 5. Red5 opens on its landing page, which confirms the server is installed and running correctly and links through to the bundled demo applications.

Step 10 - Explore the demo applications

From the landing page, open the Demos page. Red5 ships a catalog of sample applications that exercise its features - Shared Ball (shared objects), the OFLA video player, a Publisher, Bandwidth Detection and a Simple Chat - each with a short description. These demonstrate the streaming and shared object capabilities you build on with your own applications.

Step 11 - Review the broadcast and subscribe demos

Scrolling the demos catalog reveals the live media samples: the Publisher (publish, record and view videos), a Simple Chat, and a Simple Broadcaster and Simple Subscriber pair that show the basic publish and play flow over RTMP. These map directly onto the rtmp://<vm-public-ip>:1935/live/<stream> publish and play URLs from Step 8.

Step 12 - Review the recorder and conferencing demos

Further down the catalog are the Simple Recorder (record an incoming stream to an FLV file), a Video Conference sample and an Echo test, plus links to the Red5 example source repositories. Use these as starting points when writing your own streaming applications against the Red5 API.

Maintenance

• Password: the web UI password is set on first boot and stored as a bcrypt entry in /etc/nginx/.red5.htpasswd. To change it, run sudo htpasswd -B /etc/nginx/.red5.htpasswd admin and then sudo systemctl reload nginx.
• Loopback binding: Red5's HTTP interface is bound to 127.0.0.1:5080 (http.host=127.0.0.1 in /opt/red5/conf/red5.properties), so nginx is the only path into the web interface. Keep it that way - do not change the host to a public interface.
• Restrict the media ports: RTMP (1935) and RTMPS (8443) are served directly by Red5. Restrict them to your encoders and viewers in the Network Security Group, and add application-level stream authentication in your Red5 application for production use.
• TLS: the web interface serves plain HTTP on port 80. For production, front it with TLS (for example certbot with your own domain) terminating on :443, and use the RTMPS URL for encrypted ingest.
• Configuration: Red5's server configuration lives in /opt/red5/conf (red5.properties for ports, red5.xml and red5-core.xml for the server context). Restart with sudo systemctl restart red5 after changes.
• Your applications: deploy your own Red5 web applications under /opt/red5/webapps/<app>; the live and vod applications are provided out of the box for RTMP ingest and video on demand.
• Logs: Red5 logs to the journal (sudo journalctl -u red5 -f) and to /opt/red5/log.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.