Red5 Open Source Media Server on AWS 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-instance 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 instance, 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-instance 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 instance) - 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 garbage collector and heap for the instance size
• An unauthenticated /healthz endpoint for load balancer health probes
• red5.service + nginx.service as systemd units, enabled and active
• 24/7 cloudimg support

Prerequisites

An active AWS account, an EC2 key pair, and a VPC subnet in the target region. An m5.large (2 vCPU / 8 GiB RAM) is a comfortable starting point; scale up for higher concurrency. In the instance security group allow 22/tcp from your management network for SSH, 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 - Launch from the AWS Marketplace

Find the Red5 Open Source Media Server listing by cloudimg in the AWS Marketplace and choose Continue to Subscribe, then Continue to Configuration and Continue to Launch. Pick the Ubuntu 24.04 version, your region and an instance type (m5.large or larger). Under EC2 Instance Type and Security Group Settings, select or create a security group that opens 22, 80, 1935 and 8443, choose your key pair, and launch. You can also launch the same AMI from the EC2 console with Launch instance from AMI.

Step 2 - Connect to your instance

Connect over SSH using the login user for your image variant and the private key for the EC2 key pair you launched with:

ssh -i your-key.pem ubuntu@<instance-public-ip>

Step 3 - 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-instance 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 4 - 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 instance 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_ADMIN_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 5 - 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 a load balancer health probe.

Step 6 - 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-instance 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-instance password because Red5 itself is bound to loopback and nginx is the only way in.

Step 7 - Publish a live stream

Red5's core job is live streaming. Point any RTMP encoder at rtmp://<instance-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://<instance-public-ip>:1935/live/teststream

# Confirm the live stream is being served by Red5:
ffprobe rtmp://<instance-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://<instance-public-ip>:1935/live and Stream Key to your stream name to publish the same way. Use the rtmps://<instance-public-ip>:8443/live/<stream-name> URL for encrypted RTMPS.

Step 8 - Sign in to the Red5 web interface

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

Step 9 - 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 10 - Review the full demos catalog

Scrolling the demos catalog reveals the rest of the sample applications: the Publisher (publish, record and view videos), the Simple Recorder (record an incoming stream to an FLV file), the Admin Panel and an Echo test, plus links to the Red5 example source repositories on GitHub. 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 instance 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.