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

MAATRIX

Если у вас накопилась музыкальная коллекция в FLAC и MP3, а стриминговые сервисы либо режут каталог, либо просто недоступны из России — Navidrome решает это за один вечер. Это лёгкий self-hosted сервер, который превращает папку с музыкой на вашем VPS в полноценный стриминг-сервис с веб-плеером, мобильными приложениями и поддержкой Subsonic API. Ниже — рабочий docker-compose.yml, который можно скопировать и запустить без танцев с бубном.

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

Navidrome — open-source медиа-сервер, написанный на Go, с полной поддержкой Subsonic/OpenSubsonic API. Это значит, что у него нет собственного фирменного мобильного приложения, зато он совместим с десятками уже существующих Subsonic-клиентов: DSub, Substreamer, play:Sub, Symfonium, Amperfy и другими на iOS, Android и десктопе. Веб-интерфейс — отдельное современное SPA-приложение, похожее на Spotify: обложки альбомов, плейлисты, умные сортировки по жанрам и годам, скробблинг в Last.fm.

Главные плюсы для домашнего использования:

• Индексация коллекции происходит быстро даже на слабом VPS — Go даёт минимальный оверхед по памяти (обычно 100-300 МБ на десятки тысяч треков).
• Транскодирование на лету — можно слушать FLAC-коллекцию на мобильном интернете в сжатом Opus или MP3, не храня вторую копию файлов.
• Многопользовательский режим с разными правами — удобно, если сервер общий на семью.
• Работает без базы данных отдельным сервисом — использует встроенный SQLite, поэтому весь стек — это один контейнер плюс тома.

Это не замена стриминговому сервису в смысле каталога — играет только то, что вы туда положили. Но если у вас есть собранная за годы коллекция (или вы синхронизируете её с NAS), Navidrome закрывает вопрос доступа к ней с любого устройства.

Требования к серверу

Navidrome сам по себе нетребователен — сканирование и раздача файлов без транскодирования почти не грузят CPU. Основная нагрузка появляется, если вы включаете транскодирование на лету для нескольких одновременных слушателей: каждый активный поток кодирования FLAC → Opus/MP3 занимает примерно одно ядро.

Диск — отдельный вопрос: если коллекция на несколько тысяч альбомов в FLAC, это легко 200-500 ГБ и больше. Дешевле держать музыку на отдельном блочном томе или подключить внешнее хранилище по SMB/NFS, а сам сервер брать компактный. Если коллекция растёт, заранее закладывайтесь на расширяемый диск — на VPS это обычно вопрос пары кликов в панели, без переустановки системы.

Установка Docker и подготовка каталогов

Если Docker ещё не стоит, поставьте его штатным способом (Ubuntu 24.04):

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
newgrp docker

Создайте структуру каталогов — отдельно данные приложения (индекс, конфиг, БД) и отдельно музыка:

mkdir -p /opt/navidrome/data
mkdir -p /opt/navidrome/music

В /opt/navidrome/music заливаете вашу коллекцию — через rsync, scp, rclone (если музыка лежит в облаке) или монтируете сетевой диск. Структура папок Navidrome не критична: он сам разбирает метаданные из тегов файлов, но классическая раскладка Артист/Альбом/01 - Трек.flac даёт наиболее предсказуемую группировку.

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

Вот рабочий конфиг с транскодированием, healthcheck и правильными правами:

services:
  navidrome:
    image: deluan/navidrome:latest
    container_name: navidrome
    restart: unless-stopped
    ports:
      - "4533:4533"
    environment:
      ND_SCANSCHEDULE: "1h"
      ND_LOGLEVEL: "info"
      ND_SESSIONTIMEOUT: "24h"
      ND_BASEURL: ""
      ND_ENABLETRANSCODINGCONFIG: "true"
      ND_TRANSCODINGCACHESIZE: "10GB"
      TZ: "Europe/Moscow"
    volumes:
      - ./data:/data
      - ./music:/music:ro
    healthcheck:
      test: ["CMD", "wget", "-q", "--spider", "http://localhost:4533/ping"]
      interval: 30s
      timeout: 5s
      retries: 3

Пояснения по ключевым переменным:

• ND_SCANSCHEDULE: "1h" — Navidrome раз в час проверяет папку /music на новые файлы и переиндексирует. Можно поставить 0 и запускать сканирование вручную из веб-интерфейса, если коллекция статична.
• :ro на томе ./music — папка с музыкой монтируется только для чтения, Navidrome не может её случайно изменить или удалить, только читать.
• ND_TRANSCODINGCACHESIZE — кэш уже перекодированных файлов, чтобы не транскодировать один и тот же трек повторно при повторном прослушивании.
• TZ — важно выставить свой часовой пояс, иначе даты добавления треков и логи будут путать.

