Розгортання Owncast на VPS: self-hosted live-стримінг, SSL, Docker і резервне копіювання

1. Що ми налаштовуємо і навіщо

Owncast — відкрита платформа для самостійного розміщення live-стримінгу. Вона приймає відеопотік від OBS Studio або іншого RTMP-сумісного застосунку, перекодовує або передає його глядачам через вебплеєр і надає сторінку трансляції, чат, налаштування каналу та базову модерацію.

На відміну від Twitch, YouTube Live або Kick, сервер Owncast перебуває під вашим контролем. Ви самостійно керуєте доменом, налаштуваннями доступу, журналами, резервними копіями та політикою зберігання даних. Це корисно для закритих трансляцій, корпоративних заходів, освітніх проєктів, власної спільноти або інтеграції стримінгу із сайтом.

У цьому посібнику передбачається така схема:

• VPS з Ubuntu Server 24.04 LTS і публічною IPv4-адресою;
• домен stream.example.com, спрямований на VPS;
• Docker Engine і Docker Compose Plugin;
• Owncast у контейнері з постійним сховищем;
• Caddy як reverse proxy та автоматичний менеджер TLS;
• OBS Studio на комп’ютері ведучого;
• зовнішнє сховище для резервних копій.

Що вийде в результаті

Після виконання інструкцій глядач зможе відкрити HTTPS-адресу каналу, а ви — надіслати потік з OBS на RTMP-адресу. Вебінтерфейс Owncast буде доступний через Caddy на портах 80 і 443, а RTMP-з’єднання прийматиметься на порту 1935. Панель адміністратора буде захищена окремим паролем.

Важливо розуміти межі такої схеми. VPS не створює додаткову пропускну здатність для кожного глядача: сервер повинен надсилати відеопотік кожному підключеному клієнту. Якщо потік має бітрейт 6 Мбіт/с і одночасно дивляться 50 осіб, вихідний трафік може сягати приблизно 300 Мбіт/с без урахування службових даних.

Self-hosted і хмарні платформи

Хмарні сервіси простіші на старті: не потрібно оновлювати сервер, стежити за диском, налаштовувати SSL і окремо оплачувати вихідний трафік. Водночас діють обмеження платформи: правила контенту, комісії, ліміти API, обов’язкова реєстрація глядачів або відсутність повного контролю над аналітикою.

Self-hosted Owncast потребує більше адміністрування, зате дає передбачувану архітектуру. Ви можете вбудувати плеєр на свій сайт, змінити оформлення, обмежити доступ VPN або reverse proxy, зберігати конфігурацію у себе та переносити інсталяцію між серверами.

2. Яка VPS-конфігурація потрібна для цього завдання

Головний ресурс для live-стримінгу — не лише CPU та пам’ять, а й вихідна мережа. Якщо Owncast не перекодовує відео, сервер переважно приймає один RTMP-потік і роздає його глядачам. Якщо увімкнено додаткові профілі якості або транскодування, навантаження на CPU зростає багаторазово.

Мінімальна конфігурація

Для тестової трансляції та невеликого закритого каналу підійде VPS з 2 vCPU, 2 ГБ RAM, SSD на 30–40 ГБ і мережевим портом 1 Гбіт/с. Такий варіант розрахований приблизно на 5–15 глядачів за потоку 2–4 Мбіт/с, якщо сервер не займається важким транскодуванням.

Практичний стартовий варіант для одного публічного каналу — 2–4 vCPU, 4 ГБ RAM, NVMe-диск на 80 ГБ і щонайменше 1 ТБ вихідного трафіку на місяць. Для потоку 1080p з бітрейтом 5–8 Мбіт/с цього зазвичай достатньо для невеликої спільноти, але фактичний ліміт залежить від тарифу, мережі та кількості одночасних глядачів.

Відповідний варіант VPS

