Audiobookshelf ради полки аудиокниг, которая влезает на флешку

MAATRIX

Audiobookshelf регулярно всплывает в списках «must-have self-hosted проектов» рядом с Jellyfin и Navidrome, и желание развернуть себе такой же выглядит логично: свой сервер аудиокниг, красивая библиотека с обложками, прогресс прослушивания синхронизируется между телефоном и планшетом. Но если вся коллекция — двадцать аудиокниг и пяток подкастов, которые физически помещаются на одну флешку, вопрос не «как поставить», а «а оно вам вообще надо». Разбираемся честно: как разворачивается Audiobookshelf, что он реально даёт и с какого объёма библиотеки эта инфраструктура начинает окупаться, а не просто добавлять точку отказа.

Что такое Audiobookshelf и когда о нём вообще стоит думать

Audiobookshelf — open-source сервер для аудиокниг и подкастов: бэкенд на Node.js, встроенная база SQLite, веб-интерфейс на Vue и собственные мобильные приложения. По устройству он ближе к Jellyfin, чем к простому файловому серверу: сканирует указанные папки, вытаскивает метаданные (автор, серия, обложка, длительность, главы), хранит для каждого пользователя прогресс прослушивания, закладки и скорость воспроизведения, отдаёт контент через прямой стрим или, при необходимости, транскодирует на лету через ffmpeg.

Ключевая ценность именно в состоянии, а не в раздаче файлов. Файл вы могли бы скачать и через обычный файловый сервер — про такой вариант мы отдельно писали. Audiobookshelf ценен тем, что помнит: вы остановились на 3 часа 42 минуты в 14-й главе, открыли книгу вечером на другом устройстве — а она сама промотала на нужное место. Для одной книги на одном телефоне эта функция не стоит поднятия сервера. Для библиотеки в сотни файлов, нескольких слушателей в семье и параллельной подписки на подкасты — стоит, и разница ощущается быстро.

Ресурсы под сам сервер скромные: 512 МБ — 1 ГБ RAM и одно ядро тянут библиотеку в тысячи файлов без проблем, основная нагрузка — на диск под сами аудиофайлы и кратковременные всплески CPU при первом сканировании и подтяжке обложек. Раздутый VPS под это брать не нужно — хватает базового тарифа, где узкое место обычно не CPU, а объём диска под саму библиотеку.

Установка на VPS: Docker Compose и первый запуск

Официальный образ публикуется в GitHub Container Registry, ставим через Docker Compose:

services:
  audiobookshelf:
    image: ghcr.io/advplyr/audiobookshelf:latest
    container_name: audiobookshelf
    restart: unless-stopped
    ports:
      - "13378:80"
    volumes:
      - /opt/audiobookshelf/config:/config
      - /opt/audiobookshelf/metadata:/metadata
      - /mnt/audiobooks:/audiobooks
      - /mnt/podcasts:/podcasts
    environment:
      - TZ=Europe/Moscow
      - AUDIOBOOKSHELF_UID=1000
      - AUDIOBOOKSHELF_GID=1000

Четыре тома здесь не взаимозаменяемы, и путать их не стоит:

• /config — настройки сервера, пользователи, ключи API;
• /metadata — база SQLite, кэш обложек, кэшированные метаданные, бэкапы библиотеки;
• /audiobooks и /podcasts — сами медиафайлы, можно смонтировать с отдельного диска или сетевого хранилища.

AUDIOBOOKSHELF_UID/AUDIOBOOKSHELF_GID выставляют, от чьего имени процесс внутри контейнера пишет в примонтированные папки — полезно сразу указать UID/GID вашего обычного пользователя на хосте, иначе потом придётся руками разгребать права на файлы, созданные из-под root внутри контейнера. Версию образа намеренно не фиксируем цифрой — latest вполне рабочий вариант для домашнего использования, но если сервер продакшен-важный, зафиксируйте конкретный тег после того, как проверите его на тестовом окружении.

Поднимаем и проверяем:

docker compose up -d
docker compose logs -f audiobookshelf

