Owncast auf einem Managed VPS hosten: Ihre Livestreams auf Ihrem Server

Was Owncast kann

Owncast ist ein quelloffener, selbst gehosteter Server für Live-Video-Streaming und Chat für einen einzelnen Nutzer: Eine Instanz trägt den Kanal einer Person oder einer Organisation. Sein README stellt es als Weg vor, Ihre eigenen Livestreams nach dem Vorbild der großen Plattformen zu betreiben und dabei Ihre Inhalte, Ihre Oberfläche, Ihre Moderation und Ihr Publikum in der Hand zu behalten.

• Die Annahme: Ihre Streaming-Software, etwa OBS, sendet den Stream über RTMP, das Protokoll der großen Streaming-Plattformen.
• Die Auslieferung: Owncast zerlegt das Video in HLS-Segmente, in einer oder mehreren Qualitäten, und liefert es auf seiner Webseite aus. Der Stream lässt sich auch in VLC oder mpv abspielen, unter /hls/stream.m3u8.
• Der Chat: in die Seite eingebaut, mit Moderatoren, Sperren und Anmeldung über das Fediverse oder IndieAuth.
• Das Fediverse: Ein Mastodon-Konto kann Ihrem Server folgen und erfährt jedes Mal, wenn Sie live gehen. Version 0.3.0 ergänzt die Featured Streams, die die Livestreams anderer Owncast-Server zeigen.
• Die Erweiterung: Webhooks, APIs und seit 0.3.0 Plugins, die über die Administration installiert werden, mit den Berechtigungen, die Sie ihnen gewähren.

Was die MIT-Lizenz erlaubt

Owncast wird unter der MIT-Lizenz veröffentlicht. Sie gewährt kostenlos das Recht, die Software zu nutzen, zu kopieren, zu ändern, zusammenzuführen, zu veröffentlichen, zu verbreiten, unterzulizenzieren und Kopien davon zu verkaufen. Sie können sie also für Ihr Unternehmen, Ihre Community oder Ihre Kunden betreiben, ohne eine Lizenz zu kaufen.

Die einzige Bedingung ist, den Urheberrechtshinweis und den Lizenztext in allen Kopien oder wesentlichen Teilen der Software beizubehalten. Der Text stellt die Software „wie besehen“ bereit, ohne Gewährleistung.

Prozessor und Bandbreite: den Server bemessen

Die Dokumentation sagt es gleich zu Beginn: Der Bedarf hängt von Ihrer Konfiguration ab. Sie gibt aber eine klare Regel an die Hand, um ihn abzuschätzen. Der Prozessor transkodiert das Video in die Qualitäten, die Sie anbieten; die Bandbreite liefert es an jeden Zuschauer aus.

• Die Zahl der Zuschauer ändert die Prozessorlast nicht. Das Video wird einmal kodiert und dann an alle ausgeliefert: null Zuschauer oder hundert, die Kodierarbeit bleibt dieselbe. Der Chat fügt etwas Last hinzu, gering neben der Kodierung.
• Die Bandbreite wächst mit jedem Zuschauer. Jeder Zuschauer erhält seine eigene Kopie des Streams.
• Jede transkodierte Qualität braucht Prozessorleistung, umso mehr, je niedriger die Zielbitrate ist, denn stärkeres Komprimieren erfordert mehr Rechenarbeit.

Die Bandbreite des Servers

Die Dokumentation gibt zwei Formeln an. Das Volumen eines Streams in Gigabyte: Bitrate in kbit/s × Dauer in Sekunden × Zuschauer ÷ 8.000.000. Die zu haltende ausgehende Spitzenrate in Mbit/s: Bitrate in kbit/s × Zuschauer ÷ 1.000. Bei mehreren Qualitäten rechnen Sie jede einzeln und addieren sie. Ihre Schätzungen für einen Stream von zwei Stunden:

Auf einem Simafri-VPS hat der Datenverkehr keinen monatlichen Zähler: Ihre Streams werden nach ihrer Spitzenbitrate bemessen. Wächst Ihr Publikum, liefert der weiter unten beschriebene Objektspeicher das Video an Stelle des Servers aus.

Der Prozessor

Die Dokumentation nennt gemessene Anhaltspunkte und weist darauf hin, dass sie je nach Codec, Bitrate, Auflösung und Encoder-Voreinstellung schwanken:

• Ein Kern pro Qualität: Als grobe Faustregel schafft ein einzelner Prozessorkern oft eine transkodierte Qualität mit 30 Bildern pro Sekunde.
• Die Bildrate: 60 Bilder pro Sekunde erfordern etwa doppelt so viel Rechenarbeit wie 30, und 24 Bilder pro Sekunde etwa das 0,8-Fache.
• Die Standardeinstellung: Owncast startet mit einer einzigen Qualität, mit 1.200 kbit/s und 24 Bildern pro Sekunde, deren Ton unverändert durchgereicht wird. Die Dokumentation rät, dort zu beginnen, zu testen und dann eine Qualität hinzuzufügen, sobald der Prozessor Reserven hat.

Die Dokumentation nennt keinen Wert für den Arbeitsspeicher, und die Festplatte spielt kaum eine Rolle: Die Videosegmente werden im Lauf des Streams geschrieben und wieder entfernt. Nur der Ordner data wächst mit der Zeit. Auf einem VPS übernimmt der Prozessor die Kodierung: Jede transkodierte Qualität wird in vCPUs bemessen. Auf einem Managed VPS beschreiben Sie uns Ihre Streams, ihre Bitrate, ihre Qualitäten und Ihr Publikum, und wir empfehlen Ihnen die passende Größe.

Ihre Verbindung zum Senden

Bevor der Stream den Server erreicht, verlässt er Ihre eigene Verbindung. Die Dokumentation verlangt eine Upload-Geschwindigkeit von mindestens dem 1,5-Fachen der Bitrate des Streams: 7,5 Mbit/s für einen Stream mit 5.000 kbit/s. Sie empfiehlt eine Kabelverbindung statt WLAN.

Die Installation mit Docker Compose

Die Dokumentation bietet das Image owncast/owncast auf Docker Hub an, das ffmpeg enthält, das Kodierwerkzeug, das Owncast braucht. Legen Sie auf einem Server, auf dem Docker installiert ist, einen Ordner an und speichern Sie darin diese compose.yaml, entnommen aus der Dokumentation:

services:
  owncast:
    image: owncast/owncast:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
      - "1935:1935"
    volumes:
      - ./data:/app/data

docker compose up -d

• Port 8080, auf 127.0.0.1 veröffentlicht: Das ist die einzige Änderung gegenüber dem Beispiel der Dokumentation, das beide Ports veröffentlicht. Ihre Seite zum Reverse Proxy bittet darum, Owncast nicht direkt ins Internet zu stellen, da es standardmäßig auf allen Schnittstellen lauscht, und Docker veröffentlicht einen Port ohne Angabe auf allen Adressen des Servers. Die Weboberfläche ist dann nur über den Reverse Proxy erreichbar.
• Port 1935 empfängt den Stream über RTMP. Er bleibt öffentlich, denn Ihre Streaming-Software erreicht ihn direkt, ohne über den Proxy zu gehen.
• Der Ordner data hält die Datenbank und ihre Backups auf dem Server, außerhalb des Containers: Ihn sichern und verschieben Sie.
• Das Tag latest folgt der jüngsten Version; 0.3.0 legt eine Version fest.

Ohne Docker: das offizielle Installationsprogramm

Der andere Weg der Dokumentation ist ein Skript, das die neueste Owncast-Version für Ihre Plattform herunterlädt, und ffmpeg, falls es noch nicht vorhanden ist. Es installiert alles in einem Ordner owncast unterhalb des aktuellen. Die Dokumentation rät davon ab, es als root auszuführen, und empfiehlt, jedes entfernte Skript vor dem Ausführen zu lesen:

curl -s https://owncast.online/install.sh | bash

Damit Owncast mit dem Server startet und nach einem Absturz von selbst neu startet, liefert die Dokumentation einen systemd-Dienst, den Sie an den gewählten Ordner und das gewählte Konto anpassen:

[Unit]
Description=Owncast
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/owncast
ExecStart=/opt/owncast/owncast
User=owncast
Group=owncast
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now owncast

Admin-Passwort und Stream-Schlüssel

Die Administration liegt unter /admin. Owncast startet mit Zugangsdaten, die jeder kennt, und die Dokumentation bittet darum, sie bei der ersten Anmeldung zu ändern:

Um diese Änderung vorzunehmen, bevor die Oberfläche öffentlich erreichbar ist, gehen Sie über einen SSH-Tunnel: Port 8080 des Servers erscheint dann auf Ihrem Computer, unter http://localhost:8080/admin. Ergänzen Sie -p und den SSH-Port aus Ihrem Kundenbereich.

ssh -L 8080:127.0.0.1:8080 user@live.example.com

