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

MAATRIX

Obsidian и Notion удобны, пока заметки живут в одном плоском списке или паре папок — как только структура разрастается до сотен страниц с перекрёстными связями, начинается хаос из тегов и бэклинков, в которых сложно ориентироваться. Trilium Notes решает это буквально деревом: каждая заметка — узел, у узла могут быть дочерние заметки любой вложенности, а одна и та же заметка способна одновременно находиться в нескольких ветках дерева через клонирование. Ниже — рабочий docker-compose.yml, разбор первого запуска и настройка синхронизации с десктопным клиентом, ради которой Trilium чаще всего и поднимают на сервере, а не используют только локально.

Trilium Notes и TriliumNext: что это и почему два имени

Оригинальный Trilium Notes с 2017 года разрабатывал один автор (zadam), и к 2024 году проект стал одной из самых зрелых self-hosted альтернатив Notion/Evernote: иерархическое дерево заметок неограниченной вложенности, богатый редактор на базе CKEditor с поддержкой таблиц, кода и математических формул, встроенное шифрование отдельных веток дерева, скриптинг на JavaScript через атрибуты заметок и REST API (ETAPI) для внешних интеграций.

В 2024 году оригинальный автор объявил о паузе в поддержке, и сообщество продолжило разработку под форком TriliumNext Notes — тем же кодом, с продолжающимися релизами и исправлениями. На практике это значит: образ zadam/trilium в Docker Hub больше не обновляется, актуальный образ — triliumnext/notes. Формат данных полностью совместим, так что этот момент важен только при выборе образа для установки, а не при работе с самими заметками.

Если нужна именно плоская структура с обратными ссылками между заметками в духе Zettelkasten, Outline Wiki или связка markdown-файлов подойдут точнее. Trilium выигрывает там, где база знаний естественно организована иерархически — документация, справочник по проектам, персональная вики с разделами и подразделами.

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

Node.js-процесс плюс SQLite в одном файле — стек лёгкий, отдельная СУБД не нужна вовсе.

Цифры ориентировочные — сам движок нетребователен, но если в заметки активно вкладывают файлы (скриншоты, PDF, архивы), диск растёт быстрее, чем кажется на старте. SQLite отлично держит нагрузку одного-нескольких одновременных пользователей; для десятков параллельных редакторов такой профиль использования Trilium не рассчитан изначально.

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

Структура каталогов на сервере:

/opt/trilium/
├── trilium-data/     # база SQLite, вложения, конфиг
└── docker-compose.yml

Создаём каталог и docker-compose.yml:

mkdir -p /opt/trilium/trilium-data
cd /opt/trilium
nano docker-compose.yml

Содержимое файла:

services:
  trilium:
    image: triliumnext/notes:latest
    container_name: trilium
    restart: unless-stopped
    environment:
      TRILIUM_DATA_DIR: /home/node/trilium-data
      # Часовой пояс важен для меток времени в заметках
      TZ: Europe/Moscow
    volumes:
      - ./trilium-data:/home/node/trilium-data
    ports:
      - "127.0.0.1:8080:8080"

Всё состояние — сама база заметок, вложения, история версий и настройки — лежит в единственном каталоге trilium-data, смонтированном как volume. Это упрощает бэкап и перенос на другой сервер до предела: остановили контейнер, скопировали каталог, запустили на новом хосте — миграция БД не нужна, потому что SQLite это просто файл. Порт 8080 отдаём только на 127.0.0.1, наружу — через реверс-прокси, раздел ниже.

Поднимаем стек:

docker compose up -d
docker compose logs -f trilium

Первый старт занимает несколько секунд — контейнер инициализирует пустую базу SQLite при отсутствии данных в volume. В логах должна появиться строка о том, что сервер слушает порт 8080.

Первый запуск и дерево заметок

Открываем http://<IP-сервера>:8080 (или домен, если прокси уже настроен). При первом заходе Trilium предлагает задать пароль — он защищает не отдельный аккаунт, а весь инстанс: сессия хранится в браузере, повторный вход спрашивает тот же пароль. Отдельной регистрации пользователей с ролями в базовой версии нет — Trilium рассчитан на одного владельца инстанса (лично для себя или для доверенной команды с общим доступом), а не на публичный сервис с разграничением прав.

