Găzduirea Owncast pe un Managed VPS: transmisiunile live pe propriul server

Ce face Owncast

Owncast este un server open source de transmisiuni video live și de chat, găzduit pe propriul server și cu un singur utilizator: o instanță poartă canalul unei singure persoane sau organizații. README-ul său îl prezintă ca pe un mijloc de a vă difuza propriile transmisiuni live, în stilul marilor platforme publice, păstrând controlul asupra conținutului, interfeței, moderării și publicului dumneavoastră.

• Recepția: software-ul dumneavoastră de difuzare, precum OBS, trimite fluxul prin RTMP, protocolul folosit de marile platforme de streaming.
• Livrarea: Owncast împarte video-ul în segmente HLS, într-una sau mai multe calități, și îl servește pe pagina sa web. Fluxul se redă și în VLC sau mpv, la /hls/stream.m3u8.
• Chatul: integrat în pagină, cu moderatori, excluderi și conectare prin Fediverse sau IndieAuth.
• Fediverse: un cont Mastodon vă poate urmări serverul și poate fi anunțat de fiecare dată când intrați în direct. Versiunea 0.3.0 adaugă Featured Streams, care afișează transmisiunile live ale altor servere Owncast.
• Extinderea: webhookuri, API-uri și, începând cu 0.3.0, pluginuri, instalate din administrare cu permisiunile pe care le acordați.

Ce permite licența MIT

Owncast este publicat sub licența MIT. Ea acordă gratuit dreptul de a folosi, copia, modifica, fuziona, publica, distribui, sublicenția și vinde copii ale software-ului. Îl puteți deci rula pentru firma, comunitatea sau clienții dumneavoastră, fără nicio licență de cumpărat.

Singura condiție este păstrarea mențiunii de copyright și a textului licenței în toate copiile sau părțile substanțiale ale software-ului. Textul furnizează software-ul „ca atare” („as is”), fără garanție.

Procesorul și lățimea de bandă: dimensionarea serverului

Documentația o spune de la început: cerințele depind de configurația dumneavoastră. Ea formulează totuși o regulă clară pentru a le estima. Procesorul transcodează video-ul în calitățile pe care le oferiți; lățimea de bandă îl livrează fiecărui spectator.

• Numărul de spectatori nu schimbă sarcina procesorului. Video-ul este codat o singură dată, apoi servit tuturor: zero spectatori sau o sută, munca de codare este aceeași. Chatul adaugă o sarcină mică, neglijabilă față de codare.
• Lățimea de bandă crește cu fiecare spectator. Fiecare spectator primește propria copie a fluxului.
• Fiecare calitate transcodată cere procesor, cu atât mai mult cu cât debitul țintă este mai mic, deoarece o compresie mai puternică cere mai multe calcule.

Lățimea de bandă a serverului

Documentația dă două formule. Volumul unei transmisiuni, în gigaocteți: debitul în kbps × durata în secunde × spectatorii ÷ 8.000.000. Viteza de ieșire maximă de susținut, în Mbps: debitul în kbps × spectatorii ÷ 1.000. Cu mai multe calități, calculați-le pe fiecare și adunați-le. Estimările sale pentru o transmisiune de două ore:

Pe un VPS Simafri, traficul nu are contor lunar: transmisiunile dumneavoastră se dimensionează după debitul lor de vârf. Pe măsură ce publicul crește, stocarea de obiecte, prezentată mai jos, servește video-ul în locul serverului.

Procesorul

Documentația dă repere măsurate, precizând că ele variază în funcție de codec, debit, rezoluție și presetarea codorului:

• Un nucleu pe calitate: ca regulă aproximativă, un singur nucleu de procesor poate gestiona adesea o calitate transcodată la 30 de cadre pe secundă.
• Frecvența cadrelor: 60 de cadre pe secundă cer aproximativ de două ori mai multe calcule decât 30, iar 24 de cadre pe secundă aproximativ de 0,8 ori.
• Setarea implicită: Owncast pornește cu o singură calitate, la 1.200 kbps și 24 de cadre pe secundă, cu sunetul transmis neschimbat. Documentația sfătuiește să porniți de aici, să testați, apoi să adăugați o calitate când procesorul are rezervă.

Documentația nu indică nicio cifră pentru memorie, iar discul contează puțin: segmentele video sunt scrise, apoi șterse pe măsură ce transmisiunea avansează. Doar directorul data crește în timp. Pe un VPS, procesorul face codarea: fiecare calitate transcodată se dimensionează în vCPU. Pe un Managed VPS, descrieți-ne transmisiunile dumneavoastră, debitul lor, calitățile și publicul, și vă recomandăm dimensiunea potrivită.