• Das Admin-Passwort ändern Sie unter „Configuration“, „Server Setup“. Es braucht 8 bis 192 Zeichen, mindestens einen Kleinbuchstaben, einen Großbuchstaben, eine Ziffer und ein Sonderzeichen aus !@#$%^&*, und nirgends einen Bindestrich.
• Die Stream-Schlüssel verwalten Sie im Reiter „Stream Keys“ derselben Seite. Owncast schlägt einen automatisch erzeugten Schlüssel mit 30 Zeichen vor, und Sie können mehrere behalten, jeden mit einem Kommentar: Ein Schlüssel, den Sie einem Co-Host geben, lässt sich später widerrufen, ohne die anderen anzurühren.
• Ein verlorenes Passwort ersetzen Sie beim Start mit dem Parameter --adminpassword, der es in der Datenbank speichert.

Das Admin-Passwort und der Stream-Schlüssel lauten anfangs beide abc123, sind aber zwei getrennte Einstellungen: Ändern Sie beide.

HTTPS: der Reverse Proxy

Owncast kümmert sich nicht selbst um HTTPS. Die Dokumentation stellt ihm einen Reverse Proxy voran, der auf den Ports 80 und 443 lauscht, das Zertifikat bezieht, den Datenverkehr verschlüsselt und ihn unverschlüsselt an Owncast auf Port 8080 weitergibt. Ohne HTTPS kennzeichnen Browser die Seite als nicht sicher, und eine über HTTPS ausgelieferte Seite kann Ihr Video und Ihren Chat nicht einbetten.

• Der Proxy leitet jeden Pfad weiter, auch die WebSocket-Verbindung unter /ws, die den Chat trägt. Ein Proxy, der sie blockiert, schneidet den Chat ab.
• RTMP läuft nicht über den Proxy: Ihre Streaming-Software sendet direkt an Port 1935 von Owncast.
• Die echte Adresse der Besucher: Owncast liest den Header X-Forwarded-For, um die IP-Adresse eines im Chat gesperrten Nutzers zu blockieren. Die Dokumentation verlangt, dass der Proxy diesen Header selbst setzt.

Mit Caddy

Die Dokumentation schlägt Caddy vor, wenn Sie keine andere Präferenz haben: Es bezieht selbstständig ein Zertifikat von Let’s Encrypt und leitet WebSocket ohne zusätzliche Einstellung weiter. Hier ihr Caddyfile-Beispiel, in dem die Zeile tls die E-Mail-Adresse des Let’s-Encrypt-Kontos angibt:

live.example.com {
  encode gzip
  reverse_proxy 127.0.0.1:8080
  tls contact@example.com
}

Mit Nginx

Bei Nginx betont die Dokumentation WebSocket: Wer es vergisst, legt den Chat lahm. Ergänzen Sie den Abschnitt http von /etc/nginx/nginx.conf um diesen Block map:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Dieser Site-Block folgt dem der Dokumentation, auf Port 80, damit Certbot HTTPS einrichten kann:

server {
    listen 80;
    listen [::]:80;
    server_name live.example.com;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Authorization $http_authorization;
        proxy_pass_header Authorization;
        proxy_pass http://127.0.0.1:8080;
    }
}

sudo nginx -t
sudo certbot --nginx

Über RTMP aus OBS senden

Owncast akzeptiert jede Software, die über RTMP an einen entfernten Server sendet. Der Schlüssel wird nur auf dem Pfad /live angenommen. In OBS:

1. Öffnen Sie „Einstellungen“, dann „Stream“, und wählen Sie „Benutzerdefiniert“ als Dienst.
2. Geben Sie die Adresse rtmp://live.example.com:1935/live ein.
3. Geben Sie Ihren Stream-Schlüssel ein, den aus dem Reiter „Stream Keys“ von Owncast.
4. Starten Sie den Stream.

Software ohne Feld für den Schlüssel akzeptiert die vollständige Adresse, rtmp://live.example.com:1935/live/your-key.

Auf einem Simafri-VPS kann die IPv6-Adresse des Servers jeden Port öffnen, den Sie wählen: Ihre Streaming-Software erreicht Port 1935 über diese Adresse, unter einem Namen, der den Eintrag AAAA trägt. In einem IPv4-Docker-Netzwerk, wie hier, leitet Docker den Port auf der IPv6-Adresse des Servers an den Container weiter. Öffnen Sie diesen Port, wenn ufw aktiv ist, und testen Sie dann von Ihrem Computer aus:

sudo ufw allow 1935/tcp
nc -6 -vz live.example.com 1935

Für jeden anderen Bedarf beschreiben Sie uns Ihr Vorhaben, und wir sehen uns die Adressierung gemeinsam mit Ihnen an.

Die Einstellungen Ihrer Streaming-Software