После входа — пустое дерево с корневой заметкой Root. Базовые операции:

• Новая заметка — Ctrl+O или значок + рядом с деревом, создаётся как дочерняя к выбранной.
• Клонирование — Ctrl+Shift+C на заметке: та же заметка появляется ещё в одной ветке дерева, изменения синхронны в обеих. Полезно для заметок, которые логически относятся сразу к нескольким разделам (например, заметка о сотруднике одновременно и в разделе «Команда», и в разделе конкретного проекта).
• Переход между заметками — Ctrl+J открывает быстрый поиск по названиям, без необходимости листать дерево вручную.
• Day Notes (журнал) — специальная ветка Calendar, где каждый день автоматически создаётся своя заметка. Удобно как ежедневник, куда стекаются заметки-однодневки, не засоряя основное дерево.

Редактор поддерживает markdown-подобный ввод (например, ## в начале строки превращается в заголовок), таблицы, блоки кода с подсветкой синтаксиса и вставку изображений прямо из буфера обмена — файл при этом сохраняется как вложение к заметке, а не как внешняя ссылка.

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

Ключевая причина держать Trilium именно на сервере, а не только локально на ноутбуке, — синхронизация. Схема работы обратная привычной: сервер — источник истины, а десктопное приложение (Windows/macOS/Linux) синхронизируется с ним, а не наоборот.

Настройка на стороне десктопного клиента:

1. Скачиваем и устанавливаем десктопное приложение TriliumNext с GitHub Releases проекта.
2. При первом запуске выбираем Sync with server вместо локальной базы.
3. Указываем адрес сервера (https://trilium.your-domain.example) и пароль инстанса.
4. Клиент скачивает полную копию дерева заметок и дальше работает в режиме sync — правки в любую сторону (сервер или десктоп) распространяются при следующей синхронизации, обычно раз в несколько секунд при активном соединении.

Такая архитектура даёт офлайн-режим по умолчанию: десктопный клиент хранит собственную локальную копию базы и работает без сети, а при восстановлении соединения подтягивает изменения. Конфликты правок одной и той же заметки в разных местах Trilium разрешает автоматически по принципу «побеждает более позднее изменение», без ручного merge — для базы знаний, где редко правят один и тот же абзац одновременно из двух мест, это работает надёжно.

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

HTTPS, шифрование и бэкап

Пароль инстанса и содержимое заметок не должны идти открытым текстом — закрываем доступ Caddy с автоматическим Let's Encrypt:

# /etc/caddy/Caddyfile
trilium.your-domain.example {
    reverse_proxy 127.0.0.1:8080
}

Если Caddy на сервере ещё не настроен, разбор есть в статье про установку Caddy с авто-SSL на VPS — там же общие грабли, если в процессе что-то пошло не так.

Отдельно от HTTPS у Trilium есть встроенное шифрование на уровне веток дерева (Protected notes): выбираем ветку → Protect subtree, дальше содержимое заметок в этой ветке шифруется отдельным паролем и не читается без явного ввода этого пароля в текущей сессии, даже если у кого-то есть доступ к самому серверу и файлу базы. Это полезно для действительно чувствительных данных (пароли, личные записи) внутри общей базы знаний, которую в остальном видит команда.

Бэкап сводится к копированию одного каталога — никакого дампа СУБД не требуется:

docker compose stop trilium
tar czf /opt/trilium/backups/trilium-$(date +%F).tar.gz -C /opt/trilium trilium-data
docker compose start trilium

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

Обновление — стандартный pull + up:

docker compose pull trilium
docker compose up -d trilium

Схема базы обновляется автоматически при первом старте новой версии контейнера. Перед обновлением на новую мажорную версию имеет смысл сделать свежий архив каталога trilium-data — как и у любого приложения с миграциями данных на лету, штатного отката на предыдущую версию после неудачной миграции не предусмотрено.

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