Hostovat Owncast na Managed VPS: vaše živá vysílání na vašem serveru

Co Owncast umí

Owncast je otevřený server pro živé vysílání videa a chat, určený pro vlastní hosting a pro jednoho uživatele: jedna instance nese kanál jedné osoby nebo organizace. Jeho README ho představuje jako způsob, jak provozovat vlastní živá vysílání ve stylu velkých platforem a přitom si ponechat vlastnictví obsahu, rozhraní, moderování i publika.

• Příjem: váš vysílací software, například OBS, posílá stream přes RTMP, protokol, který používají velké streamovací platformy.
• Doručení: Owncast dělí video na segmenty HLS v jedné nebo více kvalitách a nabízí ho na své webové stránce. Stream se přehraje i ve VLC nebo mpv, na /hls/stream.m3u8.
• Chat: zabudovaný do stránky, s moderátory, zákazy a přihlášením přes Fediverse nebo IndieAuth.
• Fediverse: účet Mastodon může váš server sledovat a dostat zprávu pokaždé, když začnete vysílat. Verze 0.3.0 přidává Featured Streams, které ukazují živá vysílání jiných serverů Owncast.
• Rozšíření: webhooky, API a od 0.3.0 pluginy, instalované ze správy s oprávněními, která jim udělíte.

Co dovoluje licence MIT

Owncast je vydáván pod licencí MIT. Ta bezplatně uděluje právo software používat, kopírovat, upravovat, slučovat, zveřejňovat, šířit, sublicencovat a prodávat jeho kopie. Můžete ho tedy provozovat pro svou firmu, svou komunitu nebo své klienty, aniž byste kupovali licenci.

Jedinou podmínkou je zachovat upozornění o autorských právech a text licence ve všech kopiích nebo podstatných částech softwaru. Text poskytuje software „tak, jak je“, bez záruky.

CPU a přenosové pásmo: dimenzování serveru

Dokumentace to říká hned na začátku: požadavky závisí na vaší konfiguraci. Stanoví ale jasné pravidlo, jak je odhadnout. CPU překóduje video do nabízených kvalit; přenosové pásmo ho doručí každému divákovi.

• Počet diváků zátěž CPU nemění. Video se zakóduje jednou a pak se nabízí všem: nula diváků, nebo sto, práce kódování je stejná. Chat přidává trochu zátěže, vedle kódování malé.
• Přenosové pásmo roste s každým divákem. Každý divák dostává vlastní kopii streamu.
• Každá překódovaná kvalita potřebuje CPU, tím víc, čím nižší je cílový datový tok, protože silnější komprese vyžaduje víc výpočtů.

Přenosové pásmo serveru

Dokumentace uvádí dva vzorce. Objem vysílání v gigabajtech: datový tok v kb/s × trvání v sekundách × diváci ÷ 8 000 000. Špičková odchozí rychlost, kterou je třeba udržet, v Mb/s: datový tok v kb/s × diváci ÷ 1 000. Při více kvalitách spočítejte každou a sečtěte je. Její odhady pro dvouhodinové vysílání:

Na VPS Simafri se provoz neměří po měsících: vaše vysílání se dimenzují podle špičkového datového toku. Jak vaše publikum roste, video místo serveru nabízí objektové úložiště, popsané níže.

CPU

Dokumentace uvádí naměřené orientační body a poznamenává, že se liší podle kodeku, datového toku, rozlišení a předvolby kodéru:

• Jedno jádro na kvalitu: jako hrubé pravidlo zvládne jedno jádro CPU často jednu překódovanou kvalitu při 30 snímcích za sekundu.
• Snímková frekvence: 60 snímků za sekundu vyžaduje zhruba dvojnásobek výpočtů oproti 30 a 24 snímků za sekundu zhruba 0,8násobek.
• Výchozí nastavení: Owncast začíná s jedinou kvalitou, 1 200 kb/s a 24 snímků za sekundu, se zvukem předávaným beze změny. Dokumentace radí začít tady, vyzkoušet a další kvalitu přidat, až bude mít CPU rezervu.

Dokumentace neuvádí žádný údaj o paměti a na disku záleží málo: segmenty videa se zapisují a v průběhu vysílání zase mažou. V čase roste jen složka data. Na VPS obstarává kódování CPU: každá překódovaná kvalita se dimenzuje ve vCPU. Na Managed VPS nám popište svá vysílání, jejich datový tok, kvality a své publikum a doporučíme vám vhodnou velikost.

Vaše vysílací připojení