Для описаної конфігурації можна взяти відповідний VPS з 4 vCPU, 8 ГБ RAM, NVMe-диском від 80 ГБ, публічним IPv4 і мережевим портом 1 Гбіт/с. Перевірте не лише швидкість порту, а й місячний ліміт трафіку: 100 глядачів за 6 Мбіт/с можуть використати близько 2,2 ТБ вихідних даних за 24 години безперервної трансляції.

Коли потрібен dedicated-сервер

Dedicated-сервер виправданий, якщо канал регулярно збирає сотні глядачів, потрібно кілька одночасних трансляцій, виконується апаратно-залежне кодування або не можна допускати конкуренцію за CPU та мережу з сусідніми віртуальними машинами. Він також корисний для архівування великої кількості записів та обробки відео.

Для одного Owncast-каналу dedicated зазвичай надмірний. Спочатку виміряйте CPU, RAM, вихідний трафік і затримку. Переходити на фізичний сервер варто тоді, коли збільшення VPS уже не вирішує проблему або вартість гарантованих ресурсів стає порівнянною з вартістю dedicated.

Вибір локації

Розміщуйте сервер ближче до основної аудиторії. Географічна близькість зменшує затримку під час відкриття сайту та ризик мережевих проблем, але не усуває навантаження від роздавання відео. Якщо глядачі перебувають у кількох регіонах, для масштабування можна додати CDN для вебресурсів або використовувати окремий media relay, проте звичайний HTTP CDN не завжди коректно проксіює live-відеопотік.

3. Підготовка сервера

Нижче використовується чиста Ubuntu Server 24.04 LTS з користувачем, створеним під час встановлення. Усі команди виконуються через SSH від імені користувача з правами sudo. Замініть IP-адресу та ім’я домену на власні значення.

Оновлення системи та базові утиліти

Спочатку оновіть індекс пакетів і встановлені компоненти. Перезавантаження потрібне, якщо оновилося ядро або системні бібліотеки, що використовуються службами.

sudo apt update
sudo apt full-upgrade -y
sudo apt install -y ca-certificates curl gnupg git vim unzip jq htop ncdu
sudo reboot

Після повторного підключення перевірте версію ОС і час. Неправильний час може заважати перевірці TLS-сертифікатів і роботі планувальника резервних копій.

cat /etc/os-release
timedatectl status
hostnamectl

Окремий адміністративний користувач

Не використовуйте root для повсякденної роботи. Створіть користувача streamadmin, додайте його до групи sudo та встановіть публічний SSH-ключ. Публічний ключ можна отримати з локального файлу ~/.ssh/id_ed25519.pub.

sudo adduser streamadmin
sudo usermod -aG sudo streamadmin
sudo install -d -m 700 -o streamadmin -g streamadmin /home/streamadmin/.ssh
sudo nano /home/streamadmin/.ssh/authorized_keys
sudo chown streamadmin:streamadmin /home/streamadmin/.ssh/authorized_keys
sudo chmod 600 /home/streamadmin/.ssh/authorized_keys

Відкрийте другий термінал і переконайтеся, що вхід працює:

ssh streamadmin@SERVER_IP

Після перевірки можна заборонити SSH-вхід для root і вимкнути парольну автентифікацію. Не виконуйте це до перевірки ключа: інакше легко втратити доступ до сервера.

sudo install -d -m 755 /etc/ssh/sshd_config.d
printf 'PermitRootLogin no\nPasswordAuthentication no\nKbdInteractiveAuthentication no\n' | sudo tee /etc/ssh/sshd_config.d/99-hardening.conf
sudo sshd -t
sudo systemctl reload ssh

Firewall і fail2ban

Потрібно дозволити SSH, HTTP, HTTPS і RTMP. SSH-порт у прикладі залишається стандартним 22; якщо ви змінили його, замініть правило UFW.

sudo apt install -y ufw fail2ban
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 1935/tcp
sudo ufw enable
sudo ufw status verbose

Fail2ban блокуватиме повторювані невдалі спроби входу через SSH. Для базової конфігурації достатньо увімкнути системний jail:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Порт 1935 потрібен лише для вхідного RTMP. Не відкривайте адміністративний порт Owncast назовні: він буде доступний через HTTPS reverse proxy, а прямий доступ до нього ми обмежимо локальною bind-адресою.

