# Oryx: an all-in-one open source video stack for live streaming and WebRTC

> Oryx, formerly SRS Stack, packages SRS, FFmpeg, React, Go, Redis and a set of management tools into one container that serves RTMP, WebRTC, HLS, HTTP-FLV and SRT with recording, transcoding, virtual live and automatic HTTPS. It is a product assembled from proven parts rather than a new media engine, and the documentation is unusually candid about the ports and volumes you have to think about.

**ossrs/oryx** — Oryx (SRS Stack) is an AI-driven, all-in-one, out-of-the-box, and open-source video solution for creating online video services, including live streaming and WebRTC, in the cloud or through self-hosting.

- Repository: https://github.com/ossrs/oryx
- Website: https://ossrs.io/oryx
- Stars: 891 · Forks: 159
- Language: Go
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/ossrs-oryx

## The problem: a video service assembled from parts that do not talk

Standing up a live streaming service means combining an ingest server, a transcoding pipeline, a web player, a console, a cache, a recorder and a certificate workflow, and making them agree on ports, paths, secrets and file layout. Each of those pieces exists and works. The work is in the assembly, and the assembly is the part that differs between every deployment.

Oryx is that assembly, packaged. The project description calls it an all-in-one, out-of-the-box, open-source video solution for creating online video services, including live streaming and WebRTC, in the cloud or through self-hosting. It is built using Go, Reactjs, SRS, FFmpeg and WebRTC, with Redis included, and it integrates OpenAI services.

The audience is a team that needs a working video service rather than a video engine. If you are building a platform with a custom ingest pipeline, an unusual transcoding topology or a protocol SRS does not speak, this is the wrong layer. If you need RTMP ingest, WebRTC playout, HLS delivery, recording to disk, automatic certificates and a management console this afternoon, it is exactly the right layer.

One piece of the story is worth knowing because it explains the naming. The project was renamed from SRS Stack to Oryx, and the reason given is that a new name was needed for AI assistants to identify, because they were confused between SRS and SRS Stack. That is a small thing and a revealing one: the name change is aimed at the tools that read the code, not at the users who run it.

The licence is MIT, the homepage is ossrs.io/oryx, and the last push was on 2026-10-18.

## The components and the protocols they cover

The stack table in the project description is short and it defines what the product is.

SRS is the media server at the centre, and the documentation notes that for the SRS server the build always uses the latest release version, taken from the ossrs/srs image rather than built from source in the container. FFmpeg handles the transcoding side, React.js is the front end, and Go is the language of the platform and management code. Redis is included, and the data layout in the repository has a dedicated redis directory that holds the publish secret and the record configuration, which tells you that Redis is where the runtime secrets and the recording settings live rather than being an optional cache.

On the protocol side, Oryx supports RTMP for publishing, WebRTC for browser-native playout, HLS and HTTP-FLV for delivery, and SRT for contribution over UDP. The repository topics list hls, media-server, rtmp, srt and whip, and WHIP is the WebRTC ingest path that the documentation calls out separately, with a warning that to use WebRTC WHIP in a browser you should avoid localhost and 127.0.0.1 and use a private IP, a public IP or a domain instead, because the browser needs a real address to establish the session.

The feature list covers the operations that make a streaming service usable rather than merely functional: authentication, streaming on multiple platforms, recording, transcoding, virtual live events, automatic HTTPS and an easy to use HTTP Open API. Virtual live in particular is the one that changes what a platform can offer, since it turns stored video into a scheduled live channel.

The project is also careful to distinguish what it is from what it is not, and that distinction runs through the documentation: the FAQ pages, the tutorials and the developer document are all part of the product, not an afterthought.

## Running it: one container and five listening ports

The quick start is a single command. You run Oryx in one Docker container and then open it in a browser:

```bash
docker run --restart always -d -it --name oryx -v $HOME/data:/data \
  -p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
  ossrs/oryx:5
```

The port list is worth reading on its own, because it is the deployment contract. 80/tcp is the HTTP port, and you can use 2022 instead, for instance with -p 2022:2022. 443/tcp is the HTTPS port, with 2443 as the alternative. 1935/tcp is the RTMP port, for publishing to Oryx. 8000/udp is the WebRTC UDP port, which transports the WebRTC media data such as RTP packets. 10080/udp is the SRT UDP port, for publishing over SRT.

