SRS

Self-hosted real-time video infrastructure, honestly reviewed. Built by engineers, for engineers — and increasingly approachable for founders who want off the SaaS video bill.

TL;DR

• What it is: Open-source (MIT) real-time media server written in C/C++, handling RTMP, WebRTC, HLS, HTTP-FLV, SRT, MPEG-DASH, and GB28181 from a single binary [README][2].
• Who it’s for: Developers and technical founders who need a self-hosted video infrastructure backbone — live streaming, video conferencing, protocol conversion, or any scenario where paying per-minute to a commercial streaming service starts to hurt [2].
• Cost savings: Commercial alternatives like Wowza Streaming Engine start at roughly $95/month. Mux and AWS IVS charge per streaming minute. SRS on a $10–20/month VPS handles the same workload for the cost of the server.
• Key strength: Single-binary deployment that speaks RTMP, WebRTC, HLS, and SRT simultaneously, with seamless protocol conversion between them — without re-encoding [2]. Plus 28,646 GitHub stars and an active community backing it.
• Key weakness: This is infrastructure, not a product. SRS gives you the engine; you build the vehicle. Non-technical founders will need a developer, or the Oryx wrapper, to get anywhere close to a usable service.

---

What is SRS

SRS stands for Simple Realtime Server. The “simple” is aspirational — the codebase is C/C++, the configuration is INI files, and the documentation is split across English and Chinese wikis — but the deployment is genuinely simple compared to building equivalent infrastructure from scratch [README][2].

At its core, SRS is a media server: it accepts incoming video streams (from OBS, FFmpeg, a browser, or another server), processes them, and delivers them to viewers through whichever protocol they need. Its architecture diagram shows a single node handling ingest and egress across every major streaming protocol simultaneously [README].

The full protocol stack as of SRS 7.0: RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181 (the Chinese government standard for IP cameras, relevant if you’re building surveillance or smart-city applications) [README]. The codec support is equally broad: H.264, H.265, AV1, VP9 on video, AAC, Opus, and G.711 on audio.

It runs on Linux and macOS, across X86_64, ARMv7, AARCH64, Apple M1, RISC-V, LoongArch, and MIPS. That last part matters if you’re deploying on edge hardware or ARM-based cloud instances [README].

The project launched in 2013 and sits at 28,646 GitHub stars as of this review. It’s maintained by the OSSRS community, with the organization registered in North York, Ontario, Canada. The companion product Oryx is a higher-level wrapper that packages SRS into an all-in-one solution with a web dashboard, making it approachable without deep protocol knowledge [website].

---

Why people choose it

The two relevant reviews of SRS-as-media-server tell a consistent story: this is the go-to open-source choice when you need multiple streaming protocols from one place and you don’t want to pay commercial licensing fees.

Protocol flexibility without re-encoding. The brightcoding.dev guide [2] is the most comprehensive technical treatment available, and its main thesis is that SRS’s killer feature is protocol conversion. A stream arrives via RTMP from OBS; viewers receive it as HLS on mobile, as HTTP-FLV in the browser, or as WebRTC for sub-second latency. No re-encoding between formats. This is not trivial — most servers handle one or two protocols well and bolt on others as afterthoughts [2].

Latency profiles across use cases. The same guide [2] gives concrete numbers:

• RTMP: 1–3 seconds (standard live streaming)
• WebRTC: 150–400 milliseconds (video conferencing, interactive use cases)
• HLS: 3–10 seconds standard, 2–3 seconds with low-latency HLS variants

This matters for product decisions. If your use case is e-commerce live shopping where you want viewers to interact with the host, 3 seconds of delay destroys the experience. If you’re building sports highlights, 10 seconds is fine. SRS handles both with configuration, not code changes [2].

Real use cases from the field [2]:

• E-commerce live shopping (major driver in Asian markets, growing in the West)
• Esports and betting platform streaming
• Telemedicine consultations requiring sub-second latency
• 24/7 linear broadcasting (replacing traditional broadcast infrastructure)
• WebRTC video conferencing (videosdk.live built their tutorial stack on SRS [1])