Než stream dorazí na server, opouští vaše vlastní připojení. Dokumentace žádá rychlost odesílání alespoň 1,5násobku datového toku streamu: 7,5 Mb/s pro stream 5 000 kb/s. Doporučuje kabelové připojení místo Wi-Fi.

Instalace pomocí Docker Compose

Dokumentace nabízí obraz owncast/owncast na Docker Hubu, který obsahuje ffmpeg, kódovací nástroj, jejž Owncast potřebuje. Na serveru s nainstalovaným Dockerem vytvořte složku a umístěte do ní tento compose.yaml, převzatý z dokumentace:

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 publikovaný na 127.0.0.1: to je jediná změna oproti příkladu z dokumentace, který publikuje oba porty. Její stránka o reverzní proxy žádá, abyste Owncast nevystavovali přímo internetu, protože ve výchozím nastavení naslouchá na všech rozhraních, a Docker publikuje port na všech adresách serveru, když žádnou neuvedete. Webové rozhraní je pak dostupné jen přes reverzní proxy.
• Port 1935 přijímá stream přes RTMP. Zůstává veřejný, protože se k němu váš vysílací software připojuje přímo, bez průchodu proxy.
• Složka data uchovává databázi a její zálohy na serveru, mimo kontejner: tu zálohujete a přenášíte.
• Značka latest sleduje nejnovější vydání; 0.3.0 verzi pevně určí.

Bez Dockeru: oficiální instalátor

Druhou cestou dokumentace je skript, který stáhne nejnovější vydání Owncast pro vaši platformu, a ffmpeg, pokud ještě není k dispozici. Vše nainstaluje do složky owncast v aktuální složce. Dokumentace nedoporučuje spouštět ho jako root a doporučuje každý vzdálený skript před spuštěním přečíst:

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

Aby se Owncast spouštěl se serverem a po pádu se sám restartoval, nabízí dokumentace službu systemd, kterou přizpůsobíte zvolené složce a účtu:

[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

Heslo správce a klíč streamu

Správa se nachází na /admin. Owncast startuje s přístupovými údaji, které zná každý, a dokumentace žádá změnit je při prvním přihlášení:

Abyste tuto změnu provedli dřív, než bude rozhraní přístupné veřejnosti, použijte tunel SSH: port 8080 serveru se objeví na vašem počítači, na http://localhost:8080/admin. Přidejte -p a port SSH uvedený ve vašem zákaznickém prostoru.

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

• Heslo správce se mění v části „Configuration“, „Server Setup“. Musí mít 8 až 192 znaků, alespoň jedno malé písmeno, jedno velké písmeno, jednu číslici a jeden speciální znak z !@#$%^&* a nesmí nikde obsahovat spojovník.
• Klíče streamu se spravují na kartě „Stream Keys“ téže stránky. Owncast nabízí automaticky vygenerovaný klíč o 30 znacích a můžete jich mít několik, každý s komentářem: klíč předaný spoluvysílajícímu lze později zrušit, aniž byste se dotkli ostatních.
• Ztracené heslo se nahradí při spuštění příznakem --adminpassword, který ho uloží do databáze.

Heslo správce i klíč streamu začínají jako abc123, jsou to ale dvě samostatná nastavení: změňte obě.

HTTPS: reverzní proxy

Owncast HTTPS sám neobsluhuje. Dokumentace před něj staví reverzní proxy, která naslouchá na portech 80 a 443, získá certifikát, šifruje provoz a předává ho v nešifrované podobě Owncastu na port 8080. Bez HTTPS prohlížeče označí stránku jako nezabezpečenou a stránka obsluhovaná přes HTTPS nemůže vložit vaše video ani váš chat.

• Proxy předává všechny cesty, včetně připojení WebSocket na /ws, které nese chat. Proxy, která ho blokuje, chat odřízne.
• RTMP neprochází proxy: váš vysílací software posílá přímo na port 1935 Owncastu.
• Skutečná adresa návštěvníků: Owncast čte hlavičku X-Forwarded-For, aby zablokoval adresu IP uživatele, kterému byl zakázán chat. Dokumentace žádá, aby tuto hlavičku nastavovala sama proxy.

S Caddy

Dokumentace navrhuje Caddy, pokud nemáte jinou preferenci: certifikát Let’s Encrypt získá samo a WebSocket předává bez dalšího nastavení. Toto je její příklad Caddyfile, ve kterém řádek tls uvádí e-mailovou adresu účtu Let’s Encrypt:

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

S Nginx

U Nginx dokumentace zdůrazňuje WebSocket: když se na něj zapomene, chat nefunguje. Přidejte tento blok map do sekce http souboru /etc/nginx/nginx.conf:

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

Tento blok webu vychází z bloku v dokumentaci, na portu 80, aby HTTPS nasadil Certbot:

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

Vysílání přes RTMP z OBS

Owncast přijme jakýkoli software, který vysílá přes RTMP na vzdálený server. Klíč se přijímá jen na cestě /live. V OBS:

1. Otevřete „Nastavení“, pak „Vysílání“ a jako službu zvolte „Vlastní“.
2. Zadejte adresu rtmp://live.example.com:1935/live.
3. Zadejte svůj klíč streamu, ten z karty „Stream Keys“ v Owncastu.
4. Spusťte vysílání.

Software bez pole pro klíč přijme celou adresu, rtmp://live.example.com:1935/live/your-key.

Na VPS Simafri může adresa IPv6 serveru otevřít libovolný port: váš vysílací software se k portu 1935 dostane přes tuto adresu, pod jménem, které nese záznam AAAA. V síti Docker s IPv4, jako zde, Docker namapuje port na adrese IPv6 serveru na kontejner. Pokud je aktivní ufw, tento port otevřete a pak vyzkoušejte ze svého počítače:

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

Pro jakoukoli jinou potřebu nám popište, co máte v plánu, a adresování s vámi probereme.

Nastavení vašeho vysílacího softwaru

• Kodeky: H.264 pro video a AAC pro zvuk, jediné, u kterých je zaručeno překódování i kompatibilita přehrávání.
• Interval klíčových snímků: jeden každé 2 sekundy, nikdy ne „auto“. V OBS se interval udává v sekundách, tedy 2.
• Datový tok: posílejte to, co chcete nabídnout, nic víc. Pokud váš server zvládá 720p při 2 500 kb/s, neposílejte mu 1080p při 6 000 kb/s: každý převod, který požadujete, přidává zátěž CPU.

Kvality videa a latence

Kvality nabízené divákům se nastavují v části „Configuration“, „Video“. Více kvalit umožní přehrávači zvolit tu, kterou jeho připojení zvládne: dokumentace doporučuje druhou kvalitu, od 1 000 do 2 000 kb/s, vedle vysoké kvality od 4 000 do 6 000 kb/s, jakmile svou první konfiguraci vyzkoušíte.

• Datový tok: od 400 do 13 000 kb/s, po krocích 100.
• Snímková frekvence: od 24 do 120 snímků za sekundu, ve výchozím nastavení 24.
• Rozlišení: změňte šířku, nebo výšku, ne obojí, a Owncast zachová poměr stran.
• Využití CPU: pět úrovní. Čím vyšší úroveň, tím lepší obraz, nebo menší soubor při stejné kvalitě.

Passthrough předává příchozí video dál bez nového kódování: ušetří téměř všechno CPU této kvality a ignoruje její nastavení datového toku, rozlišení a snímkové frekvence. Dokumentace ho vyhrazuje pokročilým uživatelům: diváci dostávají přesně to, co posílá váš software, což některé přehrávače neumí přehrát, a latence roste. Než se na něj spolehnete, vyzkoušejte přehrávání na zařízeních, na kterých vám záleží.

Latence se nastavuje vyrovnávací pamětí latence na téže stránce. Každá úroveň vyměňuje trochu zpoždění za stabilitu a změna platí od dalšího vysílání:

Verze 0.3.0 přidává na straně diváka také volbu přehrávače „Minimize latency“, která přehrávání mírně zrychlí, aby se přiblížilo přímému přenosu, a nastavení automatického přehrávání, ve výchozím nastavení vypnuté.

Objektové úložiště pro více diváků

Owncast umí posílat své segmenty videa do úložiště kompatibilního s S3, odkud si je diváci stahují. Server dál nabízí hlavní playlist, API a chat; video, které tvoří téměř celé přenosové pásmo, přichází z úložiště. Váš server pak posílá jen jednu kopii každé kvality: v příkladu z dokumentace 6,5 Mb/s pro dvě kvality při 5 000 a 1 500 kb/s, ať máte nula diváků, nebo tisíc. Zátěž CPU zůstává stejná.

1. Vytvořte bucket u svého poskytovatele objektového úložiště.
2. Nastavte ho jako veřejně čitelný a nastavte zásady CORS, pokud je poskytovatel vyžaduje: chyba CORS nebo Access-Control-Allow-Origin v konzoli prohlížeče má téměř vždy původ právě tam.
3. V části „Configuration“, „Server Setup“, na kartě „S3 Object Storage“, zapněte úložiště a zadejte název bucketu, přístupový klíč, tajný klíč, koncový bod a region. Všechna tato pole jsou povinná.

Toto úložiště slouží živému vysílání, ne archivu: Owncast průběžně maže segmenty starší než playlist plus rezerva zhruba 20 segmentů. Bucket obsahuje jen posledních několik minut vysílání.

Pro diváky rozeseté po celém světě dokumentace popisuje také síť pro doručování obsahu (CDN) umístěnou před Owncast, se samostatným názvem hostitele pro zdroj a nastavením „Websocket host override“, které udržuje chat připojený ke zdrojovému serveru.

Chat a moderování

Chat se nastavuje v části „Configuration“, „Chat“. Ve výchozím nastavení nejsou žádní moderátoři: dokumentace navrhuje jmenovat moderátorem alespoň sebe, ze stránky „Users“ ve správě.

• Moderátoři skrývají zprávu nebo zakazují uživatele přímo z chatu. Do správy přístup nemají.
• Zákaz uživatele odpojí, odstraní jeho zprávy a zablokuje jeho známou adresu IP. Lze ho později zrušit; smazání uživatele je naproti tomu trvalé.
• Jen zavedení uživatelé: toto nastavení blokuje zprávy od účtů mladších 15 minut, s výjimkou moderátorů.
• Filtr jazyka odmítá urážlivé zprávy podle interního seznamu slov.
• Povinné ověření dovoluje posílat zprávy jen ověřeným uživatelům, přes účet ve Fediverse nebo IndieAuth, a moderátorům.
• Omezovač rychlosti, ve výchozím nastavení zapnutý, dovoluje zhruba jednu zprávu každé dvě třetiny sekundy a každého, kdo chat zahlcuje, zablokuje na 10 sekund.

Dokumentace upozorňuje, že blokování IP lze obejít, například pomocí VPN: zneužívání omezuje a moderování zůstává vlastní prací každého kanálu. Proto se u vašich nejsledovanějších vysílání vyplatí jmenovaní moderátoři.

Zálohy

Owncast zálohuje svou databázi sám jednou za hodinu, do data/backup/owncastdb.bak. Příznak --backupdir tuto složku změní. Takto vypadá obsah složky s daty:

Pro úplnou obnovu nebo přesun instance žádá dokumentace zálohovat celou složku data: její zkopírování do nové instalace přenese vše. S Dockerem, při zastavené službě:

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

Naplánujte tuto kopii podle svých vysílání a posílejte ji mimo server. Uložené na jeho disku se tyto archivy dostanou i do jeho nočních záloh.

Obnova databáze

Obnova vrátí databázi do okamžiku zálohy: vše, co se od té doby změnilo, se ztratí. Nejdřív zkopírujte stávající databázi na bezpečné místo a pak:

1. Zastavte Owncast.
2. Spusťte Owncast s --restoreDatabase a cestou k souboru zálohy: obnoví databázi a pak se ukončí.
3. Spusťte Owncast obvyklým způsobem a ve správě zkontrolujte svá nastavení.

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

Aktualizace

S Dockerem uvádí dokumentace dva příkazy, spuštěné ze složky se souborem compose.yaml. Složka s daty zůstává na místě:

docker compose pull
docker compose up -d

S instalátorem popisují poznámky k verzi 0.3.0 aktualizaci takto: zastavte službu, odložte stranou soubory webového rozhraní, které jste upravili, spusťte instalátor znovu pod účtem, který Owncast provozuje, a pak restartujte. Skript sám před nahrazením vydání uloží archiv složky data do owncast-install-backups.

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

Verze 0.3.0, vydaná 3. září 2026, přináší pluginy, Featured Streams, automatické přehrávání a volbu rozhraní, na kterém RTMP naslouchá. Její poznámky žádají přečíst si změny před aktualizací, protože se týkají vaší instance: sledujte tyto poznámky u každého vydání a těsně předtím zkopírujte složku data.

Kdo co dělá na Managed VPS

Vlastní hosting vyžaduje, abyste kromě aplikace udržovali i server. Na Managed VPS se serveru ujímají naše týmy a vaši instanci proaktivně sledují; Owncast zůstává vaším softwarem, s jeho nastavením a daty.

Pokud dáváte přednost tomu, aby naše týmy zasáhly přímo v aplikaci, tato služba se účtuje po hodinách nebo paušálem, s cenovou nabídkou sdělenou před zásahem.