После первого старта сервис слушает 13378 внутри вашей сети. Наружу лучше отдавать не порт напрямую, а через nginx с TLS — тем более что Audiobookshelf использует websocket (Socket.IO) для живого обновления прогресса и статуса сканирования, и заголовки апгрейда соединения нужно прокидывать явно:

server {
    listen 443 ssl;
    server_name audiobooks.example.com;

    ssl_certificate     /etc/letsencrypt/live/audiobooks.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/audiobooks.example.com/privkey.pem;

    client_max_body_size 200M;

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

client_max_body_size увеличен, потому что при загрузке обложек или бэкапов библиотеки через веб-интерфейс дефолтный лимит nginx в 1 МБ иногда режет запрос без внятной ошибки на стороне клиента — это одна из тех граблей, на которую натыкаешься не сразу, а только когда пробуешь залить конкретный файл.

Библиотека, метаданные и структура папок

Audiobookshelf организует контент в «библиотеки» — раздельные разделы для книг и подкастов, у каждой свой набор папок для сканирования. Внутри библиотеки книг одна папка = один элемент: либо цельный .m4b с главами внутри контейнера, либо папка с набором .mp3, которые сервер сам склеивает в единый плеер-трек по порядку файлов.

Рабочая структура папок, которую рекомендует сам проект и которая избавляет от путаницы при сканировании:

/audiobooks/
  Автор Имя/
    Название книги/
      01 - Глава первая.mp3
      02 - Глава вторая.mp3
      cover.jpg
    Название серии/
      Книга 1 из серии/
        book.m4b
      Книга 2 из серии/
        book.m4b

Метаданные Audiobookshelf берёт из нескольких источников: встроенные ID3/M4B-теги файла, файл metadata.json/.opf рядом с книгой (если он есть — например, от Calibre), и, при ручном или автоматическом матчинге, внешние провайдеры вроде Audible, iTunes, OpenLibrary, Google Books — сервер ищет по названию и автору, показывает варианты, вы выбираете подходящий. Для собранной вручную коллекции это удобно: не нужно вручную вбивать описание и искать обложку для каждой книги — но и не идеально: неточные названия файлов иногда путают автопоиск, и часть книг приходится матчить руками, особенно если это переводная или редкая литература, которой нет в англоязычных базах.

Отдельный нюанс — многотомные серии и книги с несколькими начитчиками одного произведения: Audiobookshelf хранит их как разные элементы библиотеки, связанные полем «серия», а не как версии одной книги. Если в коллекции есть одна и та же книга в двух начитках, они будут двумя карточками — это осознанное архитектурное решение, а не баг, но к нему стоит быть готовым, если предполагали автоматическое объединение дублей.

Синхронизация прогресса, мобильные приложения и подкасты

Ради этого пункта весь сервер и затевается. Прогресс прослушивания, закладки и скорость воспроизведения хранятся на сервере в привязке к пользователю, а не к устройству — открываете книгу в браузере на компьютере, продолжаете в приложении на телефоне, сервер сам подхватывает точную позицию. У проекта есть официальное мобильное приложение (Android — в Google Play; статус iOS-версии на момент публикации стоит уточнить в разделе Mobile Apps на сайте проекта, доступность там периодически менялась) с офлайн-загрузкой книг для прослушивания без сети и последующей досинхронизацией прогресса при появлении связи.

Многопользовательский режим встроен штатно: можно завести отдельный аккаунт на каждого члена семьи, у каждого будет свой прогресс, свои закладки и, при желании, ограниченный доступ только к части библиотеки (например, детский раздел отдельно от взрослого). Права можно тонко настраивать — от «только слушать» до полного администрирования библиотеки.

Подкасты в Audiobookshelf — не костыль поверх книжного движка, а отдельная полноценная библиотека с подпиской по RSS-ссылке, автоматическим скачиванием новых эпизодов по расписанию и настройкой хранения (например, держать только последние N эпизодов, а старые удалять автоматически). По сути это self-hosted подкаст-агрегатор, который параллельно решает и задачу с аудиокнигами — если вам важны оба сценария сразу, это весомый аргумент в пользу единого сервера вместо двух разных инструментов.

Настоящая цена: ресурсы, бэкапы и обслуживание базы

Здесь стоит проговорить то, что в восторженных гайдах обычно опускают. Audiobookshelf — это не просто раздача файлов, это сервис с состоянием: пользователи, прогресс, закладки и связи между файлами и метаданными живут в SQLite-базе под /metadata. Если эта база повреждена или потеряна, сами аудиофайлы никуда не денутся, но весь прогресс прослушивания, закладки и настройки пользователей — восстанавливать неоткуда, кроме как из бэкапа. Библиотеку можно пересканировать заново, а вот «на чём вы остановились» — нет.

Из этого вытекает практическое правило: бэкапить нужно не только сами аудиофайлы (что естественно и так делается), а отдельно и регулярно — папки /config и /metadata. Это несравнимо меньший объём данных, чем сама медиатека, но именно в них хранится всё, что отличает Audiobookshelf от простой файлопомойки.

Дальше — вопрос обслуживания как таковой. Обновление образа, слежение за релизами (проект развивается активно, ломающие изменения в схеме базы или API случаются), настройка HTTPS и открытого порта, мониторинг, что сервис вообще жив — весь обычный набор забот self-hosted сервиса, который есть у любого другого приложения на VPS. Для библиотеки в несколько сотен файлов и нескольких активных слушателей это оправданные накладные расходы. Для «десятка книг, которые слушаю только я на одном телефоне» — это инфраструктура ради инфраструктуры, а не ради реальной задачи.

Когда сервер избыточен: полка на флешку или облачный диск

Вот тут стоит остановиться и честно прикинуть объём. Аудиокнига среднего качества (около 64–128 кбит/с, длительность 10–15 часов) занимает ориентировочно от полутора до четырёх гигабайт — точные цифры у вас будут отличаться в зависимости от формата и битрейта, но порядок величины такой. На флешку в 32–64 ГБ спокойно помещается несколько десятков книг целиком, вместе с обложками и метаданными в тегах файлов. Если ваша реальная коллекция — это именно такой объём, а не тысячи файлов с постоянным пополнением, разворачивать под неё сервер с базой данных, пользователями и веб-интерфейсом — решение не по масштабу задачи.

Что вместо этого реально работает для скромной библиотеки:

Один слушатель, одно-два устройства. Самый простой вариант — локальный плеер для аудиокниг на телефоне (таких приложений много и на Android, и на iOS, они сами читают ID3-теги, главы внутри .m4b, запоминают позицию и скорость воспроизведения без всякого сервера). Файлы просто копируются на устройство через USB, облачный диск или напрямую с флешки через OTG-кабель или картридер. Прогресс прослушивания в этом случае и не нужно синхронизировать между устройствами — вы слушаете с одного и того же телефона.

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

Уже есть облачный диск для других задач. Если вы уже держите свой Nextcloud под фото и документы, туда же спокойно ложится и папка с аудиокнигами — доступ через WebDAV с телефона, часть плееров умеет открывать файлы прямо по WebDAV-ссылке без предварительного скачивания. Отдельный сервер ради дублирования того, что уже умеет существующий диск, — лишняя сущность.

Захотелось именно красивую библиотеку с обложками и полки — но объём пока небольшой. Тут честный ответ: красота обложек и структурированный каталог того стоят, если библиотека растёт и её становится неудобно перебирать глазами в файловом менеджере. Если рост не планируется — часть этой же пользы (обложка, метаданные, главы) дают локальные плееры без всякого сервера, просто раскладывая теги из самого файла. Порог, после которого выделенный каталог с базой данных реально экономит время, а не тратит его на обслуживание, — это не «десять книг», а момент, когда вы физически перестаёте помнить, что у вас есть и на чём вы остановились, без посторонней подсказки.

Логика здесь та же, что и в других self-hosted медиасерверах — например, для музыки схожий разбор «когда своя коллекция уже не помещается в голове и пора её систематизировать» разбирали в статье про Navidrome: порог окупаемости отдельного сервера определяется не типом контента, а реальным объёмом и числом слушателей, а не желанием иметь «как у всех».

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