4. Встановлення ПЗ — покроково

У 2026 році для такого розгортання зручно використовувати Docker Engine і Docker Compose Plugin з офіційного репозиторію Docker. Версію Owncast краще фіксувати тегом образу, а не використовувати безумовний latest. На момент підготовки прикладу використовується гілка Owncast 0.2.x; перед оновленням перевірте актуальний реліз в офіційній документації та протестуйте його на копії даних.

Додавання офіційного репозиторію Docker

Спочатку видаліть конфліктні пакети, якщо їх встановлено зі старого репозиторію Ubuntu.

sudo apt remove -y docker.io docker-compose docker-doc podman-docker containerd runc || true

Наступні команди встановлюють ключ репозиторію та підключають офіційне джерело пакетів Docker.

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

Встановіть Docker Engine, Buildx і Compose Plugin. У прикладі використовується сучасний синтаксис docker compose, а не застаріла окрема команда docker-compose.

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
sudo docker version
sudo docker compose version

Додавання користувача до групи docker дає змогу запускати Docker без sudo, але фактично надає користувачеві права рівня root. Для окремого production-сервера це допустимо лише для довіреного адміністратора.

sudo usermod -aG docker "$USER"
newgrp docker
docker run --rm hello-world

Створення каталогів Owncast

Створіть каталог проєкту та окрему директорію для даних. Каталог даних має зберігатися під час повторного створення контейнера: у ньому містяться конфігурація, користувацькі налаштування, логотипи, оформлення та інші постійні файли Owncast.

sudo mkdir -p /opt/owncast/{data,backups}
sudo chown -R "$USER:$USER" /opt/owncast
cd /opt/owncast

Файл Docker Compose

Створіть файл /opt/owncast/compose.yml. Образ запускається від імені контейнерного процесу, а дані монтуються до стандартного шляху /app/data. Порт 8080 публікується лише на loopback-інтерфейсі, тому його не можна відкрити безпосередньо з інтернету.

