Развёртывание 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. Troubleshooting и 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-сервера и раздачи медиапотока.