The developer experience story from videosdk.live [1]: SRS’s WebRTC support works with standard browser RTCPeerConnection APIs. You’re not locked into a proprietary SDK. The signaling setup is documented, the server handles the WHIP/WHEP exchange, and you can have a working video conference prototype in an afternoon. That’s a real signal about API quality for an open-source project this old.

---

Features

Based on the README and technical guides:

Protocol engine:

• RTMP (ingest and egress)
• WebRTC (WHIP/WHEP for sub-400ms latency) [1][2]
• HLS (standard and low-latency variants)
• HTTP-FLV (low-latency for browser players without WebRTC)
• SRT (Secure Reliable Transport — used for contribution feeds, poor network conditions)
• MPEG-DASH
• GB28181 (IP camera standard)
• HTTP-TS (transport stream over HTTP)

Protocol conversion:

• Ingest RTMP → deliver HLS, HTTP-FLV, WebRTC simultaneously [2]
• No re-encoding required for protocol switching [2]

Codec support:

• Video: H.264, H.265, AV1, VP9
• Audio: AAC, Opus, G.711

Operational features:

• HTTP API (port 1985 by default) for stream management and statistics
• Prometheus metrics integration
• Grafana dashboard support for production monitoring [2]
• Structured logging
• DVR (record to local disk)
• Transcoding support (via FFmpeg integration)
• Clustering for horizontal scaling
• Docker and Kubernetes native deployment [README][2]

Platform reach:

• Linux, macOS
• X86_64, ARMv7, AARCH64, Apple M1, RISC-V, LoongArch, MIPS

---

Pricing: SaaS vs self-hosted math

SRS itself costs nothing — MIT license, no commercial restrictions, no feature gating [README]. The cost is the infrastructure you run it on.

Self-hosted:

• SRS license: $0
• Minimal VPS (2 vCPU, 4GB RAM, sufficient for hundreds of concurrent viewers on a single stream): $10–20/month on Hetzner or Contabo
• Bandwidth: the real wildcard. A single 720p stream at 3 Mbps × 100 concurrent viewers = 300 Mbps sustained. That’s where you need to budget carefully — either a VPS with generous bandwidth allowances or a CDN layer.

Commercial alternatives (for comparison):

• Wowza Streaming Engine: Self-hosted commercial license, starts around $95/month. Includes support and a control panel SRS lacks.
• Wowza Cloud: SaaS, usage-based pricing per streaming hour.
• AWS IVS (Interactive Video Service): SaaS, charges per streaming minute. Low-latency ingest at ~$0.20/channel-hour, plus data transfer.
• Mux: SaaS, charges per minute of video delivered. Simple billing but costs add up fast at scale.
• Ant Media Server: Open-source community edition (free) + Enterprise edition (~$149/month per origin server). More polished dashboard than SRS, more comparable to Wowza.

Rough savings math:

If you’re running a live streaming product with 5 concurrent streams and 500 concurrent viewers, Wowza Cloud or AWS IVS runs you comfortably into $200–500/month territory. The same workload on SRS: a $20 origin server, a CDN edge layer (Bunny CDN or Cloudflare Stream as a pull cache), and your bandwidth costs. Total: $40–80/month depending on bandwidth.

That’s not the right comparison for a solo non-technical founder who can’t debug a failed WebRTC handshake. But for a technical team or a founder with a developer, the math is obvious at volume.

---

Deployment reality check

The recommended path is Docker, and it’s genuinely simple [README]:

docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 \
    -p 8000:8000/udp -p 10080:10080/udp ossrs/srs:6

Five flags, one command, running. Stream from OBS to rtmp://localhost/live, open http://localhost:8080 to verify. That part works as advertised [README].

What you need beyond that:

• A Linux VPS. 2 vCPU and 4GB RAM is a reasonable starting point for production.
• A domain and reverse proxy (nginx or Caddy) for HTTPS — required for WebRTC in browsers.
• Port exposure planning: RTMP on 1935, WebRTC/QUIC on UDP 8000, SRT on UDP 10080, HTTP on 8080. Cloud firewall rules need to be open for all of these.
• For WebRTC specifically: a STUN/TURN server configuration. SRS handles the media, but NAT traversal requires a TURN server for clients behind strict firewalls [1]. This is the most common source of “WebRTC doesn’t work from my phone” bugs.
• For transcoding: FFmpeg installed separately. SRS can spawn FFmpeg processes for format conversion, but it doesn’t bundle one [2].
• For monitoring: Prometheus scraper and Grafana if you want production dashboards. Not required, but the metrics endpoint is there [2].

Where things get harder:

The documentation is uneven. The English docs are good for the happy path (Docker, RTMP→HLS, basic WebRTC) and thin for edge cases. The Chinese docs are more complete. If you’re building something custom — clustering, fine-grained RTMP authentication, callback hooks — you’ll end up reading source code or asking on Discord.

The configuration format is INI, which is readable but not composable. Environment variable overrides exist but the documentation on which settings support them is incomplete.

Oryx as the non-technical alternative: The OSSRS team maintains Oryx (formerly SRS Stack), which packages SRS with a web management UI, one-click scenario setup, and guides oriented toward less technical users. If you want SRS’s power without the raw configuration surface, Oryx is the answer. Think of SRS as the engine block and Oryx as the car.

Realistic setup time for a developer following the guides: 1–3 hours for a working RTMP+HLS setup. Add another 2–4 hours for WebRTC with TURN and HTTPS. Clustering and production-grade monitoring: plan a day.

---

Pros and cons

Pros

• Genuinely MIT. No fair-code carve-outs, no commercial-use restrictions, no per-stream licensing. Use it in your product, sell it to clients, fork it — no legal review needed [README].
• Protocol breadth from one binary. RTMP + WebRTC + HLS + SRT + MPEG-DASH simultaneously, with protocol conversion between them. No commercial server at any price point handles this more cleanly [README][2].
• Sub-400ms WebRTC latency out of the box, using standard browser APIs. Not a proprietary SDK — works with RTCPeerConnection directly [1][2].
• 28,000+ GitHub stars with a decade-long track record. This is not an experimental project. It’s running production workloads at significant scale.
• Cloud-native from the start. Docker, Kubernetes, Prometheus, Grafana — the operational tooling stack integrates without gymnastics [README][2].
• Wide hardware support. ARMv7, AARCH64, RISC-V, LoongArch. If you’re deploying on edge hardware or exotic ARM clouds, SRS runs there.
• No per-execution or per-stream charges. Unlimited streams, unlimited viewers — your only cost is infrastructure.

Cons

• Not a product. SRS is infrastructure. There’s no management UI (outside of Oryx), no stream keys dashboard, no analytics — you build or buy those on top.
• Documentation quality is inconsistent. The English docs cover the happy path well. Complex scenarios often require reading Chinese docs or Discord history [observed from review research].
• WebRTC TURN setup is on you. SRS handles the media plane, but TURN server configuration for NAT traversal is a separate operational concern that catches non-trivial deployments off guard [1].
• No native clustering UI. Horizontal scaling is supported in the protocol, but orchestrating a multi-origin, multi-edge cluster requires manual configuration and scripting. Wowza and Ant Media Server have GUI cluster management.
• INI configuration format with incomplete env var support. Not a deal-breaker, but infrastructure-as-code setups (Terraform, Ansible) require extra work to template.
• C/C++ codebase means contributing back requires C++ skills. Contrast with n8n (TypeScript), where your average web developer can write an integration.
• No built-in auth/DRM. Stream key authentication and DRM (for protecting premium content) require custom development or external tooling.

---

Who should use this / who shouldn’t

Use SRS if:

• You’re a developer or have a developer, and you need self-hosted video infrastructure with protocol flexibility.
• You’re building a streaming product (live shopping, gaming, telemedicine) and commercial per-minute pricing will kill your margins at scale.
• You need WebRTC at below 400ms latency without paying a commercial SFU vendor.
• You’re in a regulated environment where video must stay on your own servers.
• You want an MIT-licensed foundation you can embed in your own product or white-label.
• You’re targeting hardware that mainstream cloud streaming services don’t deploy to.

Use Oryx (not raw SRS) if:

• You’re mostly non-technical but understand servers, and you want SRS’s capabilities with a management UI and guided setup.

Skip it (use Ant Media Server) if:

• You need a web-based cluster management UI and are willing to use a dual-license model (free community edition, paid enterprise).
• You want SRS-level protocol support but with a UI that doesn’t require reading configs.

Skip it (use a managed service) if:

• You have fewer than a handful of streams and the cognitive overhead of server management is not worth the savings.
• You need enterprise SLA, DRM, or content delivery guarantees that a managed service provides.
• Your team has no one who can debug a WebRTC handshake failure.

Skip it (use mediasoup or Pion) if:

• You’re building pure WebRTC infrastructure (SFU/MCU for conferencing) and don’t need RTMP or HLS at all. Mediasoup and Pion are more flexible for programmatic SFU architectures.

---

Alternatives worth considering

• Ant Media Server — the closest open-source analogy with a management UI. Community edition is free, Enterprise edition adds clustering and DRM at a paid tier. Less raw than SRS, more approachable.
• nginx-RTMP module — the classic self-hosted RTMP server. Much simpler, much less capable — no WebRTC, no SRT, limited protocol conversion. Worth knowing about as the “just RTMP + HLS” option.
• Mediasoup — Node.js SFU framework focused on WebRTC. Better choice for video conferencing architectures where you don’t need RTMP or HLS.
• Janus — open-source WebRTC server with a plugin architecture. More focused on conferencing than broadcast streaming.
• Wowza Streaming Engine — commercial self-hosted server with a long track record and professional support. Worth paying for if you need SLA guarantees and don’t have in-house video expertise.
• Mux / AWS IVS — SaaS streaming APIs. Use these if you want to skip the infrastructure entirely and pay per minute. Break-even vs. SRS self-hosted is usually somewhere around 50–100 concurrent viewers consistently.
• Cloudflare Stream — SaaS with straightforward per-minute pricing and a global CDN. Worth considering if CDN delivery is your main problem.

---

Bottom line

SRS is what you reach for when you’ve looked at the Mux or AWS IVS bill, done the math, and decided to own your infrastructure. For a technical team building a streaming product at any meaningful scale, the protocol depth (RTMP + WebRTC + HLS + SRT from one binary), the MIT license, and the decade of production use justify the operational investment. The Docker deploy is fast; the learning curve is real but finite; the savings at volume are substantial.

What SRS is not: a turn-key streaming platform, a managed service with SLAs, or something a non-technical founder should operate solo. If you don’t have a developer who can configure nginx reverse proxies and troubleshoot UDP firewall rules, start with Oryx or a managed SaaS and migrate later when scale justifies it.

If you need help deploying SRS or Oryx and just want the infrastructure running without the ops overhead, that’s exactly the kind of one-time setup upready.dev handles for clients.

---

Sources

1. How to Build SimpleRealtime Server (SRS) WebRTC App with JavaScript — videosdk.live. https://www.videosdk.live/developer-hub/media-server/srs-webrtc

2. Building a Real-Time Video Streaming Server with RTMP, WebRTC, HLS, and SRT Support: A Complete Guide Using SRS (Mohamed IDBRAHIM, Sep 2025) — brightcoding.dev. https://www.blog.brightcoding.dev/2025/09/02/building-a-real-time-video-streaming-server-with-rtmp-webrtc-hls-and-srt-support-a-complete-guide-using-srs/

Primary sources:

• GitHub repository and README: https://github.com/ossrs/srs (28,646 stars, MIT license)
• Official website: https://ossrs.io/lts/en-us/
• Getting Started docs: https://ossrs.io/lts/en-us/docs/v6/doc/getting-started