• Die Codecs: H.264 für das Video und AAC für den Ton, die einzigen, bei denen Transkodierung und Wiedergabekompatibilität gesichert sind.
• Das Keyframe-Intervall: eines alle 2 Sekunden, nie auf „Auto“. In OBS wird das Intervall in Sekunden angegeben, also 2.
• Die Bitrate: Senden Sie, was Sie anbieten wollen, nicht mehr. Schafft Ihr Server 720p mit 2.500 kbit/s, schicken Sie ihm kein 1080p mit 6.000 kbit/s: Jede Umwandlung, die Sie verlangen, erhöht die Prozessorlast.

Videoqualitäten und Latenz

Die den Zuschauern angebotenen Qualitäten stellen Sie unter „Configuration“, „Video“ ein. Mehrere Qualitäten lassen den Player diejenige wählen, die seine Verbindung tragen kann: Die Dokumentation empfiehlt eine zweite Qualität mit 1.000 bis 2.000 kbit/s neben einer hohen Qualität mit 4.000 bis 6.000 kbit/s, sobald Ihre erste Konfiguration getestet ist.

• Die Bitrate: von 400 bis 13.000 kbit/s, in Schritten von 100.
• Die Bildrate: von 24 bis 120 Bildern pro Sekunde, standardmäßig 24.
• Die Auflösung: Ändern Sie die Breite oder die Höhe, nicht beide, und Owncast behält das Seitenverhältnis bei.
• Die Prozessornutzung: fünf Stufen. Je höher die Stufe, desto besser das Bild, oder desto kleiner die Datei bei gleicher Qualität.

Passthrough reicht das eingehende Video weiter, ohne es neu zu kodieren: Es spart fast die gesamte Prozessorleistung dieser Qualität und ignoriert deren Einstellungen für Bitrate, Auflösung und Bildrate. Die Dokumentation reserviert es für fortgeschrittene Nutzer: Die Zuschauer erhalten genau das, was Ihre Software sendet, was manche Player nicht abspielen können, und die Latenz steigt. Testen Sie die Wiedergabe auf den Geräten, die Ihnen wichtig sind, bevor Sie sich darauf verlassen.

Die Latenz wird mit dem Latenzpuffer eingestellt, auf derselben Seite. Jede Stufe tauscht etwas Verzögerung gegen Stabilität, und eine Änderung gilt ab dem nächsten Stream:

Version 0.3.0 ergänzt außerdem auf Seiten der Zuschauer die Option „Minimize latency“ des Players, die die Wiedergabe leicht beschleunigt, um näher an die Live-Zeit heranzukommen, und eine Einstellung für die automatische Wiedergabe, standardmäßig ausgeschaltet.

Objektspeicher, um mehr Zuschauer zu bedienen

Owncast kann seine Videosegmente an einen S3-kompatiblen Speicher schicken, von dem die Zuschauer sie herunterladen. Der Server liefert weiterhin die Master-Playlist, die APIs und den Chat; das Video, das fast die gesamte Bandbreite ausmacht, kommt aus dem Speicher. Ihr Server sendet dann nur noch eine Kopie jeder Qualität: im Beispiel der Dokumentation 6,5 Mbit/s für zwei Qualitäten mit 5.000 und 1.500 kbit/s, ob Sie null Zuschauer haben oder tausend. Die Prozessorlast bleibt dieselbe.

1. Legen Sie bei Ihrem Anbieter für Objektspeicher einen Bucket an.
2. Machen Sie ihn öffentlich lesbar und setzen Sie eine CORS-Richtlinie, falls der Anbieter eine verlangt: Ein Fehler CORS oder Access-Control-Allow-Origin in der Browserkonsole kommt fast immer daher.
3. Aktivieren Sie unter „Configuration“, „Server Setup“, Reiter „S3 Object Storage“, den Speicher und geben Sie Bucket-Namen, Zugriffsschlüssel, geheimen Schlüssel, Endpunkt und Region ein. Alle diese Felder sind Pflicht.

Dieser Speicher liefert den Livestream aus, kein Archiv: Owncast löscht laufend Segmente, die älter sind als die Playlist plus ein Puffer von etwa 20 Segmenten. Der Bucket enthält nur die letzten Minuten des Streams.

Für Zuschauer in aller Welt beschreibt die Dokumentation außerdem ein Content Delivery Network (CDN) vor Owncast, mit einem eigenen Origin-Hostnamen und der Einstellung „Websocket host override“, die den Chat mit dem Ursprungsserver verbunden hält.

Der Chat und die Moderation

Der Chat wird unter „Configuration“, „Chat“ eingerichtet. Standardmäßig gibt es keine Moderatoren: Die Dokumentation schlägt vor, sich zumindest selbst dazu zu machen, über die Seite „Users“ der Administration.