Запуск:

cd /opt/navidrome
docker compose up -d

Проверить, что контейнер поднялся и здоров:

docker compose ps
docker compose logs -f navidrome

Первый запуск открывает мастер создания администратора — заходите на http://ваш-ip:4533, задаёте логин и пароль. Дальше можно создавать дополнительных пользователей с ограниченными правами через Settings → Users.

Настройка транскодирования

По умолчанию Navidrome отдаёт файлы как есть (direct stream), что хорошо для локальной сети или быстрого интернета. Для мобильного использования имеет смысл настроить транскодинг-профили: Settings → Transcoding. Там же указывается путь к ffmpeg — в официальном образе он уже встроен, дополнительно ставить ничего не нужно.

Типичные профили, которые стоит добавить:

• MP3 320k — универсальный, читается любым клиентом.
• Opus 128k — заметно лучше по качеству на тот же битрейт, но не все старые клиенты его поддерживают.
• Opus 96k — для мобильного интернета с ограничениями по трафику.

В настройках пользователя (Settings → Users → выбрать пользователя) можно назначить дефолтный транскодинг-профиль конкретно для этого аккаунта — например, детям или гостевым учёткам выдавать более сжатый поток, а себе — оригинал.

Учтите: если у вас коллекция в основном уже в MP3 320k, транскодировать её дополнительно смысла нет — CPU потратится, а разницы не будет. Транскодирование полезно именно для FLAC/ALAC коллекций, где исходник тяжёлый.

HTTPS и доступ извне через Traefik

Открывать порт 4533 напрямую в интернет без HTTPS — плохая идея, пароль будет уходить в открытом виде. Если на сервере уже настроен reverse proxy — добавьте туда Navidrome как ещё один сервис. Пример для Traefik (лейблы вместо отдельного docker-compose):

services:
  navidrome:
    image: deluan/navidrome:latest
    container_name: navidrome
    restart: unless-stopped
    environment:
      ND_BASEURL: ""
      TZ: "Europe/Moscow"
    volumes:
      - ./data:/data
      - ./music:/music:ro
    networks:
      - traefik-net
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.navidrome.rule=Host(`music.example.com`)"
      - "traefik.http.routers.navidrome.entrypoints=websecure"
      - "traefik.http.routers.navidrome.tls.certresolver=letsencrypt"
      - "traefik.http.services.navidrome.loadbalancer.server.port=4533"

networks:
  traefik-net:
    external: true

Если Traefik ещё не настроен, у нас есть отдельный разбор — Traefik на VPS. Альтернатива для тех, кто не хочет разбираться с лейблами — nginx с обычным reverse-proxy блоком и Certbot для сертификата, схема тоже рабочая и проще для новичка.

Отдельно про ND_BASEURL — если Navidrome будет доступен по поддомену без под-пути (как в примере выше), оставляйте пустым. Значение нужно указывать, только если публикуете сервис по под-пути вида example.com/music — тогда прописывайте ND_BASEURL: "/music".

Резервное копирование и перенос коллекции

Вся конфигурация, база пользователей, плейлисты, история прослушиваний и статистика хранятся в /opt/navidrome/data в виде SQLite-файла. Это единственное, что действительно нужно бэкапить регулярно — саму музыку, если она уже где-то есть в другом месте (NAS, облако), можно не дублировать в бэкапах VPS.

Простой скрипт для ежедневного бэкапа базы:

#!/bin/bash
DATE=$(date +%Y%m%d)
mkdir -p /opt/backups/navidrome
docker compose -f /opt/navidrome/docker-compose.yml stop navidrome
tar -czf /opt/backups/navidrome/nd-data-$DATE.tar.gz -C /opt/navidrome data
docker compose -f /opt/navidrome/docker-compose.yml start navidrome
find /opt/backups/navidrome -name "*.tar.gz" -mtime +14 -delete

Останавливать контейнер перед архивацией SQLite-файла — хорошая практика, чтобы не получить бэкап "на лету" с недописанными транзакциями. Простой на пару секунд для домашнего сервера некритичен. Для более серьёзного подхода к бэкапам на сервере в целом стоит посмотреть BorgBackup в Docker Compose — дедупликация и шифрование снимают вопрос о переполнении диска бэкапами.

Перенос на новый сервер сводится к переносу двух папок — data и music — и повторному запуску того же docker-compose.yml. Никакой миграции базы делать не нужно, SQLite переезжает как обычный файл.

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