The volume mount is not optional. The documentation is emphatic that you must mount the /data volume to avoid losing data when the container restarts, and that if you mount /data to $HOME/data then all the data is stored in the $HOME/data folder, which you should modify to your desired directory. Restart always is set, so the container comes back on reboot, and without the volume it comes back empty.

Two environment details also matter. The MGMT_PASSWORD is the management administrator password, and it is also saved in /data/config/.env so you can modify it by hand. The REACT_APP_LOCALE is the internationalisation setting for the interface, en or zh, defaulting to en. The DEVELOPER.md document has an Environments section listing the rest.

And a note for readers in China, where the documentation suggests using the registry.cn-hangzhou.aliyuncs.com/ossrs/oryx:5 image to speed up the Docker pull.

## The /data layout, which is really the configuration of the whole service

The directory listing under /data is the clearest description of what the platform does, because each subdirectory is a feature.

The config directory holds the .env with the password, plus the srs, redis, nginx and prometheus configuration and the SSL files, which is where the monitoring configuration and the certificate files live. The .well-known and lego directories are for the Let's Encrypt ACME challenge, and the fact that there is a separate lego directory is a direct consequence of the automatic HTTPS feature: the certificate is issued by the Lego client, and the challenge files have to be served from a predictable path.

The media directories divide by purpose rather than by format. dvr stores the digital video recorder files, record stores the recording files, upload stores uploaded files, vlive stores the virtual live video, transcript stores transcription output, and signals stores the signal files. The srs-s3-bucket directory is the mount point for AWS S3 compatible storage, and nginx-cache holds the reverse proxy cache.

The division matters operationally. A deployment that records a lot of video needs to think about where dvr, record and vlive grow, and the fact that the S3 bucket is mounted inside the same tree means the object store and the local disk are two halves of the same storage design rather than independent systems.

The transcription directory is worth a second look given the OpenAI integration: it is the local landing place for transcription output, which means an organisation with a data protection policy has a directory of model-generated text to consider.

## Certificates, the management password and the cost of the support model

Three operational details deserve a mention before a deployment rather than after one.

The first is automatic HTTPS. The documentation links a post about securing SRS with Let's Encrypt by one click, and the Docker image includes the goacme/lego stage, so certificate issuance and renewal are part of the image rather than something you bolt on. The trade is that the certificate workflow needs a public address and a domain, and it needs the ACME challenge to be reachable, which is why the volume reserves .well-known and the WebRTC section warns against localhost.

The second is the management password. It is set through an environment variable and then persisted into the config directory so that it survives a restart, which is convenient and also means it lives on disk in a directory that has to be protected like any other secret.

The third is support. The project runs an OpenCollective with a backer tier at five dollars a month for online text chat support through Discord, and a sponsor tier at a hundred dollars a month for an online meeting, one meeting per month for an hour. The stated aim is to establish a non-profit, open-source community that assists developers worldwide in creating their own high-quality streaming and RTC platforms. So the commercial relationship is with a small vendor that wants the community to exist, and the price of a bug fix conversation is a recurring donation rather than a contract.

For an organisation, that is a reasonable arrangement and it is also a risk to price in: the platform is free and MIT licensed, but the people who can answer your question about it are funded by supporters.

## Building from source: the multi-stage image and the make targets

The Dockerfile is where the build strategy becomes visible, and it is a good example of assembling a product from prebuilt pieces.

The base images are pulled in by architecture with an ARCH argument: node:22-bookworm-slim for the user interface build, golang:1.25-bookworm for the Go toolchain, ossrs/srs:7 for the media server, ossrs/srs:ubuntu20 for tools, goacme/lego for certificates and ubuntu:jammy as the build stage. A python:3.11-slim-bookworm stage exists for youtube-dl, referenced to the ytdl nightly project.

The build stage copies the Go toolchain and the Node binaries in, installs the compiler toolchain, and then adds the release, mgmt, platform, ui, usr and test trees plus the Makefile. The Node options are set with an explicit comment about the JavaScript heap running out of memory, which tells you the UI build is memory hungry. The build runs make clean, then make with a parallelism argument, then make install, with the lint check disabled through SRS_NO_LINT=1, and the comment explains why: by default make builds the platform and the UI, which takes a long time, and MAKEARGS exists so you can build without the UI.

