Hosting Owncast na Managed VPS: Państwa transmisje na żywo na Państwa serwerze

Co robi Owncast

Owncast to otwartoźródłowy, samodzielnie hostowany, jednoosobowy serwer transmisji wideo na żywo z czatem: jedna instancja obsługuje kanał jednej osoby lub organizacji. README przedstawia go jako sposób na prowadzenie własnych transmisji na żywo, na wzór dużych popularnych platform, z zachowaniem własności treści, interfejsu, moderacji i widowni.

• Odbiór: Państwa oprogramowanie do transmisji, na przykład OBS, wysyła strumień przez RTMP, protokół używany przez główne platformy streamingowe.
• Dostarczanie: Owncast dzieli wideo na segmenty HLS, w jednej lub kilku jakościach, i udostępnia je na swojej stronie. Strumień odtwarza się też w VLC lub mpv, pod adresem /hls/stream.m3u8.
• Czat: wbudowany w stronę, z moderatorami, blokadami i logowaniem przez Fediwersum lub IndieAuth.
• Fediwersum: konto Mastodon może obserwować Państwa serwer i otrzymywać powiadomienie o każdym rozpoczęciu transmisji. Wersja 0.3.0 dodaje Featured Streams, które pokazują transmisje na żywo innych serwerów Owncast.
• Rozszerzanie: webhooki, API oraz, od wersji 0.3.0, wtyczki, instalowane z panelu administracyjnego z uprawnieniami, które Państwo im przyznają.

Na co pozwala licencja MIT

Owncast jest udostępniany na licencji MIT. Przyznaje ona bezpłatnie prawo do używania, kopiowania, modyfikowania, łączenia, publikowania, rozpowszechniania, sublicencjonowania i sprzedawania kopii oprogramowania. Mogą więc Państwo uruchomić go dla swojej firmy, społeczności lub klientów, bez zakupu licencji.

Jedynym warunkiem jest zachowanie informacji o prawach autorskich i tekstu licencji we wszystkich kopiach lub istotnych częściach oprogramowania. Tekst dostarcza oprogramowanie „w stanie, w jakim jest”, bez gwarancji.

Procesor i przepustowość: dobór serwera

Dokumentacja mówi to od razu: wymagania zależą od Państwa konfiguracji. Podaje jednak jasną regułę, by je oszacować. Procesor transkoduje wideo do oferowanych jakości; przepustowość dostarcza je każdemu widzowi.

• Liczba widzów nie zmienia obciążenia procesora. Wideo jest kodowane raz, a potem udostępniane wszystkim: przy zerze widzów czy przy stu praca kodowania jest taka sama. Czat dokłada niewielkie obciążenie, małe w porównaniu z kodowaniem.
• Przepustowość rośnie z każdym widzem. Każdy widz otrzymuje własną kopię strumienia.
• Każda transkodowana jakość wymaga mocy procesora, tym większej, im niższa docelowa przepływność (bitrate), ponieważ mocniejsza kompresja wymaga więcej obliczeń.

Przepustowość serwera

Dokumentacja podaje dwa wzory. Objętość transmisji w gigabajtach: przepływność w kb/s × czas trwania w sekundach × widzowie ÷ 8 000 000. Szczytowa prędkość wysyłania do utrzymania, w Mb/s: przepływność w kb/s × widzowie ÷ 1000. Przy kilku jakościach proszę obliczyć każdą z nich i zsumować wyniki. Jej szacunki dla dwugodzinnej transmisji:

Na VPS Simafri ruch nie ma miesięcznego licznika: Państwa transmisje dobiera się według ich szczytowej przepływności. Gdy widownia rośnie, magazyn obiektowy, omówiony dalej, udostępnia wideo w miejsce serwera.

Procesor

Dokumentacja podaje zmierzone punkty odniesienia, zaznaczając, że zależą one od kodeka, przepływności, rozdzielczości i ustawienia enkodera:

• Jeden rdzeń na jakość: w przybliżeniu jeden rdzeń procesora często radzi sobie z jedną transkodowaną jakością przy 30 klatkach na sekundę.
• Liczba klatek: 60 klatek na sekundę wymaga mniej więcej dwa razy więcej obliczeń niż 30, a 24 klatki na sekundę mniej więcej 0,8 raza tyle.
• Ustawienie domyślne: Owncast startuje z jedną jakością, 1200 kb/s i 24 klatki na sekundę, z dźwiękiem przekazywanym bez zmian. Dokumentacja radzi od tego zacząć, przetestować, a następnie dodać jakość, gdy procesor ma zapas mocy.

Dokumentacja nie podaje wymagań dotyczących pamięci, a dysk ma niewielkie znaczenie: segmenty wideo są zapisywane, a potem usuwane w miarę trwania transmisji. Z czasem rośnie jedynie katalog data. Na VPS kodowanie wykonuje procesor: każdą transkodowaną jakość dobiera się w vCPU. Na Managed VPS wystarczy opisać nam swoje transmisje, ich przepływność, jakości i widownię, a polecimy odpowiedni rozmiar.

Łącze, z którego Państwo nadają

Zanim strumień dotrze do serwera, wychodzi z Państwa własnego łącza. Dokumentacja wymaga prędkości wysyłania co najmniej 1,5 raza większej od przepływności strumienia: 7,5 Mb/s dla strumienia 5000 kb/s. Zaleca połączenie przewodowe zamiast Wi-Fi.

Instalacja przez Docker Compose

Dokumentacja proponuje obraz owncast/owncast z Docker Hub, który zawiera ffmpeg, narzędzie do kodowania potrzebne Owncast. Na serwerze z zainstalowanym Dockerem proszę utworzyć katalog i umieścić w nim ten compose.yaml, zaczerpnięty z dokumentacji:

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 opublikowany na 127.0.0.1: to jedyna zmiana względem przykładu z dokumentacji, który publikuje oba porty. Jej strona o odwrotnym proxy prosi, by nie wystawiać Owncast bezpośrednio do internetu, ponieważ domyślnie nasłuchuje on na wszystkich interfejsach, a Docker publikuje port na wszystkich adresach serwera, gdy żaden nie jest podany. Interfejs webowy jest wtedy osiągalny wyłącznie przez odwrotne proxy.
• Port 1935 odbiera strumień przez RTMP. Pozostaje publiczny, ponieważ Państwa oprogramowanie do transmisji łączy się z nim bezpośrednio, z pominięciem proxy.
• Katalog data przechowuje bazę danych i jej kopie na serwerze, poza kontenerem: to jego kopię się wykonuje i to on się przenosi.
• Tag latest podąża za najnowszym wydaniem; 0.3.0 przypina wersję.

Bez Dockera: oficjalny instalator

Druga droga z dokumentacji to skrypt, który pobiera najnowsze wydanie Owncast dla Państwa platformy oraz ffmpeg, jeśli go jeszcze nie ma. Instaluje wszystko w katalogu owncast wewnątrz bieżącego. Dokumentacja odradza uruchamianie go jako root i zaleca przeczytanie każdego zdalnego skryptu przed jego uruchomieniem:

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

Aby Owncast startował razem z serwerem i sam uruchamiał się ponownie po awarii, dokumentacja dostarcza usługę systemd, do dostosowania do wybranego katalogu i konta:

[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

Hasło administratora i klucz transmisji

Panel administracyjny znajduje się pod /admin. Owncast startuje z danymi logowania, które zna każdy, a dokumentacja prosi o ich zmianę przy pierwszym logowaniu:

Aby dokonać tej zmiany, zanim interfejs zostanie otwarty dla publiczności, proszę skorzystać z tunelu SSH: port 8080 serwera pojawia się wtedy na Państwa komputerze, pod adresem http://localhost:8080/admin. Proszę dodać -p i port SSH podany w Państwa strefie klienta.

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

• Hasło administratora zmienia się w „Configuration”, „Server Setup”. Musi mieć od 8 do 192 znaków, co najmniej jedną małą literę, jedną wielką literę, jedną cyfrę i jeden znak specjalny spośród !@#$%^&*, i nie może zawierać myślnika.
• Klucze transmisji zarządza się w zakładce „Stream Keys” tej samej strony. Owncast proponuje automatycznie wygenerowany klucz o długości 30 znaków, a mogą Państwo przechowywać kilka kluczy, każdy z komentarzem: klucz przekazany współprowadzącemu można później unieważnić bez naruszania pozostałych.
• Utracone hasło zastępuje się przy starcie flagą --adminpassword, która zapisuje je w bazie.

Hasło administratora i klucz transmisji mają na początku tę samą wartość abc123, ale są to dwa odrębne ustawienia: proszę zmienić oba.

HTTPS: odwrotne proxy

Owncast sam nie obsługuje HTTPS. Dokumentacja umieszcza przed nim odwrotne proxy, które nasłuchuje na portach 80 i 443, uzyskuje certyfikat, szyfruje ruch i przekazuje go w postaci jawnej do Owncast na port 8080. Bez HTTPS przeglądarki oznaczają stronę jako niezabezpieczoną, a strona udostępniana przez HTTPS nie może osadzić Państwa wideo ani czatu.

• Proxy przekazuje wszystkie ścieżki, w tym połączenie WebSocket pod /ws, które obsługuje czat. Proxy, które je blokuje, odcina czat.
• RTMP nie przechodzi przez proxy: Państwa oprogramowanie do transmisji wysyła strumień prosto na port 1935 Owncast.
• Rzeczywisty adres odwiedzających: Owncast odczytuje nagłówek X-Forwarded-For, aby zablokować adres IP użytkownika wykluczonego z czatu. Dokumentacja prosi, by proxy samo ustawiało ten nagłówek.

Z Caddy

Dokumentacja proponuje Caddy, jeśli nie mają Państwo innych preferencji: sam uzyskuje certyfikat Let’s Encrypt i przekazuje WebSocket bez dodatkowych ustawień. Oto jej przykładowy Caddyfile, w którym wiersz tls podaje adres e-mail konta Let’s Encrypt:

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

Z Nginx

Przy Nginx dokumentacja kładzie nacisk na WebSocket: to jego pominięcie wyłącza czat. Proszę dodać ten blok map do sekcji http pliku /etc/nginx/nginx.conf:

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

Ten blok strony powtarza blok z dokumentacji, na porcie 80, aby Certbot mógł zainstalować 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

Transmisja przez RTMP z OBS

Owncast przyjmuje każde oprogramowanie, które nadaje przez RTMP do zdalnego serwera. Klucz jest akceptowany wyłącznie na ścieżce /live. W OBS:

1. Proszę otworzyć „Ustawienia”, a następnie „Transmisja”, i wybrać usługę niestandardową.
2. Proszę wpisać adres rtmp://live.example.com:1935/live.
3. Proszę wpisać swój klucz transmisji, ten z zakładki „Stream Keys” w Owncast.
4. Proszę rozpocząć transmisję.

Oprogramowanie bez pola na klucz przyjmuje pełny adres, rtmp://live.example.com:1935/live/your-key.

Na VPS Simafri adres IPv6 serwera może otworzyć dowolnie wybrany port: Państwa oprogramowanie do transmisji dociera do portu 1935 przez ten adres, pod nazwą, która ma rekord AAAA. W sieci Docker IPv4, jak tutaj, Docker przekierowuje port z adresu IPv6 serwera do kontenera. Jeśli ufw jest aktywny, proszę otworzyć ten port, a następnie przetestować połączenie ze swojego komputera:

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

W przypadku każdej innej potrzeby wystarczy nam ją opisać, a wspólnie przyjrzymy się adresacji.

Ustawienia Państwa oprogramowania do transmisji

• Kodeki: H.264 dla obrazu i AAC dla dźwięku, jedyne, dla których zapewniona jest zgodność transkodowania i odtwarzania.
• Interwał klatek kluczowych: jedna co 2 sekundy, nigdy w trybie „auto”. W OBS interwał podaje się w sekundach, czyli 2.
• Przepływność: proszę wysyłać to, co zamierzają Państwo oferować, i nie więcej. Jeśli serwer obsługuje 720p przy 2500 kb/s, proszę nie wysyłać mu 1080p przy 6000 kb/s: każda zlecona konwersja zwiększa obciążenie procesora.

Jakości wideo i opóźnienie

Jakości oferowane widzom ustawia się w „Configuration”, „Video”. Kilka jakości pozwala odtwarzaczowi wybrać tę, którą jego łącze jest w stanie utrzymać: dokumentacja zaleca, po przetestowaniu pierwszej konfiguracji, drugą jakość, od 1000 do 2000 kb/s, obok wysokiej jakości od 4000 do 6000 kb/s.

• Przepływność: od 400 do 13 000 kb/s, co 100.
• Liczba klatek: od 24 do 120 klatek na sekundę, domyślnie 24.
• Rozdzielczość: proszę zmienić szerokość albo wysokość, nie obie naraz, a Owncast zachowa proporcje obrazu.
• Użycie procesora: pięć poziomów. Im wyższy poziom, tym lepszy obraz albo mniejszy plik przy tej samej jakości.

Passthrough przekazuje przychodzące wideo bez ponownego kodowania: oszczędza niemal całą moc procesora tej jakości i pomija jej ustawienia przepływności, rozdzielczości i liczby klatek. Dokumentacja zastrzega go dla zaawansowanych użytkowników: widzowie otrzymują dokładnie to, co wysyła Państwa oprogramowanie, czego niektóre odtwarzacze nie potrafią odtworzyć, a opóźnienie rośnie. Zanim zaczną Państwo na nim polegać, proszę przetestować odtwarzanie na urządzeniach, które są dla Państwa ważne.

Opóźnienie ustawia się buforem opóźnienia na tej samej stronie. Każdy poziom zamienia odrobinę opóźnienia na stabilność, a zmiana obowiązuje od następnej transmisji:

Wersja 0.3.0 dodaje też po stronie widza opcję odtwarzacza „Minimize latency”, która lekko przyspiesza odtwarzanie, aby zbliżyć się do transmisji na żywo, oraz ustawienie automatycznego odtwarzania, domyślnie wyłączone.

Magazyn obiektowy, by obsłużyć więcej widzów

Owncast może wysyłać swoje segmenty wideo do magazynu zgodnego z S3, z którego pobierają je widzowie. Serwer nadal udostępnia główną listę odtwarzania, API i czat; wideo, które stanowi niemal całą przepustowość, pochodzi z magazynu. Państwa serwer wysyła wtedy tylko jedną kopię każdej jakości: w przykładzie z dokumentacji 6,5 Mb/s dla dwóch jakości, 5000 i 1500 kb/s, niezależnie od tego, czy widzów jest zero, czy tysiąc. Obciążenie procesora pozostaje takie samo.

1. Proszę utworzyć kontener (bucket) u swojego dostawcy magazynu obiektowego.
2. Proszę udostępnić go do publicznego odczytu i ustawić politykę CORS, jeśli dostawca jej wymaga: błąd CORS lub Access-Control-Allow-Origin w konsoli przeglądarki niemal zawsze ma tam swoje źródło.
3. W „Configuration”, „Server Setup”, zakładka „S3 Object Storage”, proszę włączyć magazyn i wpisać nazwę kontenera, klucz dostępu, klucz tajny, punkt końcowy i region. Wszystkie te pola są wymagane.

Ten magazyn obsługuje transmisję na żywo, a nie archiwum: Owncast na bieżąco usuwa segmenty starsze niż lista odtwarzania plus bufor około 20 segmentów. Kontener przechowuje tylko kilka ostatnich minut transmisji.

Dla widzów rozproszonych po całym świecie dokumentacja opisuje też sieć dostarczania treści (CDN) umieszczoną przed Owncast, z osobną nazwą hosta źródłowego i ustawieniem „Websocket host override”, które utrzymuje połączenie czatu z serwerem źródłowym.

Czat i moderacja

Czat ustawia się w „Configuration”, „Chat”. Domyślnie nie ma żadnych moderatorów: dokumentacja radzi przynajmniej mianować moderatorem samego siebie, na stronie „Users” panelu administracyjnego.

• Moderatorzy ukrywają wiadomość lub wykluczają użytkownika bezpośrednio z poziomu czatu. Nie mają dostępu do panelu administracyjnego.
• Wykluczenie rozłącza użytkownika, usuwa jego wiadomości i blokuje jego znany adres IP. Można je później cofnąć; usunięcie użytkownika jest natomiast trwałe.
• Tylko stali użytkownicy: to ustawienie blokuje wiadomości z kont młodszych niż 15 minut, z wyjątkiem moderatorów.
• Filtr języka odrzuca obraźliwe wiadomości na podstawie wewnętrznej listy słów.
• Wymagane uwierzytelnienie pozwala wysyłać wiadomości tylko uwierzytelnionym użytkownikom, przez konto w Fediwersum lub IndieAuth, oraz moderatorom.
• Ogranicznik częstotliwości, domyślnie włączony, dopuszcza mniej więcej jedną wiadomość co dwie trzecie sekundy i na 10 sekund blokuje każdego, kto zalewa czat wiadomościami.

Dokumentacja zaznacza, że blokadę IP można obejść, na przykład przez VPN: ogranicza ona nadużycia, a moderacja pozostaje zadaniem każdego kanału. Stąd wartość wyznaczonych moderatorów przy najchętniej oglądanych transmisjach.

Kopie zapasowe

Owncast sam wykonuje kopię swojej bazy raz na godzinę, do data/backup/owncastdb.bak. Flaga --backupdir zmienia ten katalog. Oto, co zawiera katalog z danymi:

Do pełnego odtworzenia albo przeniesienia instancji dokumentacja prosi o kopię całego katalogu data: skopiowanie go do nowej instalacji przenosi wszystko. Przy Dockerze, przy zatrzymanej usłudze:

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

Proszę zaplanować tę kopię odpowiednio do swoich transmisji i wysyłać ją poza serwer. Umieszczone na jego dysku, archiwa te trafiają także do jego nocnych kopii zapasowych.

Przywracanie bazy

Przywrócenie cofa bazę do chwili wykonania kopii: wszystko, co zmieniono od tego czasu, zostaje utracone. Najpierw proszę skopiować bieżącą bazę w bezpieczne miejsce, a następnie:

1. Proszę zatrzymać Owncast.
2. Proszę uruchomić Owncast z --restoreDatabase i ścieżką pliku kopii: przywraca on bazę, a potem kończy działanie.
3. Proszę uruchomić Owncast w zwykły sposób, a następnie sprawdzić swoje ustawienia w panelu administracyjnym.

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

Aktualizacje

Przy Dockerze dokumentacja podaje dwa polecenia, wydawane z katalogu z compose.yaml. Katalog z danymi pozostaje na miejscu:

docker compose pull
docker compose up -d

Przy instalatorze informacje o wydaniu 0.3.0 opisują aktualizację: zatrzymać usługę, odłożyć na bok ewentualnie zmienione pliki interfejsu webowego, ponownie uruchomić instalator z konta, które uruchamia Owncast, a potem uruchomić usługę ponownie. Sam skrypt przed zastąpieniem wydania zapisuje archiwum katalogu data w owncast-install-backups.

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

Wersja 0.3.0, wydana 3 września 2026 roku, przynosi wtyczki, Featured Streams, automatyczne odtwarzanie i wybór interfejsu, na którym nasłuchuje RTMP. Jej notatki proszą o zapoznanie się ze zmianami przed aktualizacją, ponieważ dotyczą one Państwa instancji: proszę śledzić te notatki przy każdym wydaniu i tuż przed aktualizacją skopiować katalog data.

Kto za co odpowiada na Managed VPS

Samodzielny hosting wymaga prowadzenia serwera, oprócz samej aplikacji. Na Managed VPS nasze zespoły przejmują serwer i proaktywnie czuwają nad Państwa instancją; Owncast pozostaje Państwa oprogramowaniem, z jego ustawieniami i danymi.

Jeśli wolą Państwo, aby nasze zespoły interweniowały w samej aplikacji, usługa ta jest rozliczana godzinowo lub ryczałtowo, z wyceną przekazaną przed interwencją.