• Die Moderatoren blenden eine Nachricht aus oder sperren einen Nutzer direkt im Chat. Sie haben keinen Zugang zur Administration.
• Eine Sperre trennt den Nutzer, entfernt seine Nachrichten und blockiert seine bekannte IP-Adresse. Sie lässt sich später aufheben; das Löschen eines Nutzers dagegen ist endgültig.
• Nur etablierte Nutzer: Diese Einstellung blockiert Nachrichten von Konten, die jünger als 15 Minuten sind, Moderatoren ausgenommen.
• Der Sprachfilter weist beleidigende Nachrichten ab, anhand einer internen Wortliste.
• Die Pflicht zur Authentifizierung lässt nur authentifizierte Nutzer, über ein Fediverse-Konto oder IndieAuth, und Moderatoren Nachrichten senden.
• Die Ratenbegrenzung, standardmäßig aktiv, erlaubt etwa eine Nachricht alle zwei Drittel einer Sekunde und blockiert jeden, der den Chat flutet, für 10 Sekunden.

Die Dokumentation weist darauf hin, dass sich eine IP-Sperre umgehen lässt, etwa mit einem VPN: Sie hält Missbrauch in Grenzen, und die Moderation bleibt die eigene Arbeit jedes Kanals. Daher der Wert benannter Moderatoren für Ihre meistgesehenen Streams.

Die Backups

Owncast sichert seine eigene Datenbank einmal pro Stunde, nach data/backup/owncastdb.bak. Der Parameter --backupdir ändert diesen Ordner. Das enthält der Datenordner:

Für eine vollständige Wiederherstellung, oder um die Instanz umzuziehen, bittet die Dokumentation darum, den ganzen Ordner data zu sichern: In eine neue Installation kopiert, nimmt er alles mit. Mit Docker, bei gestopptem Dienst:

docker compose down
tar -czf owncast-$(date +%F).tar.gz data
docker compose up -d

Planen Sie diese Kopie passend zu Ihren Streams und schicken Sie sie außerhalb des Servers. Auf seiner Festplatte abgelegt, fließen diese Archive auch in seine nächtlichen Backups ein.

Die Datenbank wiederherstellen

Eine Wiederherstellung setzt die Datenbank auf den Stand des Backups zurück: Alles, was sich seitdem geändert hat, geht verloren. Kopieren Sie zuerst die aktuelle Datenbank an einen sicheren Ort, dann:

1. Stoppen Sie Owncast.
2. Starten Sie Owncast mit --restoreDatabase und dem Pfad der Backup-Datei: Es stellt die Datenbank wieder her und beendet sich dann.
3. Starten Sie Owncast wie gewohnt und prüfen Sie dann Ihre Einstellungen in der Administration.

docker compose stop
docker compose run --rm owncast --restoreDatabase data/backup/owncastdb.bak
docker compose up -d

Die Updates

Mit Docker nennt die Dokumentation zwei Befehle, auszuführen im Ordner der compose.yaml. Der Datenordner bleibt dabei erhalten:

docker compose pull
docker compose up -d

Mit dem Installationsprogramm beschreiben die Release Notes von 0.3.0 das Update: Stoppen Sie den Dienst, legen Sie die angepassten Dateien der Weboberfläche beiseite, führen Sie das Installationsprogramm erneut mit dem Konto aus, das Owncast betreibt, und starten Sie dann neu. Das Skript selbst legt ein Archiv des Ordners data in owncast-install-backups ab, bevor es die Version ersetzt.

sudo systemctl stop owncast
su -c "curl https://owncast.online/install.sh | bash" owncast
sudo systemctl start owncast

Version 0.3.0, erschienen am 3. September 2026, bringt Plugins, Featured Streams, die automatische Wiedergabe und die Wahl der Schnittstelle, auf der RTMP lauscht. Ihre Notizen bitten darum, die Änderungen vor dem Update zu lesen, da sie Ihre Instanz betreffen: Verfolgen Sie diese Notizen bei jeder Version und kopieren Sie den Ordner data unmittelbar davor.

Wer was tut auf einem Managed VPS

Beim Selbsthosting müssen Sie neben der Anwendung auch den Server betreuen. Auf einem Managed VPS übernehmen unsere Teams den Server und betreuen Ihre Instanz proaktiv; Owncast bleibt Ihre Software, mit ihren Einstellungen und Daten.

Wenn unsere Teams lieber in der Anwendung selbst eingreifen sollen, wird diese Leistung nach Stunden oder pauschal abgerechnet, mit einem Kostenvoranschlag vor dem Eingriff.