Как установить и настроить Tdarr на VPS

MAATRIX

Библиотека фильмов и сериалов разрослась до нескольких терабайт, часть файлов в старом H.264 с раздутым битрейтом, часть — вообще в форматах, которые не тянет ни один клиент. Пересжимать всё это вручную через HandBrake — работа на месяцы. Tdarr автоматизирует именно эту рутину: сканирует библиотеку, проверяет файлы на здоровье и перекодирует их по заданным правилам, причём может делать это силами нескольких серверов параллельно. Разберём, как поставить Tdarr на VPS и настроить его так, чтобы перекодирование шло предсказуемо, а не съедало сервер целиком.

Что такое Tdarr и зачем он нужен

Tdarr — открытый инструмент для автоматического управления медиатекой: перекодирование видео в нужный кодек и контейнер, проверка целостности файлов (health check), нормализация звуковых дорожек и субтитров, удаление ненужных потоков. В отличие от разового прогона через ffmpeg-скрипт, Tdarr работает как постоянный сервис — следит за папками, подхватывает новые файлы и обрабатывает их по правилам, которые вы задали один раз.

Архитектура состоит из двух ролей. Tdarr Server — это мозг: веб-интерфейс, база данных, очередь задач и настройки библиотек. Tdarr Node — это руки: воркер, который берёт задачу из очереди и реально гоняет ffmpeg. Сервер и нода могут жить в одном контейнере на одной машине (для небольшой библиотеки этого достаточно), а могут быть разнесены — сервер на одном VPS, а ноды на нескольких других, каждая со своими ядрами.

Tdarr часто ставят рядом с медиасервером — например, Jellyfin или Plex: библиотека приводится к единообразному кодеку заранее, чтобы клиентам не приходилось транскодировать на лету при каждом просмотре. Типичный сценарий: библиотека в разномастных кодеках (H.264, MPEG-2, старый Xvid) приводится к единому HEVC с целевым битрейтом — экономия места ощутима, конкретные цифры зависят от исходников и настроек, поэтому не буду называть усреднённый процент. Второй частый кейс — health check: Tdarr прогоняет файлы через ffmpeg-транскод в /dev/null, чтобы выявить битые или незавершённые загрузки без изменения самого файла.

Требования к VPS: CPU, RAM, диск

Перекодирование видео — это чистая нагрузка на процессор. Программный x265-энкодинг одного потока 1080p может неделями держать несколько ядер под нагрузкой, если библиотека большая. Поэтому ключевой параметр выбора VPS — число ядер и их частота, а не объём RAM: сам Tdarr Server и веб-интерфейс лёгкие, 1–2 ГБ RAM и 1 ядро им хватает с запасом, но каждая параллельная транскодирующая задача на ноде — это отдельный процесс ffmpeg, которому нужно 1–2 ядра в зависимости от разрешения и пресета.

Диск — второй по важности ресурс. Нужно место под саму библиотеку, под временный кэш транскодирования (Tdarr пишет промежуточный файл, пока идёт перекодирование, и подменяет оригинал только после успешного завершения) и желательно — под резервную копию исходников на первое время, пока вы не убедились, что результат устраивает. Скорость диска влияет на время перекодирования меньше, чем CPU, но при большом количестве параллельных воркеров упирается в I/O, особенно на медленных HDD-хранилищах.

Отдельно стоит вопрос GPU-ускорения: Tdarr умеет использовать NVENC (NVIDIA) и QuickSync (Intel) для аппаратного кодирования, которое в разы быстрее программного и почти не грузит CPU. Обычный VPS с виртуальным процессором такого не даёт — для этого нужен сервер с реальным GPU или процессором с интегрированным Intel QuickSync и проброшенным устройством /dev/dri. Если библиотека большая и время критично, стоит сразу смотреть в сторону сервера с GPU, а не пытаться выжать это из бюджетного VPS.

Установка Tdarr Server и Node через Docker Compose

Официальный и самый удобный способ — Docker (если нужен более подробный разбор установки Docker и базовой защиты сервера, есть отдельная инструкция). Начните с подготовки сервера:

apt update && apt upgrade -y
curl -fsSL https://get.docker.com | sh

Создайте рабочую директорию и структуру папок для конфигов, логов, временного кэша и самой медиатеки:

mkdir -p /opt/tdarr/{server,configs,logs,temp}
mkdir -p /mnt/media

Простейший вариант — сервер и нода в одном контейнере, для старта на одном VPS этого достаточно:

services:
  tdarr:
    image: ghcr.io/haveagitgat/tdarr:latest
    container_name: tdarr
    restart: unless-stopped
    ports:
      - "8265:8265"   # веб-интерфейс
      - "8266:8266"   # порт сервера для нод
      - "8267:8267"   # порт ноды
    environment:
      - TZ=Europe/Moscow
      - PUID=1000
      - PGID=1000
      - UMASK_SET=002
      - serverIP=0.0.0.0
      - serverPort=8266
      - webUIPort=8265
      - internalNode=true
      - inContainer=true
      - ffmpegVersion=6
      - nodeName=main-node
    volumes:
      - /opt/tdarr/server:/app/server
      - /opt/tdarr/configs:/app/configs
      - /opt/tdarr/logs:/app/logs
      - /mnt/media:/media
      - /opt/tdarr/temp:/temp

Запустите:

cd /opt/tdarr && docker compose up -d

Проверьте, что контейнер поднялся и слушает порты:

docker compose ps
ss -tlnp | grep -E '8265|8266|8267'

Веб-интерфейс открывается по адресу http://IP-сервера:8265. По умолчанию он не защищён паролем — это отдельный пункт, к которому вернёмся ниже.

Настройка библиотек и воркеров в веб-интерфейсе

При первом входе Tdarr предложит создать библиотеку — укажите путь /media (тот, что смонтирован в контейнер) как исходную папку для сканирования. Библиотеке нужно задать режим: Transcode (перекодирование по правилам), Health Check (только проверка целостности) или оба сразу.

Ключевая настройка — количество воркеров на ноде, во вкладке Nodes. Здесь задаётся, сколько задач транскодирования и здоровья могут выполняться параллельно на CPU и на GPU отдельно. На VPS без GPU логично начать с 1–2 CPU-воркеров транскодирования на каждые пару свободных ядер и посмотреть на реальную загрузку через htop, прежде чем увеличивать число — слишком много параллельных ffmpeg-процессов на ограниченном числе ядер только удлиняет очередь, а не ускоряет её.

Во вкладке библиотеки настраивается расписание сканирования (Folder Watch — на новые файлы, или периодический полный скан) и фильтры: какие расширения обрабатывать, какие папки исключить, минимальный размер файла. Обязательно настройте exclude для папок с уже обработанными файлами и временных папок загрузчика — иначе Tdarr будет пытаться перекодировать файл, который ещё докачивается.

Плагины и типовая цепочка перекодирования

Логика обработки строится из плагинов — блоков, которые Tdarr выполняет по очереди для каждого файла: проверка кодека, проверка контейнера, проверка аудиодорожек, финальная сборка ffmpeg-команды. Для стандартной задачи «привести всё к HEVC в MKV» есть готовые community-плагины, например классика от MC93 (Tdarr_Plugin_MC93_Migz1FFMPEG и его производные) — они уже содержат логику «если кодек не HEVC — перекодировать, если уже HEVC — пропустить».

Собрать цепочку можно и без готовых плагинов через встроенный Flow-редактор (визуальный конструктор условий и действий) или через Classic-редактор, где плагины выстраиваются последовательно с условными переходами. Базовая цепочка обычно выглядит так:

1. Проверить видеокодек файла.
2. Если это уже целевой кодек — пропустить файл (Success, без перекодирования).
3. Если нет — задать параметры ffmpeg: кодек libx265 (или hevc_nvenc/hevc_qsv при аппаратном ускорении), CRF/битрейт, сохранение всех аудиодорожек и субтитров.
4. Запустить транскод, дождаться завершения, заменить оригинал результатом.

Важно тестировать цепочку на нескольких файлах вручную (кнопка Test в интерфейсе показывает итоговую ffmpeg-команду и её результат), прежде чем запускать на всю библиотеку — ошибка в маппинге потоков на тысяче файлов исправляется куда дольше, чем предотвращается одним тестовым прогоном.

Масштабирование: распределённые ноды и GPU

Если процессора одного VPS не хватает, к серверу можно подключить дополнительные ноды с других машин — они работают как отдельные воркеры, забирающие задачи из общей очереди. На каждой дополнительной машине поднимается только Tdarr_Node:

services:
  tdarr_node:
    image: ghcr.io/haveagitgat/tdarr_node:latest
    container_name: tdarr_node
    restart: unless-stopped
    environment:
      - TZ=Europe/Moscow
      - serverIP=IP_ГЛАВНОГО_СЕРВЕРА
      - serverPort=8266
      - nodeName=worker-2
      - inContainer=true
    volumes:
      - /opt/tdarr/configs:/app/configs
      - /opt/tdarr/logs:/app/logs
      - /mnt/media:/media
      - /opt/tdarr/temp:/temp

Важный нюанс: путь к медиатеке (/media) должен вести к тем же файлам, что и на сервере — иначе нода не найдёт исходники. На практике это либо общее сетевое хранилище (NFS, SMB), смонтированное одинаково на все ноды, либо синхронизированная копия. Через несколько дополнительных серверов из разных локаций с сетевым хранилищем библиотека перекодируется параллельно, что заметно сокращает суммарное время на большом каталоге — конкретный выигрыш зависит от числа ядер каждой ноды и профиля файлов.

Отдельная нода с GPU (NVENC или QuickSync) регистрируется точно так же, но с пробросом устройства в контейнер (--gpus all для NVIDIA или /dev/dri для Intel) и указанием GPU-кодека в плагине. Аппаратное кодирование радикально быстрее программного, но обычно даёт заметно больший файл на том же качестве — это классический компромисс между скоростью и эффективностью сжатия, который стоит проверить на своих файлах, а не на чужих обзорах.

Хранилище, кэш и безопасность доступа

Каталог /temp (временный кэш транскодирования) стоит держать на отдельном быстром диске, если он есть, — туда пишется промежуточный файл на весь период обработки, и при большом параллелизме это ощутимая нагрузка на I/O. Оригинал заменяется результатом только после успешного завершения задачи, так что при сбое (обрыв контейнера, нехватка места) файл остаётся целым — но место под кэш нужно закладывать с запасом хотя бы на один-два самых крупных файла библиотеки.

Веб-интерфейс Tdarr по умолчанию открыт без авторизации — на боевом VPS с публичным IP это открытая дверь к перекодированию и удалению файлов. Минимум — закрыть порт 8265 файрволом для всех, кроме своего IP:

ufw allow from ВАШ_IP to any port 8265
ufw deny 8265

Более гибкий вариант — вынести интерфейс за reverse proxy (Nginx или Caddy) с Basic Auth или полноценной аутентификацией, а порты 8266/8267 (общение сервера с нодами) вообще не публиковать наружу, если ноды находятся в одной приватной сети — используйте для связи между серверами внутренний VPN или приватную подсеть провайдера, а не открытый интернет.

Если библиотека лежит не локально, а на внешнем хранилище (например, подключена через rclone к облаку), учитывайте канал: перекодирование тысяч файлов через смонтированный удалённый диск создаёт постоянную нагрузку на сеть и может быть заметно медленнее локального SSD — для больших библиотек выгоднее держать рабочую копию на локальном диске сервера.

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