datarhei/restreamer: a self-hosted RTMP, SRT and HLS server for publishing to YouTube and Twitch

What Restreamer actually sits between

The project describes itself as a self-hosting solution to stream live to your website and publish to many platforms such as YouTube-Live, Twitter, Twitch and Vimeo. Read that literally: Restreamer is not an encoder and not a player product. It is the middle box. OBS, a camera or another RTMP/SRT source feeds it, and it fans that feed out to one or more destinations while also offering an HTTP/S HLS server, an RTMP/S server and an SRT server of its own.

The audience is the person who is tired of a hosted relay subscription and is willing to run a container. The README lists the intended environments explicitly: Linux, macOS and Windows through Docker Desktop, and single-board computers such as the Raspberry Pi, plus GPU-powered systems for encoding. If you have a spare NUC, a Pi 4 and a stable uplink, you are the target user. If you want someone else to be paged when the stream drops at 3am, you are not.

The bundle is three images glued by a Dockerfile

Restreamer is assembled, not written as one program. The Dockerfile at the repository root pulls three images and copies pieces out of two of them: the UI build lands in /core/ui, the core binaries in /core, and the ffmpeg image becomes the runtime base. The build arguments name them directly: RESTREAMER_UI_IMAGE defaults to datarhei/restreamer-ui:latest, CORE_IMAGE to datarhei/base:alpine-core-latest, and FFMPEG_IMAGE to datarhei/base:alpine-ffmpeg-latest.

That layout explains most of the project's behaviour. The backend is the Golang project datarhei/core, the interface is a React project, and the media work is done by a datarhei-maintained ffmpeg build. The README says video processing is "as native as possible", which is a fair description of a design that delegates codecs and muxing to ffmpeg rather than reimplementing them. It also means the feature set you get is bounded by what that ffmpeg build was compiled with, and the Dockerfile runs ffmpeg -buildconf at build time, so the build configuration is baked into the image rather than chosen by you at runtime.

State lives in two volumes, /core/config and /core/data, declared as VOLUME entries. The environment variables CORE_CONFIGFILE, CORE_DB_DIR, CORE_ROUTER_UI_PATH and CORE_STORAGE_DISK_DIR map those paths into the core process. Back up /core/config and you have backed up the installation.

Installing Restreamer with docker run

The README's quick setup is a single docker run for AMD64, ARMv7 and ARM64. It mounts config and data under /opt/restreamer, publishes four TCP ports and one UDP port, and restarts the container automatically.

docker run -d --restart=always --name restreamer \
   -v /opt/restreamer/config:/core/config -v /opt/restreamer/data:/core/data \
   -p 8080:8080 -p 8181:8181 \
   -p 1935:1935 -p 1936:1936 \
   -p 6000:6000/udp \
   datarhei/restreamer:latest

The README notes that --privileged is only needed for local devices such as USB cameras, and suggests --security-opt seccomp=unconfined if no network source can be reached. Those two flags are the usual source of friction on hardened hosts, and the second one is worth understanding before you paste it: it loosens the container's syscall filter.

On a Raspberry Pi the README switches the image tag to datarhei/restreamer:rpi-latest and adds --privileged. For Nvidia CUDA it uses --runtime=nvidia --privileged with datarhei/restreamer:cuda-latest, and for Intel VAAPI it mounts /dev/dri and uses datarhei/restreamer:vaapi-latest. Choosing the wrong tag is the most common way to end up with software encoding and a pegged CPU.

After the container is up, the README points at the documentation quick start rather than the README itself for the first-run steps. There is also a hosted demo at demo.datarhei.com/ui with the credentials admin and demo, which is the cheapest way to see the wizard before you commit a machine. For external access the README states that port forwarding from your router to the Restreamer's internal IP may need to be set up.

Where Restreamer is the wrong tool

The README does not document rollback, and it does not publish a support matrix for concurrent outputs. Treat both as unknowns you must test on your own hardware before a live event.

The more structural limitation is latency and interactivity. Restreamer's own server protocols are HLS, RTMP/S and SRT. HLS is segment-based, so the HTTP path will always be seconds behind, and nothing in the README claims otherwise. If your product is a chat-driven live show where the host reacts to messages, this is the wrong layer. The project's stated scope is publication and redistribution, not audience interaction.