The Makefile mirrors that structure with build, build-no-ui, install, run, uninstall, upgrade, test and clean targets, and an install prefix of /usr/local/oryx. The install target copies the management bootstrap, the built UI, the platform binaries and the platform container definitions, and the data directories, and it rewrites the systemd unit file to point at the configured prefix, which is how the platform is installed as a service on a normal Linux host rather than only as a container.

The test target runs go test in the platform, releases and test trees, with the API secret check disabled for the system test, and then runs the UI tests, so the checks span the Go services and the front end.

## The version jump, the licence and where Oryx is the wrong tool

The release history needs reading carefully. The most recent release is v7.15.26 on 2026-09-14, and the releases before it are v5.15.20 from 2024-07-22 and v5.15.15 from 2024-07-10. So the project moved from a 5.x series to a 7.x series, and the quick start command in the documentation still pulls the tag ossrs/oryx:5.

That gap is the single most important operational fact for anyone deploying this. The 5.x line was the SRS Stack era and the 7.x line is the current Oryx, and the image tag in the documentation is from the older line. Anyone who copies the quick start verbatim gets the previous major version rather than the current one, and the difference between a 5.x and a 7.x deployment is exactly the kind of thing that eats an afternoon.

The licence is MIT, with a LICENSE file at the root, and the repository also carries a SECURITY.md and a CONTRIBUTING.md. The code is yours to modify and to embed in a commercial product, which matters for a platform that is often deployed as part of somebody else's product.

Where Oryx is the wrong tool is straightforward. If you need only an RTMP ingest point, this is a platform with a browser console, a Redis instance, five listening ports and a stateful data directory, and SRS on its own would be a fraction of that. If your deployment has to run on a platform without Docker, the Makefile supports an install, but the operational path is clearly designed around the container. And if you need protocol support outside RTMP, WebRTC, HLS, HTTP-FLV and SRT, there is no extension point described in the documentation.

The judgement, in short: Oryx is a well assembled, permissively licensed product for people who want a complete streaming service rather than a component, and the one thing to verify before deploying is which major version the image tag actually points at.

## Conclusion

Adopt Oryx if you need a working live streaming and WebRTC service this week and would rather assemble SRS, FFmpeg, Redis, a web console and a certificate workflow than wire them together yourself. Do not adopt it if you need a small, focused RTMP ingester, since this is a full platform with five listening ports and a stateful data directory. Before you deploy it, read the port list and the volume layout, decide how you will terminate TLS and protect the management password, and check which version line you are on, because the project moved from a 5.x series to a 7.x series and the image tag in the documentation still shows the older major version.

## FAQ

### How do I start Oryx with Docker?

Run the container with the documented command, mapping the HTTP, HTTPS, RTMP, WebRTC UDP and SRT UDP ports and mounting a host directory to /data so the data survives a restart, then open http://localhost in a browser. The documentation stresses that the /data volume must be mounted, and that you should change $HOME/data to the directory you want.

### Which ports does Oryx use?

80/tcp for HTTP, with 2022 as an alternative, 443/tcp for HTTPS, with 2443 as an alternative, 1935/tcp for RTMP publishing, 8000/udp for WebRTC media such as RTP packets, and 10080/udp for publishing over SRT.

### What is stored in the Oryx /data directory?

The .well-known and lego directories for the Let's Encrypt ACME challenge, config for the .env with the password and the srs, redis, nginx and prometheus configuration and the SSL files, dvr, record, upload, vlive, transcript and signals for the different kinds of stored files, redis for the publish secret and record configuration, nginx-cache for the proxy cache, and srs-s3-bucket as the mount point for AWS S3 compatible storage.

### Why was SRS Stack renamed to Oryx?

The project states that a new name was needed for AI assistants to identify, because AI assistants were confused between SRS and SRS Stack. The rename is about the code being distinguishable to tools, not a change of product direction.

### What licence is Oryx released under, and how is it supported?

MIT, with a LICENSE file at the root of the repository. Support runs through an OpenCollective with a backer tier at five dollars a month for text chat support and a sponsor tier at a hundred dollars a month for a monthly online meeting.

## Sources

- [License: MIT](https://github.com/ossrs/oryx/blob/main/LICENSE)
- [ossrs/oryx on GitHub](https://github.com/ossrs/oryx)
- [Project website](https://ossrs.io/oryx)
- [README](https://github.com/ossrs/oryx/blob/main/README.md)
- [Releases](https://github.com/ossrs/oryx/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ossrs-oryx