Owncast hosztolása Managed VPS-en: élő adásai a saját szerverén

Mit tud az Owncast

Az Owncast nyílt forráskódú, saját üzemeltetésű, egyfelhasználós élővideó-közvetítő és csevegőszerver: egy példány egy személy vagy szervezet csatornáját hordozza. A README arra kínál módot, hogy a nagy, széles körben használt platformok mintájára saját élő adásokat üzemeltessen, miközben a tartalma, a felülete, a moderálás és a közönsége az Ön kezében marad.

• A fogadás: a közvetítőszoftvere, például az OBS, RTMP-n küldi az adást, azon a protokollon, amelyet a nagy streamingplatformok használnak.
• A kiszolgálás: az Owncast HLS-szegmensekre bontja a videót, egy vagy több minőségben, és a weboldalán szolgálja ki. Az adás a VLC-ben vagy az mpv-ben is lejátszható, a /hls/stream.m3u8 címen.
• A csevegés: az oldalba építve, moderátorokkal, kitiltásokkal és a Fediverse-en vagy az IndieAuthon keresztüli bejelentkezéssel.
• A Fediverse: egy Mastodon-fiók követheti a szerverét, és értesítést kaphat minden élő adásának indulásakor. A 0.3.0-s verzió hozzáadja a Featured Streams funkciót, amely más Owncast-szerverek élő adásait mutatja.
• A bővíthetőség: webhookok, API-k és a 0.3.0-s verzió óta bővítmények, amelyeket az adminisztrációs felületről telepít, az Ön által megadott jogosultságokkal.

Mit enged meg az MIT licenc

Az Owncast az MIT licenc alatt jelenik meg. Ez ingyenesen biztosítja a szoftver használatának, másolásának, módosításának, egyesítésének, közzétételének, terjesztésének, allicencbe adásának és másolatai értékesítésének jogát. Futtathatja tehát a vállalkozásához, a közösségéhez vagy az ügyfeleihez, licenc vásárlása nélkül.

Az egyetlen feltétel a szerzői jogi megjegyzés és a licenc szövegének megtartása a szoftver minden másolatában vagy lényeges részében. A szöveg a szoftvert „ahogy van” állapotban, garancia nélkül adja.

Processzor és sávszélesség: a szerver méretezése

A dokumentáció rögtön az elején kimondja: az igények a konfigurációjától függenek. Ugyanakkor világos szabályt ad a becslésükhöz. A processzor a felkínált minőségekbe kódolja át a videót; a sávszélesség eljuttatja minden nézőhöz.

• A nézők száma nem változtat a processzor terhelésén. A videó egyszer kódolódik, majd mindenkinek kiszolgálódik: nulla néző vagy száz, a kódolási munka ugyanaz. A csevegés kevés terhelést ad hozzá, a kódoláshoz képest csekélyt.
• A sávszélesség minden nézővel nő. Minden néző a saját másolatát kapja az adásból.
• Minden átkódolt minőséghez processzor kell, annál több, minél alacsonyabb a cél-bitráta, mivel az erősebb tömörítés több számítást igényel.

A szerver sávszélessége

A dokumentáció két képletet ad meg. Egy adás adatmennyisége gigabájtban: bitráta kbps-ben × időtartam másodpercben × nézők ÷ 8 000 000. A fenntartandó kimenő csúcssebesség Mbps-ben: bitráta kbps-ben × nézők ÷ 1000. Több minőség esetén számolja ki mindegyiket, és adja össze őket. A dokumentáció becslései egy kétórás adásra:

Simafri VPS-en a forgalomnak nincs havi mérője: az adásait a csúcsbitrátájuk alapján méretezzük. Ahogy a közönsége nő, az alább ismertetett objektumtároló a szerver helyett szolgálja ki a videót.

A processzor

A dokumentáció mért viszonyítási pontokat ad, megjegyezve, hogy ezek a kodektől, a bitrátától, a felbontástól és a kódolási előbeállítástól függően változnak:

• Minőségenként egy mag: durva ökölszabályként egyetlen processzormag gyakran elbír egy átkódolt minőséget másodpercenként 30 képkockával.
• A képkockasebesség: a másodpercenkénti 60 képkocka nagyjából kétszer annyi számítást igényel, mint a 30, a 24 képkocka pedig nagyjából 0,8-szeresét.
• Az alapbeállítás: az Owncast egyetlen minőséggel indul, 1200 kbps-sel és másodpercenként 24 képkockával, a hangot érintetlenül továbbítva. A dokumentáció azt tanácsolja, hogy innen induljon, teszteljen, majd adjon hozzá egy minőséget, amikor a processzornak van tartaléka.

A dokumentáció nem ad meg memóriaigényt, és a lemez kevéssé számít: a videószegmensek az adás során íródnak, majd törlődnek. Idővel csak a data mappa nő. VPS-en a processzor végzi a kódolást: minden átkódolt minőség vCPU-kban méretezendő. Egy Managed VPS esetén írja le nekünk az adásait, a bitrátájukat, a minőségeiket és a közönségét, és mi azt a méretet javasoljuk, amely megfelel.

Az Ön közvetítési kapcsolata

Mielőtt a szerverhez érne, az adás az Ön saját internetkapcsolatáról indul. A dokumentáció az adás bitrátájának legalább 1,5-szeresét kéri feltöltési sebességként: 5000 kbps-es adáshoz 7,5 Mbps-t. A Wi-Fi helyett vezetékes kapcsolatot ajánl.

Telepítés Docker Compose-zal

A dokumentáció a Docker Hubon elérhető owncast/owncast image-et kínálja, amely tartalmazza az ffmpeget, az Owncast számára szükséges kódolóeszközt. Egy olyan szerveren, ahol a Docker telepítve van, hozzon létre egy mappát, és helyezze bele ezt a compose.yaml fájlt, amely a dokumentációból származik:

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

• A 127.0.0.1 címen közzétett 8080-as port: ez az egyetlen eltérés a dokumentáció példájától, amely mindkét portot közzéteszi. A fordított proxyról szóló oldala azt kéri, hogy az Owncastot ne tegye ki közvetlenül az internetre, mivel alapértelmezésként minden interfészen figyel, a Docker pedig cím megadása nélkül a szerver összes címén közzéteszi a portot. A webes felület így kizárólag a fordított proxyn keresztül érhető el.
• Az 1935-ös port RTMP-n fogadja az adást. Nyilvános marad, mert a közvetítőszoftvere közvetlenül éri el, a proxy megkerülésével.
• A data mappa a szerveren, a konténeren kívül őrzi az adatbázist és a mentéseit: ezt menti és ezt költözteti.
• A latest címke a legutóbbi kiadást követi; a 0.3.0 rögzít egy verziót.

Docker nélkül: a hivatalos telepítő

A dokumentáció másik útja egy szkript, amely letölti az Owncast legutóbbi kiadását az Ön platformjára, és az ffmpeget is, ha még nincs a gépen. Mindent egy owncast mappába telepít az aktuális mappán belül. A dokumentáció azt tanácsolja, hogy ne root-ként futtassa, és hogy minden távoli szkriptet olvasson el, mielőtt futtatja:

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

Ahhoz, hogy az Owncast a szerverrel együtt induljon, és egy összeomlás után magától újrainduljon, a dokumentáció egy systemd szolgáltatást ad, amelyet a választott mappához és fiókhoz kell igazítani:

[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

Adminisztrátori jelszó és streamkulcs

Az adminisztrációs felület a /admin címen érhető el. Az Owncast mindenki által ismert hozzáférési adatokkal indul, amelyeket a dokumentáció az első bejelentkezéskor kér módosítani:

Ahhoz, hogy ezt a módosítást még a felület nyilvánossá válása előtt elvégezze, használjon SSH-alagutat: a szerver 8080-as portja megjelenik a számítógépén, a http://localhost:8080/admin címen. Adja hozzá a -p kapcsolót és az ügyfélterületén feltüntetett SSH-portot.

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

• Az adminisztrátori jelszó a „Configuration”, „Server Setup” menüpont alatt módosítható. 8 és 192 karakter közötti hosszúságú lehet, legalább egy kisbetűvel, egy nagybetűvel, egy számjeggyel és egy speciális karakterrel a !@#$%^&* közül, és sehol sem tartalmazhat kötőjelet.
• A streamkulcsok ugyanennek az oldalnak a „Stream Keys” lapján kezelhetők. Az Owncast automatikusan generált, 30 karakteres kulcsot kínál, és több kulcsot is tarthat, mindegyiket megjegyzéssel: egy műsortársnak adott kulcs később visszavonható a többi érintése nélkül.
• Az elfelejtett jelszó indításkor az --adminpassword kapcsolóval cserélhető le, amely az adatbázisba menti.

Az adminisztrátori jelszó és a streamkulcs egyaránt abc123 értékkel indul, de két külön beállításról van szó: módosítsa mindkettőt.

HTTPS: a fordított proxy

Az Owncast maga nem kezeli a HTTPS-t. A dokumentáció fordított proxyt helyez elé, amely a 80-as és a 443-as porton figyel, megszerzi a tanúsítványt, titkosítja a forgalmat, és titkosítatlanul továbbítja az Owncastnak a 8080-as portra. HTTPS nélkül a böngészők nem biztonságosnak jelölik az oldalt, és egy HTTPS-en kiszolgált oldal nem tudja beágyazni a videóját vagy a csevegését.

• A proxy minden útvonalat továbbít, a /ws címen futó WebSocket-kapcsolatot is, amely a csevegést hordozza. Egy azt blokkoló proxy megszakítja a csevegést.
• Az RTMP nem halad át a proxyn: a közvetítőszoftvere közvetlenül az Owncast 1935-ös portjára küld.
• A látogatók valódi címe: az Owncast az X-Forwarded-For fejlécet olvassa, hogy letiltsa a csevegésből kitiltott felhasználó IP-címét. A dokumentáció azt kéri, hogy ezt a fejlécet maga a proxy állítsa be.

Caddyvel

A dokumentáció a Caddyt javasolja, ha nincs más preferenciája: magától megszerzi a Let's Encrypt-tanúsítványt, és külön beállítás nélkül továbbítja a WebSocketet. Íme a Caddyfile-példája, amelyben a tls sor a Let's Encrypt-fiók e-mail-címét adja meg:

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

Nginxszel

Nginx esetén a dokumentáció a WebSocketet hangsúlyozza: ha kimarad, a csevegés nem működik. Adja hozzá ezt a map blokkot az /etc/nginx/nginx.conf fájl http részéhez:

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

Ez a webhelyblokk a dokumentációét követi, a 80-as porton, hogy a Certbot beállíthassa a HTTPS-t:

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

Közvetítés RTMP-n az OBS-ből

Az Owncast minden olyan szoftvert elfogad, amely RTMP-n közvetít egy távoli szerverre. A kulcsot csak a /live útvonalon fogadja el. Az OBS-ben:

1. Nyissa meg a „Settings” (Beállítások), majd a „Stream” menüt, és szolgáltatásként válassza a „Custom” (egyéni) lehetőséget.
2. Adja meg az rtmp://live.example.com:1935/live címet.
3. Adja meg a streamkulcsát, azt, amelyik az Owncast „Stream Keys” lapján szerepel.
4. Indítsa el a közvetítést.

Az olyan szoftver, amelynek nincs mezője a kulcshoz, a teljes címet fogadja el: rtmp://live.example.com:1935/live/your-key.

Simafri VPS-en a szerver IPv6-címén bármelyik választott port megnyitható: a közvetítőszoftvere ezen a címen éri el az 1935-ös portot, egy olyan néven, amely az AAAA rekordot hordozza. Egy IPv4-es Docker-hálózaton, mint itt, a Docker a szerver IPv6-címén lévő portot a konténerhez rendeli. Nyissa meg ezt a portot, ha az ufw aktív, majd teszteljen a számítógépéről:

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

Bármilyen más igény esetén írja meg nekünk, mit tervez, és közösen megnézzük a címzést.

A közvetítőszoftver beállításai

• A kodekek: H.264 a videóhoz és AAC a hanghoz, az egyetlenek, amelyeknél az átkódolás és a lejátszási kompatibilitás biztosított.
• A kulcskocka-intervallum: 2 másodpercenként egy, soha nem „auto” értéken hagyva. Az OBS-ben az intervallum másodpercben értendő, tehát 2.
• A bitráta: azt küldje, amit kínálni szeretne, ne többet. Ha a szervere 720p-t bír 2500 kbps-sel, ne küldjön neki 1080p-t 6000 kbps-sel: minden kért átalakítás processzorterhelést ad hozzá.

Videóminőségek és késleltetés

A nézőknek felkínált minőségek a „Configuration”, „Video” menüpont alatt állíthatók be. Több minőség esetén a lejátszó azt választhatja, amelyet a kapcsolata elbír: a dokumentáció egy második, 1000 és 2000 kbps közötti minőséget ajánl egy 4000 és 6000 kbps közötti magas minőség mellé, miután az első konfigurációját kipróbálta.

• A bitráta: 400 és 13 000 kbps között, 100-as lépésekben.
• A képkockasebesség: másodpercenként 24 és 120 képkocka között, alapértelmezésként 24.
• A felbontás: a szélességet vagy a magasságot módosítsa, ne mindkettőt, és az Owncast megtartja a képarányt.
• A processzorhasználat: öt szint. Minél magasabb a szint, annál jobb a kép, vagy annál kisebb a fájl azonos minőség mellett.

A passthrough újrakódolás nélkül továbbítja a beérkező videót: az adott minőség processzorigényének szinte egészét megtakarítja, és figyelmen kívül hagyja a bitráta-, felbontás- és képkockasebesség-beállításait. A dokumentáció a haladó felhasználóknak tartja fenn: a nézők pontosan azt kapják, amit a szoftvere küld, amit egyes lejátszók nem tudnak lejátszani, és a késleltetés nő. Mielőtt erre építene, tesztelje a lejátszást az Ön számára fontos eszközökön.

A késleltetés ugyanezen az oldalon, a késleltetési pufferrel állítható be. Minden szint egy kis késést cserél stabilitásra, és a módosítás a következő adástól érvényes:

A 0.3.0-s verzió a nézők oldalán a lejátszó „Minimize latency” (késleltetés minimalizálása) opcióját is hozzáadja, amely kissé gyorsítja a lejátszást, hogy közelebb kerüljön az élő adáshoz, valamint egy automatikus lejátszási beállítást, amely alapértelmezésként ki van kapcsolva.

Objektumtároló több néző kiszolgálásához

Az Owncast a videószegmenseit S3-kompatibilis tárolóba küldheti, ahonnan a nézők letöltik őket. A szerver továbbra is kiszolgálja a fő lejátszási listát, az API-kat és a csevegést; a videó, amely a sávszélesség szinte egészét teszi ki, a tárolóból érkezik. A szervere ekkor minőségenként csak egy másolatot küld: a dokumentáció példájában 6,5 Mbps-t két, 5000 és 1500 kbps-es minőségre, akár nulla, akár ezer nézője van. A processzorterhelés ugyanaz marad.

1. Hozzon létre egy bucketet az objektumtároló-szolgáltatójánál.
2. Tegye nyilvánosan olvashatóvá, és állítson be CORS-szabályzatot, ha a szolgáltató megköveteli: a böngészőkonzolban megjelenő CORS vagy Access-Control-Allow-Origin hiba szinte mindig innen ered.
3. A „Configuration”, „Server Setup” menüpont „S3 Object Storage” lapján kapcsolja be a tárolót, és adja meg a bucket nevét, a hozzáférési kulcsot, a titkos kulcsot, a végpontot és a régiót. Mindegyik mező kötelező.

Ez a tároló az élő adást szolgálja ki, nem archívum: az Owncast menet közben törli azokat a szegmenseket, amelyek régebbiek a lejátszási listánál és egy nagyjából 20 szegmensnyi puffernél. A bucket csak az adás utolsó néhány percét tartalmazza.

A világ különböző pontjain élő nézők számára a dokumentáció egy Owncast elé helyezett tartalomkézbesítő hálózatot (CDN) is leír, külön forrásgépnévvel és a „Websocket host override” beállítással, amely a csevegést a forrásszerverhez kapcsolva tartja.

Csevegés és moderálás

A csevegés a „Configuration”, „Chat” menüpont alatt állítható be. Alapértelmezésként nincsenek moderátorok: a dokumentáció azt javasolja, hogy legalább saját magát tegye azzá, az adminisztrációs felület „Users” oldaláról.

• A moderátorok magából a csevegésből rejtenek el egy üzenetet vagy tiltanak ki egy felhasználót. Az adminisztrációs felülethez nincs hozzáférésük.
• A kitiltás lecsatlakoztatja a felhasználót, eltávolítja az üzeneteit, és letiltja az ismert IP-címét. Később feloldható; egy felhasználó törlése viszont végleges.
• Csak régebbi felhasználók: ez a beállítás blokkolja a 15 percnél fiatalabb fiókok üzeneteit, a moderátorok kivételével.
• A nyelvi szűrő egy belső szólista alapján elutasítja a sértő üzeneteket.
• A kötelező hitelesítés csak a Fediverse-fiókkal vagy IndieAuthtal hitelesített felhasználóknak és a moderátoroknak engedi az üzenetküldést.
• A sebességkorlátozó, amely alapértelmezésként be van kapcsolva, nagyjából kétharmad másodpercenként egy üzenetet enged, és 10 másodpercre letiltja azt, aki elárasztja a csevegést.

A dokumentáció rámutat, hogy az IP-alapú letiltás megkerülhető, például VPN-nel: visszaszorítja a visszaéléseket, a moderálás pedig minden csatorna saját feladata marad. Ezért érdemes név szerint megnevezett moderátorokat kijelölni a legnézettebb adásaihoz.

A mentések

Az Owncast óránként egyszer menti a saját adatbázisát a data/backup/owncastdb.bak fájlba. A --backupdir kapcsoló megváltoztatja ezt a mappát. Íme, mit tartalmaz az adatmappa:

A teljes helyreállításhoz vagy a példány költöztetéséhez a dokumentáció a teljes data mappa mentését kéri: ha egy új telepítésbe másolja, minden átkerül. Dockerrel, leállított szolgáltatás mellett:

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

Ütemezze ezt a másolást az adásaihoz igazodva, és küldje a szerveren kívülre. A szerver lemezére téve ezek az archívumok a szerver éjszakai mentéseibe is bekerülnek.

Az adatbázis visszaállítása

A visszaállítás a mentés időpontjára állítja vissza az adatbázist: ami azóta változott, elvész. Először másolja biztonságos helyre a jelenlegi adatbázist, majd:

1. Állítsa le az Owncastot.
2. Indítsa el az Owncastot a --restoreDatabase kapcsolóval és a mentési fájl elérési útjával: visszaállítja az adatbázist, majd kilép.
3. Indítsa el az Owncastot a szokásos módon, majd ellenőrizze a beállításait az adminisztrációs felületen.

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

A frissítések

Docker esetén a dokumentáció két parancsot ad meg, a compose.yaml mappájából futtatva. Az adatmappa a helyén marad:

docker compose pull
docker compose up -d

A telepítő esetén a 0.3.0-s verzió kiadási megjegyzései leírják a frissítést: állítsa le a szolgáltatást, tegye félre a webes felület általa testreszabott fájljait, futtassa újra a telepítőt az Owncastot futtató fiókkal, majd indítsa újra. Maga a szkript a kiadás lecserélése előtt archívumot ment a data mappáról az owncast-install-backups mappába.

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

A 2026. szeptember 3-án megjelent 0.3.0-s verzió a bővítményeket, a Featured Streams funkciót, az automatikus lejátszást és annak az interfésznek a kiválasztását hozza, amelyen az RTMP figyel. A megjegyzései azt kérik, hogy frissítés előtt olvassa el a változásokat, mert érintik a példányát: kövesse ezeket a megjegyzéseket minden kiadásnál, és közvetlenül előtte másolja a data mappát.

Ki mit csinál egy Managed VPS-en

A saját üzemeltetés az alkalmazás mellett a szerver gondozását is megköveteli. Egy Managed VPS esetén csapataink átveszik a szervert, és proaktívan követik a példányát; az Owncast továbbra is az Ön szoftvere marad, a beállításaival és az adataival.

Ha inkább azt szeretné, hogy csapataink magában az alkalmazásban avatkozzanak be, ez a szolgáltatás óradíjban vagy átalánydíjban számlázódik, a beavatkozás előtt közölt árajánlattal.