Conexiunea dumneavoastră de difuzare

Înainte de a ajunge la server, fluxul pleacă de pe propria dumneavoastră conexiune. Documentația cere o viteză de upload de cel puțin 1,5 ori debitul fluxului: 7,5 Mbps pentru un flux de 5.000 kbps. Ea recomandă o conexiune prin cablu mai degrabă decât Wi-Fi.

Instalarea cu Docker Compose

Documentația propune imaginea owncast/owncast de pe Docker Hub, care include ffmpeg, instrumentul de codare de care are nevoie Owncast. Pe un server unde Docker este instalat, creați un director și puneți în el acest compose.yaml, preluat din documentație:

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

• Portul 8080 publicat pe 127.0.0.1: este singura modificare față de exemplul din documentație, care publică ambele porturi. Pagina sa despre proxy-ul invers cere să țineți Owncast departe de internet, deoarece ascultă implicit pe toate interfețele, iar Docker publică un port pe toate adresele serverului când nu i se indică niciuna. Interfața web este atunci accesibilă doar prin proxy-ul invers.
• Portul 1935 primește fluxul prin RTMP. El rămâne public, deoarece software-ul dumneavoastră de difuzare ajunge direct la el, fără a trece prin proxy.
• Directorul data păstrează baza de date și backupurile ei pe server, în afara containerului: pe el îl salvați și îl mutați.
• Eticheta latest urmărește cea mai recentă versiune; 0.3.0 fixează o versiune.

Fără Docker: programul de instalare oficial

Cealaltă cale din documentație este un script care descarcă ultima versiune Owncast pentru platforma dumneavoastră, precum și ffmpeg, dacă nu există deja. El instalează totul într-un director owncast sub cel curent. Documentația descurajează rularea lui ca root și recomandă să citiți orice script la distanță înainte de a-l rula:

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

Pentru ca Owncast să pornească odată cu serverul și să repornească singur după o cădere, documentația furnizează un serviciu systemd, de adaptat la directorul și contul alese:

[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

Parola de administrare și cheia de transmisie

Administrarea se află la /admin. Owncast pornește cu date de acces cunoscute de toată lumea, pe care documentația cere să le schimbați la prima conectare:

Pentru a face această schimbare înainte ca interfața să fie deschisă publicului, treceți printr-un tunel SSH: portul 8080 al serverului apare pe computerul dumneavoastră, la http://localhost:8080/admin. Adăugați -p și portul SSH indicat în spațiul dumneavoastră de client.

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

• Parola de administrare se schimbă în „Configuration”, „Server Setup”. Ea cere între 8 și 192 de caractere, cel puțin o literă mică, o literă mare, o cifră și un caracter special dintre !@#$%^&*, și nicio cratimă.
• Cheile de transmisie se gestionează în fila „Stream Keys” a aceleiași pagini. Owncast propune o cheie generată automat, de 30 de caractere, și puteți păstra mai multe, fiecare cu un comentariu: o cheie dată unui coprezentator poate fi revocată ulterior fără a le atinge pe celelalte.
• O parolă pierdută se înlocuiește la pornire cu opțiunea --adminpassword, care o înregistrează în baza de date.

Parola de administrare și cheia de transmisie pornesc amândouă cu abc123, dar sunt două setări distincte: schimbați-le pe amândouă.

HTTPS: proxy-ul invers

Owncast nu gestionează el însuși HTTPS. Documentația plasează în fața lui un proxy invers, care ascultă pe porturile 80 și 443, obține certificatul, criptează traficul și îl transmite necriptat către Owncast, pe portul 8080. Fără HTTPS, browserele semnalează pagina ca nesigură, iar o pagină servită în HTTPS nu poate integra nici video-ul, nici chatul dumneavoastră.

• Proxy-ul transmite toate căile, inclusiv conexiunea WebSocket de la /ws, care poartă chatul. Un proxy care o blochează întrerupe chatul.
• RTMP nu trece prin proxy: software-ul dumneavoastră de difuzare trimite direct către portul 1935 al Owncast.
• Adresa reală a vizitatorilor: Owncast citește antetul X-Forwarded-For pentru a bloca adresa IP a unui utilizator exclus din chat. Documentația cere ca proxy-ul să seteze el însuși acest antet.

Cu Caddy

Documentația sugerează Caddy dacă nu aveți altă preferință: el obține singur un certificat Let’s Encrypt și transmite WebSocket fără nicio setare suplimentară. Iată exemplul său de Caddyfile, în care linia tls indică adresa de e-mail a contului Let’s Encrypt:

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

Cu Nginx

Cu Nginx, documentația insistă asupra WebSocket: dacă îl omiteți, chatul nu mai funcționează. Adăugați acest bloc map în secțiunea http din /etc/nginx/nginx.conf:

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

Acest bloc de site îl preia pe cel din documentație, pe portul 80, pentru a lăsa Certbot să instaleze HTTPS:

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

Difuzarea prin RTMP din OBS

Owncast acceptă orice software care difuzează prin RTMP către un server la distanță. Cheia este acceptată doar pe calea /live. În OBS:

1. Deschideți „Settings”, apoi „Stream”, și alegeți „Custom” ca serviciu.
2. Introduceți adresa rtmp://live.example.com:1935/live.
3. Introduceți cheia dumneavoastră de transmisie, cea din fila „Stream Keys” a Owncast.
4. Porniți difuzarea.

Un software fără câmp pentru cheie acceptă adresa completă, rtmp://live.example.com:1935/live/your-key.

Pe un VPS Simafri, adresa IPv6 a serverului poate deschide orice port doriți: software-ul dumneavoastră de difuzare ajunge la portul 1935 prin această adresă, sub un nume care poartă înregistrarea AAAA. Pe o rețea Docker IPv4, ca aici, Docker leagă portul de pe adresa IPv6 a serverului de container. Deschideți acest port dacă ufw este activ, apoi testați de pe computerul dumneavoastră:

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

Pentru orice altă nevoie, spuneți-ne ce aveți în vedere și analizăm împreună adresarea.

Setările software-ului dumneavoastră de difuzare

• Codecurile: H.264 pentru video și AAC pentru sunet, singurele pentru care transcodarea și compatibilitatea redării sunt asigurate.
• Intervalul cadrelor-cheie: unul la fiecare 2 secunde, niciodată lăsat pe „auto”. În OBS, intervalul se exprimă în secunde, deci 2.
• Debitul: trimiteți ce intenționați să oferiți, nu mai mult. Dacă serverul dumneavoastră gestionează 720p la 2.500 kbps, nu îi trimiteți 1080p la 6.000 kbps: fiecare conversie pe care o cereți adaugă sarcină procesorului.

Calitățile video și latența

Calitățile oferite spectatorilor se setează în „Configuration”, „Video”. Mai multe calități îi permit playerului să o aleagă pe cea pe care conexiunea sa o poate susține: documentația recomandă o a doua calitate, de 1.000 până la 2.000 kbps, alături de o calitate înaltă de 4.000 până la 6.000 kbps, după ce prima configurație a fost testată.

• Debitul: de la 400 la 13.000 kbps, în pași de 100.
• Frecvența cadrelor: de la 24 la 120 de cadre pe secundă, 24 implicit.
• Rezoluția: modificați lățimea sau înălțimea, nu pe amândouă, iar Owncast păstrează proporțiile.
• Utilizarea procesorului: cinci niveluri. Cu cât nivelul este mai ridicat, cu atât imaginea este mai bună sau fișierul mai mic la calitate egală.

Passthrough transmite video-ul primit fără să îl recodeze: economisește aproape tot procesorul acelei calități și ignoră setările ei de debit, rezoluție și frecvență a cadrelor. Documentația îl rezervă utilizatorilor avansați: spectatorii primesc exact ce trimite software-ul dumneavoastră, pe care unele playere nu îl pot reda, iar latența crește. Testați redarea pe dispozitivele care contează pentru dumneavoastră înainte de a vă baza pe el.

Latența se reglează cu bufferul de latență, pe aceeași pagină. Fiecare nivel schimbă puțină întârziere pe stabilitate, iar o modificare se aplică de la următoarea transmisiune:

Versiunea 0.3.0 adaugă și, de partea spectatorului, opțiunea „Minimize latency” a playerului, care accelerează ușor redarea pentru a se apropia de direct, precum și o setare de redare automată, dezactivată implicit.

Stocarea de obiecte pentru a servi mai mulți spectatori

Owncast își poate trimite segmentele video către un spațiu de stocare compatibil S3, de unde spectatorii le descarcă. Serverul servește în continuare playlistul principal, API-urile și chatul; video-ul, care reprezintă aproape toată lățimea de bandă, vine din spațiul de stocare. Serverul dumneavoastră trimite atunci o singură copie a fiecărei calități: în exemplul din documentație, 6,5 Mbps pentru două calități de 5.000 și 1.500 kbps, fie că aveți zero spectatori, fie o mie. Sarcina procesorului rămâne aceeași.

1. Creați un bucket la furnizorul dumneavoastră de stocare de obiecte.
2. Faceți-l accesibil public la citire și setați o politică CORS dacă furnizorul o cere: o eroare CORS sau Access-Control-Allow-Origin în consola browserului vine aproape întotdeauna de aici.
3. În „Configuration”, „Server Setup”, fila „S3 Object Storage”, activați stocarea și introduceți numele bucketului, cheia de acces, cheia secretă, endpointul și regiunea. Toate aceste câmpuri sunt obligatorii.

Acest spațiu de stocare servește transmisiunea live, nu o arhivă: Owncast șterge, pe parcurs, segmentele mai vechi decât playlistul plus o rezervă de aproximativ 20 de segmente. Bucketul păstrează doar ultimele minute ale transmisiunii.

Pentru spectatori răspândiți în toată lumea, documentația descrie și o rețea de livrare de conținut (CDN) plasată în fața Owncast, cu un nume de gazdă de origine separat și setarea „Websocket host override”, care menține chatul conectat la serverul de origine.

Chatul și moderarea

Chatul se configurează în „Configuration”, „Chat”. Implicit, nu există niciun moderator: documentația sugerează să vă numiți cel puțin pe dumneavoastră, din pagina „Users” a administrării.

• Moderatorii ascund un mesaj sau exclud un utilizator direct din chat. Ei nu au acces la administrare.
• O excludere deconectează utilizatorul, îi șterge mesajele și îi blochează adresa IP cunoscută. Ea poate fi ridicată ulterior; ștergerea unui utilizator, în schimb, este definitivă.
• Doar utilizatorii stabiliți: această setare blochează mesajele conturilor mai noi de 15 minute, cu excepția moderatorilor.
• Filtrul de limbaj respinge mesajele jignitoare, pe baza unei liste interne de cuvinte.
• Autentificarea obligatorie le permite să trimită mesaje doar utilizatorilor autentificați, printr-un cont Fediverse sau IndieAuth, și moderatorilor.
• Limitatorul de ritm, activ implicit, permite aproximativ un mesaj la fiecare două treimi de secundă și blochează pentru 10 secunde pe oricine inundă chatul.

Documentația subliniază că blocarea IP poate fi ocolită, cu un VPN de exemplu: ea limitează abuzurile, iar moderarea rămâne treaba fiecărui canal. De aici valoarea moderatorilor numiți pentru transmisiunile dumneavoastră cele mai urmărite.

Backupurile

Owncast își salvează singur baza de date o dată pe oră, în data/backup/owncastdb.bak. Opțiunea --backupdir schimbă acest director. Iată ce conține directorul de date:

Pentru o recuperare completă sau pentru a muta instanța, documentația cere să salvați întregul director data: copierea lui pe o instalare nouă transferă totul. Cu Docker, cu serviciul oprit:

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

Programați această copiere în funcție de transmisiunile dumneavoastră și trimiteți-o în afara serverului. Puse pe discul său, aceste arhive intră și în backupurile sale de noapte.

Restaurarea bazei de date

O restaurare readuce baza la momentul backupului: tot ce s-a schimbat de atunci se pierde. Copiați mai întâi baza actuală într-un loc sigur, apoi:

1. Opriți Owncast.
2. Porniți Owncast cu --restoreDatabase și calea fișierului de backup: el restaurează baza, apoi se oprește.
3. Porniți Owncast normal, apoi verificați setările în administrare.

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

Actualizările

Cu Docker, documentația dă două comenzi, de rulat din directorul fișierului compose.yaml. Directorul de date rămâne pe loc:

docker compose pull
docker compose up -d

Cu programul de instalare, notele versiunii 0.3.0 descriu actualizarea: opriți serviciul, puneți deoparte fișierele interfeței web pe care le-ați personalizat, rulați din nou programul de instalare cu contul care rulează Owncast, apoi reporniți. Scriptul însuși păstrează o arhivă a directorului data în owncast-install-backups înainte de a înlocui versiunea.

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

Versiunea 0.3.0, publicată la 3 septembrie 2026, aduce pluginurile, Featured Streams, redarea automată și alegerea interfeței pe care ascultă RTMP. Notele sale cer să citiți schimbările înainte de actualizare, deoarece ele vă afectează instanța: urmăriți aceste note la fiecare versiune și copiați directorul data chiar înainte.

Cine ce face pe un Managed VPS

Găzduirea pe propriul server cere să țineți serverul pe lângă aplicație. Pe un Managed VPS, echipele noastre preiau serverul și vă urmăresc proactiv instanța; Owncast rămâne software-ul dumneavoastră, cu setările și datele sale.

Dacă preferați ca echipele noastre să intervină în aplicația însăși, această prestație se facturează la oră sau la preț fix, cu o ofertă comunicată înainte de intervenție.