Хостване на Owncast на Managed VPS: предаванията ви на живо на ваш сървър

Какво прави Owncast

Owncast е самостоятелно хостван сървър с отворен код за видео излъчване на живо и чат, предназначен за един потребител: една инстанция носи канала на един човек или една организация. README го представя като начин да водите собствени предавания на живо, в стила на големите масови платформи, като запазвате собствеността върху съдържанието, интерфейса, модерирането и аудиторията си.

• Приемането: софтуерът ви за излъчване, като OBS, изпраща потока през RTMP, протокола, който използват големите платформи за стрийминг.
• Доставката: Owncast нарязва видеото на сегменти HLS, в едно или няколко качества, и го предоставя на своята уеб страница. Потокът се пуска и във VLC или mpv, на /hls/stream.m3u8.
• Чатът: вграден в страницата, с модератори, забрани и влизане чрез Fediverse или IndieAuth.
• Fediverse: акаунт в Mastodon може да следва сървъра ви и да бъде известяван всеки път, когато започнете предаване. Версия 0.3.0 добавя Featured Streams, които показват предаванията на живо на други сървъри Owncast.
• Разширяването: webhooks, API и, от 0.3.0, плъгини, инсталирани от администрацията с правата, които им давате.

Какво позволява лицензът MIT

Owncast е публикуван с лиценза MIT. Той дава безплатно правото да използвате, копирате, променяте, сливате, публикувате, разпространявате, преотстъпвате и продавате копия на софтуера. Можете следователно да го пускате за фирмата, общността или клиентите си, без да купувате лиценз.

Единственото условие е да запазите бележката за авторските права и текста на лиценза във всички копия или съществени части на софтуера. Текстът предоставя софтуера „такъв, какъвто е“, без гаранция.

Процесор и честотна лента: оразмеряване на сървъра

Документацията го казва от самото начало: изискванията зависят от вашата конфигурация. Тя все пак дава ясно правило, за да ги оцените. Процесорът транскодира видеото в качествата, които предлагате; честотната лента го доставя на всеки зрител.

• Броят на зрителите не променя натоварването на процесора. Видеото се кодира веднъж, после се предоставя на всички: нула зрители или сто, работата по кодирането е същата. Чатът добавя малко натоварване, незначително в сравнение с кодирането.
• Честотната лента расте с всеки зрител. Всеки зрител получава собствено копие на потока.
• Всяко транскодирано качество изисква процесорно време, и то толкова повече, колкото по-нисък е целевият битрейт, защото по-силното компресиране изисква повече изчисления.

Честотната лента на сървъра

Документацията дава две формули. Обемът на едно предаване, в гигабайти: битрейт в kbps × продължителност в секунди × зрители ÷ 8 000 000. Пиковата изходяща скорост, която трябва да издържите, в Mbps: битрейт в kbps × зрители ÷ 1000. При няколко качества изчислете всяко от тях и ги съберете. Нейните оценки за двучасово предаване:

На VPS на Simafri трафикът няма месечен брояч: предаванията ви се оразмеряват по пиковия им битрейт. Когато аудиторията ви расте, обектното хранилище, описано по-долу, предоставя видеото вместо сървъра.

Процесорът

Документацията дава измерени ориентири, като отбелязва, че те варират според кодека, битрейта, резолюцията и предварителната настройка на енкодера:

• Едно ядро на качество: като грубо правило едно процесорно ядро често може да поеме едно транскодирано качество при 30 кадъра в секунда.
• Кадровата честота: 60 кадъра в секунда изискват около два пъти повече изчисления от 30, а 24 кадъра в секунда около 0,8 пъти.
• Настройката по подразбиране: Owncast започва с едно качество, при 1200 kbps и 24 кадъра в секунда, със звук, предаван непроменен. Документацията съветва да започнете оттам, да тествате, после да добавите качество, когато процесорът има резерв.

Документацията не дава число за паметта, а дискът има малко значение: видео сегментите се записват, после се премахват с напредването на предаването. С времето расте само папката data. На VPS процесорът извършва кодирането: всяко транскодирано качество се оразмерява във vCPU. На Managed VPS ни разкажете за предаванията си, техния битрейт, техните качества и аудиторията ви и ще ви препоръчаме подходящия размер.

Вашата връзка за излъчване

Преди да стигне до сървъра, потокът излиза от вашата собствена връзка. Документацията иска скорост на качване поне 1,5 пъти битрейта на потока: 7,5 Mbps за поток от 5000 kbps. Тя препоръчва кабелна връзка вместо Wi-Fi.

Инсталиране с Docker Compose

Документацията предлага образа owncast/owncast в Docker Hub, който включва ffmpeg, инструмента за кодиране, от който Owncast се нуждае. На сървър с инсталиран Docker създайте папка и поставете в нея този compose.yaml, взет от документацията:

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

• Порт 8080, публикуван на 127.0.0.1: това е единствената промяна спрямо примера от документацията, който публикува двата порта. Нейната страница за обратния прокси моли да държите Owncast далеч от интернет, защото по подразбиране той слуша на всички интерфейси, а Docker публикува порт на всички адреси на сървъра, когато не му е посочен адрес. Тогава уеб интерфейсът е достъпен само през обратния прокси.
• Порт 1935 приема потока през RTMP. Той остава публичен, защото софтуерът ви за излъчване стига до него директно, без да минава през проксито.
• Папката data пази базата данни и резервните ѝ копия на сървъра, извън контейнера: това е, което архивирате и премествате.
• Етикетът latest следва последната версия; 0.3.0 фиксира версия.

Без Docker: официалният инсталатор

Другият път в документацията е скрипт, който изтегля последната версия на Owncast за вашата платформа, както и ffmpeg, ако още го няма. Той инсталира всичко в папка owncast под текущата. Документацията не препоръчва да го пускате като root и съветва да прочетете всеки отдалечен скрипт, преди да го изпълните:

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

За да стартира Owncast заедно със сървъра и да се рестартира сам след срив, документацията предоставя услуга systemd, която да адаптирате към избраните папка и акаунт:

[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. Owncast стартира с данни за достъп, които всеки знае, а документацията моли да ги смените при първото си влизане:

За да направите тази промяна, преди интерфейсът да е отворен за публиката, минете през SSH тунел: порт 8080 на сървъра се появява на вашия компютър, на http://localhost:8080/admin. Добавете -p и SSH порта, показан в клиентската ви зона.

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

• Администраторската парола се сменя в „Configuration“, „Server Setup“. Тя изисква от 8 до 192 знака, поне една малка буква, една главна буква, една цифра и един специален знак от !@#$%^&*, и никакво тире.
• Ключовете за излъчване се управляват в раздела „Stream Keys“ на същата страница. Owncast предлага автоматично генериран ключ от 30 знака, а можете да пазите няколко, всеки с коментар: ключ, даден на съводещ, може по-късно да бъде отменен, без да се засягат останалите.
• Загубена парола се заменя при стартиране с флага --adminpassword, който я записва в базата данни.

Администраторската парола и ключът за излъчване започват и двете като abc123, но са две отделни настройки: сменете и двете.

HTTPS: обратният прокси

Owncast не поема сам HTTPS. Документацията поставя пред него обратен прокси, който слуша на портове 80 и 443, получава сертификата, шифрова трафика и го препраща в явен вид към Owncast на порт 8080. Без HTTPS браузърите отбелязват страницата като несигурна, а страница, предоставена през HTTPS, не може да вгради вашето видео или вашия чат.

• Проксито препраща всички пътища, включително връзката WebSocket на /ws, която носи чата. Прокси, което я блокира, прекъсва чата.
• RTMP не минава през проксито: софтуерът ви за излъчване изпраща направо към порт 1935 на Owncast.
• Истинският адрес на посетителите: Owncast чете заглавката X-Forwarded-For, за да блокира IP адреса на потребител, забранен в чата. Документацията иска проксито само да задава тази заглавка.

С Caddy

Документацията предлага Caddy, ако нямате друго предпочитание: той сам получава сертификат Let’s Encrypt и препраща WebSocket без допълнителна настройка. Ето нейния пример за Caddyfile, в който редът tls дава имейл адреса на акаунта в Let’s Encrypt:

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

С Nginx

С Nginx документацията настоява на WebSocket: пропускането му е това, което изключва чата. Добавете този блок map в раздела http на /etc/nginx/nginx.conf:

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

Този блок за сайта следва този от документацията, на порт 80, за да остави на Certbot да постави 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

Излъчване през RTMP от OBS

Owncast приема всеки софтуер, който излъчва през RTMP към отдалечен сървър. Ключът се приема само на пътя /live. В OBS:

1. Отворете „Settings“, после „Stream“, и изберете „Custom“ като услуга.
2. Въведете адреса rtmp://live.example.com:1935/live.
3. Въведете ключа си за излъчване, този от раздела „Stream Keys“ на Owncast.
4. Започнете излъчването.

Софтуер без поле за ключа приема пълния адрес, rtmp://live.example.com:1935/live/your-key.

На VPS на Simafri IPv6 адресът на сървъра може да отвори всеки порт, който изберете: софтуерът ви за излъчване стига до порт 1935 през този адрес, под име, което носи записа AAAA. В Docker мрежа с IPv4, както тук, Docker пренасочва порта от IPv6 адреса на сървъра към контейнера. Отворете този порт, ако ufw е включен, после тествайте от компютъра си:

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

За всяка друга нужда ни кажете какво сте намислили и ще разгледаме адресирането заедно с вас.

Настройките на софтуера ви за излъчване

• Кодеците: H.264 за видеото и AAC за звука, единствените, за които транскодирането и съвместимостта при възпроизвеждане са гарантирани.
• Интервалът на ключовите кадри: един на всеки 2 секунди, никога оставен на „auto“. В OBS интервалът е в секунди, следователно 2.
• Битрейтът: изпращайте това, което смятате да предлагате, не повече. Ако сървърът ви поема 720p при 2500 kbps, не му изпращайте 1080p при 6000 kbps: всяко преобразуване, което поискате, добавя натоварване на процесора.

Качества на видеото и закъснение

Качествата, предлагани на зрителите, се настройват в „Configuration“, „Video“. Няколко качества позволяват на плейъра да избере това, което връзката му издържа: документацията препоръчва второ качество, от 1000 до 2000 kbps, до високо качество от 4000 до 6000 kbps, след като първата ви конфигурация е тествана.

• Битрейтът: от 400 до 13 000 kbps, на стъпки по 100.
• Кадровата честота: от 24 до 120 кадъра в секунда, 24 по подразбиране.
• Резолюцията: сменете ширината или височината, не и двете, а Owncast запазва съотношението.
• Използването на процесора: пет нива. Колкото по-високо е нивото, толкова по-добра е картината или толкова по-малък е файлът при същото качество.

Passthrough предава входящото видео, без да го прекодира: той спестява почти цялото процесорно време на това качество и пренебрегва настройките му за битрейт, резолюция и кадрова честота. Документацията го запазва за напреднали потребители: зрителите получават точно това, което изпраща софтуерът ви, което някои плейъри не могат да възпроизведат, а закъснението се увеличава. Тествайте възпроизвеждането на устройствата, които са важни за вас, преди да разчитате на него.

Закъснението се настройва с буфера за закъснение, на същата страница. Всяко ниво разменя малко забавяне срещу стабилност, а промяната важи от следващото предаване:

Версия 0.3.0 добавя също, от страната на зрителя, опцията на плейъра „Minimize latency“, която леко ускорява възпроизвеждането, за да се доближи до живото предаване, и настройка за автоматично пускане, изключена по подразбиране.

Обектно хранилище за повече зрители

Owncast може да изпраща видео сегментите си към хранилище, съвместимо с S3, откъдето зрителите ги изтеглят. Сървърът продължава да предоставя основния плейлист, API и чата; видеото, което съставлява почти цялата честотна лента, идва от хранилището. Тогава сървърът ви изпраща само по едно копие от всяко качество: в примера от документацията 6,5 Mbps за две качества при 5000 и 1500 kbps, независимо дали имате нула зрители или хиляда. Натоварването на процесора остава същото.

1. Създайте bucket при своя доставчик на обектно хранилище.
2. Направете го публично четим и задайте политика CORS, ако доставчикът я изисква: грешка CORS или Access-Control-Allow-Origin в конзолата на браузъра почти винаги идва оттам.
3. В „Configuration“, „Server Setup“, раздел „S3 Object Storage“, включете хранилището и въведете името на bucket, ключа за достъп, тайния ключ, крайната точка и региона. Всички тези полета са задължителни.

Това хранилище предоставя предаването на живо, а не архив: Owncast изтрива в движение сегментите, по-стари от плейлиста плюс буфер от около 20 сегмента. Bucket пази само последните няколко минути от предаването.

За зрители, разпръснати по целия свят, документацията описва и мрежа за доставка на съдържание (CDN), поставена пред Owncast, с отделно име на хоста за източника и настройката „Websocket host override“, която държи чата свързан със сървъра източник.

Чат и модериране

Чатът се настройва в „Configuration“, „Chat“. По подразбиране няма модератори: документацията предлага поне да направите себе си модератор, от страницата „Users“ на администрацията.

• Модераторите скриват съобщение или забраняват потребител направо от чата. Те нямат достъп до администрацията.
• Забраната изключва потребителя, премахва съобщенията му и блокира известния му IP адрес. Тя може да бъде отменена по-късно; изтриването на потребител, от своя страна, е окончателно.
• Само утвърдени потребители: тази настройка блокира съобщенията от акаунти, по-млади от 15 минути, с изключение на модераторите.
• Езиковият филтър отхвърля обидните съобщения, по вътрешен списък с думи.
• Задължителното удостоверяване позволява да изпращат съобщения само удостоверени потребители, чрез акаунт във Fediverse или IndieAuth, и модераторите.
• Ограничителят на честотата, включен по подразбиране, позволява приблизително едно съобщение на всеки две трети от секундата и блокира за 10 секунди всеки, който залива чата.

Документацията посочва, че блокирането по IP може да се заобиколи, например с VPN: то ограничава злоупотребите, а модерирането остава работа на всеки канал. Оттук и ползата от посочени модератори за най-гледаните ви предавания.

Резервните копия

Owncast архивира собствената си база данни веднъж на час, в data/backup/owncastdb.bak. Флагът --backupdir сменя тази папка. Ето какво съдържа папката с данни:

За пълно възстановяване или за преместване на инстанцията документацията моли да архивирате цялата папка data: копирането ѝ в нова инсталация пренася всичко. С Docker, при спряна услуга:

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

Планирайте това копие според предаванията си и го изпращайте извън сървъра. Поставени на диска му, тези архиви влизат и в нощните му резервни копия.

Възстановяване на базата данни

Възстановяването връща базата към момента на резервното копие: всичко, променено след това, се губи. Първо копирайте текущата база на сигурно място, после:

1. Спрете Owncast.
2. Стартирайте Owncast с --restoreDatabase и пътя на файла с резервното копие: той възстановява базата, после спира.
3. Стартирайте Owncast както обикновено, после проверете настройките си в администрацията.

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

Обновленията

С Docker документацията дава две команди, изпълнявани от папката на compose.yaml. Папката с данни остава на мястото си:

docker compose pull
docker compose up -d

С инсталатора бележките към версия 0.3.0 описват обновяването: спрете услугата, отделете настрана файловете на уеб интерфейса, които сте персонализирали, пуснете отново инсталатора с акаунта, под който работи Owncast, после рестартирайте. Самият скрипт пази архив на папката data в owncast-install-backups, преди да замени версията.

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

Версия 0.3.0, издадена на 3 септември 2026 г., носи плъгините, Featured Streams, автоматичното пускане и избора на интерфейса, на който слуша RTMP. Бележките ѝ молят да прочетете промените преди обновяване, защото те засягат вашата инстанция: следете тези бележки при всяка версия и копирайте папката data непосредствено преди това.

Кой какво прави на Managed VPS

Самостоятелното хостване изисква да поддържате сървъра освен приложението. На Managed VPS нашите екипи поемат сървъра и следят проактивно вашата инстанция; Owncast остава ваш софтуер, с неговите настройки и данни.

Ако предпочитате нашите екипи да се намесват в самото приложение, тази услуга се фактурира на час или на фиксирана цена, с оферта, съобщена преди намесата.