Owncast в Docker Compose: готовый файл

MAATRIX

Twitch режет донаты из России, YouTube банит трансляции за формальные нарушения, а альтернативные площадки либо платные, либо с ограничениями по контенту. Owncast решает проблему радикально: это открытый стриминговый сервер, который принимает поток из OBS по RTMP и раздаёт его зрителям через HLS-плеер прямо в браузере — без посредника между вами и аудиторией. В отличие от PeerTube, Owncast не тянет за собой PostgreSQL и Redis: это один бинарник с встроенной базой, поднимается за 10 минут. Ниже — рабочий docker-compose.yml, настройка OBS и весь путь от нуля до первого стрима.

Сколько ресурсов нужно серверу для Owncast

Owncast сильно легче классических видеохостингов вроде PeerTube, потому что не хранит библиотеку VOD-контента по умолчанию — сервер работает как проксирующий узел для живого потока. Но требования к CPU сильно зависят от того, включаете вы серверное перекодирование или нет.

Два принципиально разных сценария:

• Passthrough (без перекодирования) — сервер просто принимает RTMP-поток и раздаёт его как есть через HLS, вообще не трогая видео кодеком. Это дёшево по CPU: хватает 1-2 vCPU и 1-2 ГБ RAM, даже на бюджетном VPS. Минус — все зрители получают один и тот же битрейт/разрешение, который вы задали в OBS.
• Несколько качеств (adaptive bitrate) — Owncast сам перекодирует входящий поток в несколько вариантов (например, 1080p и 480p), чтобы зрители с медленным интернетом могли переключиться на более лёгкий поток. Каждый дополнительный вариант — это отдельный процесс ffmpeg, который постоянно ест CPU всё время трансляции. Здесь ориентир — от 4 vCPU, если хотите 2-3 дополнительных качества одновременно с исходным.

RAM для Owncast сама по себе некритична — 2 ГБ хватает почти всегда, узкое место именно в CPU при транскодировании. Диск нужен небольшой, если не включать долгосрочное хранение записей: сегменты HLS текущего стрима занимают немного и удаляются после ротации. А вот сеть на исходящий трафик стоит закладывать с запасом — каждый зритель тянет постоянный поток, и при аудитории в сотни человек это быстро становится узким местом раньше процессора.

Если планируете именно многозрительский стриминг с несколькими качествами, разумно начинать с сервера на 4+ vCPU — апгрейдить конфигурацию на лету с реальным стримом на публике неудобно.

Готовый docker-compose.yml

Вся установка — один контейнер. Сохраните файл как docker-compose.yml в отдельной директории, например /opt/owncast/:

version: "3.8"

services:
  owncast:
    image: owncast/owncast:latest
    container_name: owncast
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
      - "1935:1935"
    volumes:
      - ./data:/app/data
    environment:
      - TZ=Europe/Moscow

Обратите внимание на порты:

• 1935 — это RTMP-порт для приёма потока из OBS. Он открывается наружу напрямую, потому что RTMP — не HTTP-протокол, и через nginx/Caddy его штатно не проксируют.
• 8080 — веб-интерфейс, HLS-плеер, чат и админка. Он привязан только к localhost — снаружи к нему пойдёт reverse-proxy с TLS (раздел ниже).

Запуск:

docker compose up -d
docker compose logs -f owncast

Контейнер поднимается за секунды — никаких миграций базы ждать не нужно, Owncast использует встроенную SQLite-базу прямо в volume ./data.

Первый запуск и настройка через веб-панель

Почти вся конфигурация Owncast делается не через файлы, а через веб-админку — это заметно отличается от той же PeerTube с YAML-конфигами. Откройте http://IP-сервера:8080/admin (пока нет домена и SSL — временно через прямой порт, если он открыт в файрволе, либо через SSH-туннель).

При первом входе используется дефолтная пара логин/пароль администратора — её нужно сразу сменить в разделе Config → Server Setup → Admin Password, ещё до того, как вы объявите стрим публично. Если сервер смотрит в интернет открытым портом 8080, оставлять дефолтный пароль даже на несколько минут — плохая идея.

В админке настраивается всё, что нужно для запуска:

• General → Name, Summary, Tags — название канала и описание, которые видят зрители.
• General → Server URL — сюда вписывается домен, на котором будет жить стрим (например, https://stream.ваш-домен.ru), это важно для генерации корректных ссылок в HLS-манифестах и чате.
• Video → Output — здесь задаются варианты качества и битрейты (см. раздел про несколько качеств ниже).
• Stream Key — секретный ключ, который OBS использует для авторизации на RTMP-порту.

Все изменения в админке применяются сразу, без рестарта контейнера — Owncast перечитывает конфигурацию на лету.

Подключение OBS: RTMP-ingest и стрим-ключ

Со стороны OBS Studio (или любого другого RTMP-энкодера — XSplit, ffmpeg, Streamlabs) настройка сводится к двум полям в разделе Settings → Stream:

• Service — Custom...
• Server — rtmp://ваш-домен-или-IP:1935/live
• Stream Key — значение, скопированное из админки Owncast (Config → Server Setup → Stream Key)

Server:     rtmp://stream.ваш-домен.ru:1935/live
Stream Key: <ваш-ключ-из-админки>

После нажатия «Start Streaming» в OBS поток должен появиться на главной странице https://ваш-домен.ru практически мгновенно — задержка (latency) у HLS обычно в районе нескольких секунд, точное значение зависит от длины сегмента, которую вы задаёте в настройках видео.

Битрейт и разрешение исходного потока настраиваются в самом OBS (Settings → Output → Video Bitrate, Settings → Video → Output Resolution) — это тот поток, который Owncast принимает как исходный и либо раздаёт как есть (passthrough), либо перекодирует в дополнительные варианты.

Полезная деталь для отладки: если OBS показывает «Failed to connect to server», в первую очередь проверьте, что порт 1935 действительно открыт в файрволе сервера — про настройку правил есть отдельный разбор про ufw на VPS.

Reverse-proxy с SSL перед Owncast

Веб-часть Owncast (порт 8080) слушает только localhost — снаружи нужен reverse-proxy с TLS-терминацией и, обязательно, с поддержкой WebSocket: через него работает чат в реальном времени.

Пример конфига для Caddy — сертификат Let's Encrypt получает и продлевает автоматически:

stream.ваш-домен.ru {
    reverse_proxy 127.0.0.1:8080 {
        header_up X-Forwarded-Proto https
        header_up X-Real-IP {remote_host}
    }
}

Caddy сам умеет проксировать WebSocket-соединения без дополнительных директив — этим он проще nginx. Если предпочитаете nginx, для чата обязательно нужны заголовки апгрейда протокола:

server {
    listen 443 ssl;
    server_name stream.ваш-домен.ru;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Без Upgrade/Connection заголовков сам стрим будет работать (HLS — это обычные HTTP-запросы сегментов), а вот чат — нет: WebSocket-соединение просто не установится, и зрители не увидят обновлений в реальном времени. Подробный разбор установки reverse-proxy с нуля — в статье про Caddy с авто-SSL на VPS.

Порт 1935 (RTMP) через reverse-proxy не проксируется — он открывается напрямую в файрволе на IP сервера, TLS для него не нужен, потому что OBS подключается к нему напрямую по внутреннему протоколу, а не через браузер.

Качество стрима, запись в S3 и чат с федерацией

Несколько качеств. В разделе Video → Output админки можно добавить дополнительные варианты потока помимо исходного — например, урезанную копию в 480p с меньшим битрейтом для зрителей с медленным интернетом. Каждый добавленный вариант запускает отдельный процесс перекодирования на сервере и повышает нагрузку на CPU пропорционально числу вариантов — не добавляйте больше 2-3, если сервер не рассчитан именно на это заранее.

Хранилище и запись стримов. По умолчанию Owncast не хранит записи вечно — сегменты HLS текущей трансляции ротируются локально на диске и удаляются после эфира. Если нужно архивировать стримы, в Config → Storage можно подключить S3-совместимое хранилище — тогда сегменты пишутся сразу туда, а не на локальный диск сервера. Подходит и внешний провайдер, и собственный MinIO — если поднимаете его сами, у нас есть инструкция по установке и настройке MinIO. Это разгружает диск основного сервера точно так же, как в связке с PeerTube.

Чат. Встроен из коробки, работает через WebSocket без отдельной настройки — просто убедитесь, что reverse-proxy пробрасывает апгрейд протокола (см. выше). Модерация (бан по IP/имени, медленный режим) доступна прямо в админке, без сторонних ботов.

Федерация с Fediverse. Owncast умеет публиковать уведомления о начале стрима в Fediverse (Mastodon и совместимые платформы) через ActivityPub — включается в разделе Config → Social, где указывается публичный handle вашего канала. Это не полноценная федерация с другими Owncast-инстансами как у PeerTube, а скорее интеграция «канал стал живым» — уведомление приходит подписчикам в их ленту Mastodon. Функциональность и её охват зависят от версии — сверяйтесь с changelog на релиз, который используете.

Частые вопросы