services:
  owncast:
    image: owncast/owncast:0.2.1
    container_name: owncast
    restart: unless-stopped
    environment:
      - TZ=UTC
    ports:
      - "127.0.0.1:8080:8080"
      - "1935:1935"
    volumes:
      - ./data:/app/data
    healthcheck:
      test: ["CMD", "wget", "-q", "-O", "-", "http://127.0.0.1:8080"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 30s

Перед запуском завантажте образ і перевірте конфігурацію Compose:

docker compose config
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=100 owncast

Якщо образ із зазначеним тегом недоступний, не підставляйте випадковий тег. Відкрийте сторінку релізів Owncast, виберіть актуальну стабільну версію та змініть поле image. Після зміни виконайте docker compose pull і перезапустіть контейнер.

Встановлення Caddy

Caddy прийматиме HTTPS-запити, автоматично отримуватиме сертифікат Let’s Encrypt і передаватиме запити до Owncast на локальний порт 8080. Встановлення виконується з офіційного репозиторію Caddy.

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy
sudo systemctl enable --now caddy
caddy version

5. Конфігурація Owncast, домену та SSL

DNS-запис

У реєстратора домену створіть A-запис:

Якщо використовується IPv6 і він коректно маршрутизується на сервер, можна додати AAAA-запис. Не створюйте AAAA-запис, якщо IPv6 на VPS не налаштований: частина глядачів тоді отримуватиме недоступну адресу.

Перевірити DNS можна безпосередньо із сервера або локального комп’ютера:

dig +short A stream.example.com
dig +short AAAA stream.example.com

Початкове налаштування Owncast

Відкрийте інтерфейс за локальною адресою через SSH-тунель. Це безпечніше, ніж тимчасово відкривати порт 8080 у зовнішньому firewall:

ssh -L 8080:127.0.0.1:8080 streamadmin@SERVER_IP

Тепер відкрийте на локальному комп’ютері http://127.0.0.1:8080. Під час першого запуску Owncast запропонує виконати початкове налаштування. Вкажіть назву каналу, часовий пояс, пароль адміністратора, опис та інші параметри. Для пароля використовуйте унікальне значення завдовжки не менше 20 символів.

Потоковий ключ не можна публікувати разом з адресою трансляції. Будь-яка людина, яка отримала цей ключ, зможе надсилати потік на ваш канал. Після витоку ключ необхідно змінити в адміністративній панелі Owncast і оновити налаштування OBS.

Reverse proxy через Caddy

Створіть файл /etc/caddy/Caddyfile. Замініть домен на свій. Директива reverse_proxy передає HTTP-запити до контейнера Owncast, а Caddy автоматично вмикає HTTPS після того, як DNS почне вказувати на сервер і порти 80/443 стануть доступними.

stream.example.com {
    encode gzip zstd

    reverse_proxy 127.0.0.1:8080

    log {
        output file /var/log/caddy/owncast-access.log
        format json
    }

    header {
        Strict-Transport-Security "max-age=31536000"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

Перевірте синтаксис і застосуйте конфігурацію:

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
sudo journalctl -u caddy -n 100 --no-pager

Через кілька секунд Caddy має отримати сертифікат. Перевірка HTTPS виконується командою:

curl -I https://stream.example.com
curl -sS https://stream.example.com | head

Очікується відповідь HTTP/2 200 або інший успішний HTTP-код, який повертає поточна сторінка Owncast. Якщо Caddy повідомляє про помилку ACME, перевірте DNS, системний час, правила UFW і наявність іншого процесу на портах 80 або 443.

Налаштування OBS Studio

В OBS відкрийте налаштування трансляції та виберіть користувацький сервіс. У полі сервера вкажіть:

rtmp://stream.example.com/live

У поле ключа вставте Stream Key із панелі Owncast. Для першого тесту використовуйте помірний профіль: H.264, 1920×1080 при 30 кадрах на секунду та бітрейт 4500–6000 Кбіт/с. Аудіо AAC 128–160 Кбіт/с сумісне з більшістю пристроїв.

Якщо вихідна швидкість інтернету у ведучого нестабільна, почніть із 1280×720 і 2500–4000 Кбіт/с. Потік має мати запас за швидкістю: бажано, щоб реальна upload-швидкість була щонайменше в 1,5 раза вищою за вибраний бітрейт. В OBS увімкніть автоматичне перепідключення та встановіть буфер перепідключення 10–20 секунд.

Перевірка конфігурації

Перевірте, що контейнер запущений і має стан healthy або стабільно працює без циклічних перезапусків:

cd /opt/owncast
docker compose ps
docker inspect --format='{{json .State.Health}}' owncast | jq
docker compose logs --tail=200 owncast

Перевірте локальний backend без участі Caddy:

curl -I http://127.0.0.1:8080
ss -lntp | grep -E ':(80|443|1935|8080)\b'

Перевірка зовнішніх портів з іншого вузла допомагає виявити помилку у firewall:

nc -vz stream.example.com 80
nc -vz stream.example.com 443
nc -vz stream.example.com 1935

Після запуску OBS відкрийте публічну сторінку Owncast і переконайтеся, що з’являється live-індикатор, збільшується кількість глядачів і відтворюється звук. Якщо сторінка відкривається, але відео не запускається, спочатку перевірте логи Owncast і консоль браузера.

6. Перевірка трансляції та діагностика

Надійна перевірка має включати не лише відкриття вебсторінки, а й спостереження за ресурсами під час ефіру. В окремому SSH-сеансі запустіть моніторинг контейнера:

docker stats owncast

Якщо CPU стабільно перебуває на рівні близько 100 відсотків одного або кількох ядер, імовірне навантаження від обробки відео або надто важкий профіль. За нестачі пам’яті Linux може почати використовувати swap, що збільшує затримки та створює ризик зупинки контейнера.

Перевірте вільне місце та розмір каталогу даних:

df -h /
du -sh /opt/owncast/data
sudo du -xhd1 /var/lib/docker | sort -h

Стежте за вихідним трафіком. Залежно від панелі провайдера дані можуть оновлюватися із затримкою, тому для оперативної оцінки використовуйте системні інструменти або моніторинг інтерфейсу. Якщо канал має обмеження трафіку, заздалегідь налаштуйте сповіщення на рівні 70–80 відсотків місячного ліміту.

Оцінка пропускної здатності

Розрахунок можна виконати за формулою: бітрейт потоку в Мбіт/с помножується на кількість глядачів, потім додається запас близько 15 відсотків. Наприклад, потік 6 Мбіт/с для 40 глядачів потребує приблизно 276 Мбіт/с вихідної пропускної здатності:

6 × 40 × 1,15 = 276 Мбит/с

Для місячного трафіку переведіть бітрейт у гігабайти. Потік 6 Мбіт/с, який безперервно працює протягом доби, передає приблизно 64,8 ГБ без урахування протокольного overhead. За 30 глядачів це близько 1,9 ТБ на добу, тому тривалі публічні ефіри потрібно планувати окремо.

Перевірка TLS

Сертифікат і ланцюжок можна перевірити через OpenSSL:

echo | openssl s_client -connect stream.example.com:443 -servername stream.example.com 2>/dev/null | openssl x509 -noout -issuer -subject -dates

Сертифікат Caddy оновлює автоматично. Не запускайте паралельно Certbot для того самого домену: два менеджери сертифікатів можуть конфліктувати через порти та ACME challenge.

7. Резервні копії та обслуговування

Що необхідно зберігати

Основний об’єкт резервного копіювання — /opt/owncast/data. У ньому можуть міститися налаштування каналу, користувацькі зміни оформлення, дані чату, конфігурація та інші файли, потрібні для відновлення інсталяції. Також збережіть /opt/owncast/compose.yml, /etc/caddy/Caddyfile і список установлених пакетів.

Не варто бездумно копіювати весь каталог /var/lib/docker: це збільшує обсяг резервної копії та прив’язує відновлення до внутрішнього формату Docker. Відновлюйте проєкт через Compose і повертайте лише потрібні постійні дані.

Проста резервна копія через restic

Restic шифрує резервні копії перед надсиланням до віддаленого сховища. Як backend можна використовувати S3-сумісне сховище або окремий сервер. Установіть пакет:

sudo apt install -y restic
sudo install -d -m 700 /root/.config/restic
sudo nano /root/.config/restic/env
sudo chmod 600 /root/.config/restic/env

Файл оточення має містити адресу репозиторію, пароль і ключі S3. Наведені нижче значення є прикладом і мають бути замінені:

export RESTIC_REPOSITORY="s3:https://s3.example.net/owncast-backups"
export RESTIC_PASSWORD="GENERATE_A_LONG_RANDOM_PASSWORD"
export AWS_ACCESS_KEY_ID="S3_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="S3_SECRET_KEY"

Пароль Restic не можна втрачати: без нього зашифроване сховище неможливо відновити. Ініціалізуйте репозиторій один раз:

sudo bash -c 'source /root/.config/restic/env && restic init'

Створіть скрипт /usr/local/sbin/owncast-backup. Перед копіюванням Compose тимчасово зупиняється, щоб дані не змінювалися під час створення знімка. Коротке переривання безпечніше, ніж резервування непослідовного стану.

sudo tee /usr/local/sbin/owncast-backup > /dev/null <<'EOF'
#!/usr/bin/env bash
set -Eeuo pipefail

source /root/.config/restic/env

PROJECT=/opt/owncast
STAGE=$(mktemp -d)
trap 'rm -rf "$STAGE"' EXIT

cd "$PROJECT"
docker compose stop owncast

mkdir -p "$STAGE/owncast-data" "$STAGE/config"
rsync -a --delete "$PROJECT/data/" "$STAGE/owncast-data/"
cp "$PROJECT/compose.yml" "$STAGE/config/compose.yml"
cp /etc/caddy/Caddyfile "$STAGE/config/Caddyfile"

docker compose start owncast

restic backup "$STAGE" --tag owncast
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check
EOF
sudo chmod 700 /usr/local/sbin/owncast-backup

Запустіть тест вручну й переконайтеся, що контейнер знову працює:

sudo /usr/local/sbin/owncast-backup
restic snapshots
docker compose -f /opt/owncast/compose.yml ps

Додайте щоденний запуск через systemd timer. Таймер кращий за cron, оскільки його стан і журнали можна переглядати через journalctl.

sudo tee /etc/systemd/system/owncast-backup.service > /dev/null <<'EOF'
[Unit]
Description=Backup Owncast data

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/owncast-backup
EOF

sudo tee /etc/systemd/system/owncast-backup.timer > /dev/null <<'EOF'
[Unit]
Description=Daily Owncast backup

[Timer]
OnCalendar=--* 03:15:00
Persistent=true

[Install]
WantedBy=timers.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now owncast-backup.timer
systemctl list-timers owncast-backup.timer

Перевірка відновлення

Резервна копія вважається працездатною лише після тестового відновлення. Отримайте список знімків, виберіть ідентифікатор і відновіть вміст у тимчасовий каталог, не перезаписуючи production:

sudo bash -c 'source /root/.config/restic/env && restic snapshots'
sudo mkdir -p /tmp/owncast-restore
sudo bash -c 'source /root/.config/restic/env && restic restore SNAPSHOT_ID --target /tmp/owncast-restore'
sudo find /tmp/owncast-restore -maxdepth 4 -type f | sort | head -50

Періодично перевіряйте відновлення на окремому VPS або під час maintenance window. Репозиторій резервних копій має розташовуватися за межами основного сервера: відмова диска, видалення VPS або компрометація root не повинні знищити обидві копії.

Оновлення Owncast

Перед оновленням зробіть свіжу резервну копію та прочитайте release notes. Для планового оновлення зупиніть трансляцію, завантажте новий образ, повторно створіть контейнер і перевірте журнали:

cd /opt/owncast
sudo /usr/local/sbin/owncast-backup
docker compose pull
docker compose up -d
docker compose ps
docker compose logs --tail=200 owncast

Змінюйте версію в compose.yml усвідомлено. Rolling update для одного контейнера Owncast недоступний у класичному розумінні: зазвичай виникає коротке вікно недоступності. Щоб мінімізувати простій, заздалегідь зберігайте перевірений старий тег і не видаляйте його до підтвердження успішного оновлення.

Регулярне обслуговування

• Щотижня перевіряйте вільне місце, статус контейнера та останні резервні копії.
• Щомісяця виконуйте тестове відновлення частини даних.
• Оновлюйте Ubuntu і Docker в окреме вікно обслуговування.
• Стежте за терміном дії домену та доступністю DNS.
• Перевіряйте витрати вихідного трафіку після великих ефірів.
• Періодично змінюйте адміністративний пароль і потоковий ключ у разі підозри на витік.
• Не зберігайте секрети в публічному Git-репозиторії та не вставляйте їх у Dockerfile.

8. Усунення несправностей і FAQ

Чому домен відкривається з помилкою «connection refused»?

Спочатку перевірте, що DNS вказує на правильну IP-адресу: dig +short A stream.example.com. Потім виконайте sudo systemctl status caddy, sudo ss -lntp і sudo ufw status. Caddy має прослуховувати 80 і 443, а Owncast — локальний порт 8080. Якщо контейнер зупинено, перегляньте docker compose logs owncast. Помилка також виникає, коли в DNS залишився неправильний запис AAAA.

Чому Caddy не може отримати сертифікат?

Порти 80 і 443 мають бути доступними з інтернету, а домен уже має розпізнаватися на VPS. Перевірте правила UFW і зовнішній firewall провайдера. Переконайтеся, що інший вебсервер не зайняв порти: sudo ss -lntp | grep -E ':(80|443)\b'. Докладна причина міститься в sudo journalctl -u caddy -n 200. Не запускайте одночасно Caddy і Certbot для одного домену.

OBS підключається, але трансляція не з’являється

Перевірте адресу сервера: зазвичай це rtmp://stream.example.com/live, а не HTTPS-адреса сторінки. Переконайтеся, що порт 1935 дозволений у UFW і зовнішньому firewall. В Owncast і OBS потоковий ключ має збігатися. Після запуску OBS виконайте docker compose logs -f owncast і перевірте, чи реєструє сервер вхідне RTMP-з’єднання. У разі витоку ключа створіть новий.

Відео буферизується у глядачів, хоча CPU вільний

Найімовірніша причина — недостатня вихідна пропускна здатність або обмеження трафіку. Розрахуйте бітрейт, помножений на кількість глядачів, і порівняйте результат із гарантованою швидкістю VPS. Перевірте втрати пакетів і маршрут до кількох мереж. Зменште бітрейт в OBS, наприклад із 6000 до 4000 Кбіт/с, і протестуйте знову. Якщо проблема виникає лише у віддалених регіонах, розгляньте media relay або окремий edge-сервер.

Яка конфігурація VPS мінімально підійде?

Для тестової трансляції достатньо 2 vCPU, 2 ГБ RAM, SSD на 40 ГБ і публічної IPv4-адреси. Для регулярного ефіру з 20–80 глядачами краще вибрати 2–4 vCPU, 4 ГБ RAM, NVMe на 80 ГБ і порт 1 Гбіт/с із достатнім місячним трафіком. Ці значення передбачають, що Owncast не виконує важке транскодування. Для кількох профілів якості знадобляться додаткові CPU та пам’ять.

Що вибрати — VPS чи dedicated для цього завдання?

VPS підходить більшості невеликих і середніх каналів: його простіше масштабувати, переносити й обслуговувати, а вартість нижча. Dedicated потрібен за наявності сотень одночасних глядачів, кількох каналів, постійного транскодування, великих архівів або вимог до гарантованих ресурсів. Приймайте рішення на основі вимірювань CPU, RAM, вихідного трафіку та мережевої затримки, а не лише за кількістю ядер.

Контейнер постійно перезапускається. Що перевірити?

Виконайте docker compose ps і docker compose logs --tail=300 owncast. Часті причини — неправильний тег образу, пошкоджений каталог даних, нестача місця або помилка прав на volume. Перевірте df -h, df -i і права на /opt/owncast/data. Не видаляйте дані одразу: спочатку зупиніть контейнер і скопіюйте каталог. Відновлення з останньої робочої резервної копії безпечніше за ручне редагування невідомих файлів.

Чи можна відкрити Owncast без домену та SSL?

Для тимчасового тесту можна звертатися до IP і локального порту, але публічну експлуатацію краще починати лише після налаштування домену та HTTPS. Без TLS адміністративні паролі та інші дані передаються небезпечно, а браузери можуть блокувати окремі функції. RTMP також не шифрується стандартним способом, тому потоковий ключ не можна вважати захищеним від прослуховування. Для production використовуйте HTTPS для вебінтерфейсу й обмежуйте доступ до панелі.

9. Висновки та наступні кроки

У результаті Owncast працює на VPS у Docker, приймає потік з OBS, віддає глядачам HTTPS-сторінку через Caddy і автоматично отримує TLS-сертифікат. Постійні дані винесені в окремий каталог, а резервні копії шифруються Restic і надсилаються до зовнішнього сховища.

Далі виміряйте реальне навантаження на CPU, затримку та вихідний трафік під час кількох ефірів. Потім можна додати моніторинг Prometheus або Uptime Kuma, налаштувати окрему систему зберігання записів і підготувати другий сервер для аварійного відновлення. За зростання аудиторії плануйте розділення вебпроксі, ingest-сервера та роздачі медіапотоку.