A second boundary is the platform list. The README names YouTube-Live, Twitter, Twitch, Vimeo, Wowza and "other platforms or services" over RTMP and SRT. That covers the mainstream ingest endpoints. It does not describe first-class integrations with platforms that require their own SDK, and it does not claim to.

Finally, the privacy claim cuts both ways. The README states the project is GDPR compliant without third-party providers and does not save audience data. That is a genuine advantage over hosted relays, but it also means you get no built-in analytics beyond the viewer and bandwidth monitoring the feature list mentions. If you need detailed audience reporting, you are building it yourself against the REST API or the optional Prometheus metrics.

Restreamer compared with Owncast

The comparison people search for is restreamer vs owncast, and the two solve different problems despite both being self-hosted streaming servers.

Owncast is aimed at running your own channel: one server, one audience, a page viewers visit, chat included. Restreamer is aimed at distribution: it takes your feed and pushes it to platforms that already have audiences. The README's feature list reflects that. It mentions a built-in VideoJS player for your website and a configurable publication website for streaming without player embedding, so Restreamer can serve viewers directly, but the emphasis is on outputs to YouTube-Live, Twitch, Vimeo and Wowza.

The practical difference: if your goal is "my own streaming site with chat", Owncast is the closer fit. If your goal is "one encode, five destinations, and my own relay in the middle", Restreamer is the closer fit. Running both is not absurd, but it doubles the operational surface for the same source feed.

Maintenance, licensing and upgrade cost

The repository is not archived and the last push was on 2026-05-22. The most recent release listed is v2.12.0 from 2024-09-13, preceded by v2.11.0 on 2024-06-07 and v2.10.0 on 2024-04-23. That gap between release tags and repository activity is worth noting: fixes may be landing on the 2.x branch without a tagged release, and the README's own install instructions pull :latest rather than a version tag. Pinning a version is possible, but the documentation does not describe a supported upgrade path or a migration procedure between minor versions, so the practical upgrade cost is "pull the new image, restart, and check the volumes survived".

The licence is Apache-2.0 for the repository itself. The Dockerfile makes clear that the shipped image also contains datarhei/restreamer-ui and a datarhei ffmpeg build, and the README links a separate datarhei/ffmpeg repository. If you plan to redistribute the bundle rather than run it internally, check the licensing of those component images as well as this repository. Nothing here is legal advice; the point is that the Apache-2.0 badge on the repository is not automatically the whole story for the assembled image.

The README also mentions a content licence with Creative Commons in the feature list, which concerns the media you stream rather than the software.

Operationally, the recurring costs are the ones the README implies rather than states: an always-on machine, bandwidth for every output you enable, and the port forwarding to keep the ingest and egress ports reachable. The bandwidth limiting feature exists precisely because multiple simultaneous outputs multiply your uplink usage.

What the REST API and Swagger documentation give you

The feature list claims a REST-API (JSON) that is 100% Swagger documented. That is the part of Restreamer that separates it from a purely click-driven appliance. It means the wizard is a convenience layer over an HTTP interface you can drive from scripts, so provisioning a stream, starting a process and reading status do not have to be manual steps.

The README does not reproduce the API surface or an authentication example, so the Swagger documentation is where you would look before writing automation. The resource monitoring feature, optionally exposed as Prometheus metrics, is the other integration point: it lets an existing monitoring stack scrape the Restreamer host instead of you polling a UI.

One caveat on the API: the README gives no rate limits, no versioning policy and no deprecation notice for endpoints. If you build automation against it, you are coupling to an interface whose stability guarantees are not stated in the README.

Editorial conclusion

Adopt Restreamer if you already have an encoder such as OBS and want a self-hosted relay that fans one feed out to several platforms, keeps viewer and bandwidth numbers on your own hardware, and exposes a documented REST API for automation. Do not adopt it if your goal is a low-latency interactive stream with chat built in, or if you cannot run a container with host port ranges open. Verify three things first: that the four TCP ports and the one UDP port are free and forwarded, that your hardware path (VAAPI, CUDA or the Raspberry Pi image) matches the container tag you pull, and that the Apache-2.0 licence plus the separate ffmpeg and UI components are acceptable for how you plan to redistribute the bundle.

Frequently asked questions

Official sources

1. datarhei/restreamer on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases