Селф-хостинг Notesnook и Standard Notes: сравнительный анализ

Заметки с end-to-end шифрованием становятся стандартом для пользователей, заботящихся о приватности. Два наиболее зрелых open-source решения в этой нише — Notesnook и Standard Notes — предлагают возможность самостоятельного размещения сервера синхронизации. Этот обзор анализирует практические аспекты селф-хостинга обоих решений: от архитектуры и системных требований до интеграции с клиентскими приложениями и типичных проблем при развёртывании.

Архитектура и компоненты

Standard Notes

Standard Notes использует микросервисную архитектуру, существенно упрощённую в версии 2 (февраль 2023)¹. Текущая версия состоит из четырёх Docker-контейнеров вместо тринадцати в legacy-версии, что привело к сокращению потребления памяти на 65%².

Основные компоненты:

• API Gateway — точка входа, маршрутизирующая запросы от клиентов к внутренним сервисам
• Syncing Server (+ Worker) — управление данными пользователей и синхронизация; Worker обрабатывает асинхронные задачи (email-бэкапы, история ревизий)
• Auth Service (+ Worker) — авторизация и аутентификация; Worker занимается задачами вроде удаления аккаунтов
• MySQL — основная база данных
• Redis — кэш и очередь сообщений между сервисами
• LocalStack — эмуляция S3 для хранения файлов (вложения, зашифрованные бэкапы)

Web-приложение — отдельный контейнер, не входящий в базовый стек. Его можно развернуть дополнительно через docker run -d -p 3000:80 standardnotes/web³.

Notesnook

Notesnook построен на .NET 8 и состоит из трёх core-сервисов⁴:

• Notesnook.API — основной сервис синхронизации данных
• Streetwriters.Identity — аутентификация и авторизация
• Streetwriters.Messenger — Server-Sent Events для real-time синхронизации

Инфраструктурные зависимости:

• MongoDB — база данных
• MinIO — S3-совместимое хранилище для вложений
• cors-proxy — обработка CORS-запросов

Дополнительно может быть развёрнут web-клиент (React-приложение) и Monograph Server для публичного шаринга заметок.

Сравнение архитектур

Системные требования

Standard Notes

Официальные минимальные требования²:

• ОС: Linux (Ubuntu 22.04 или совместимый дистрибутив)
• RAM: 2 ГБ (минимум), 4 ГБ рекомендуется
• CPU: 1 vCore
• Docker: актуальная версия
• Хранилище: зависит от объёма заметок и вложений; 10 ГБ для начала

Notesnook

Официальные требования не формализованы (альфа-стадия). По данным сообщества⁵⁶:

• RAM: 2 ГБ (минимум), 4 ГБ рекомендуется (MongoDB потребляет больше при росте базы)
• Docker и Docker Compose
• Хранилище: от 10 ГБ (MongoDB + MinIO)
• Сеть: несколько портов (5264, 6264, 7264, 8264, 9090, 9009)

Для сборки из исходников потребуется .NET 8 SDK и Git⁴.

Процесс развёртывания

Standard Notes: Docker (рекомендуемый метод)

Standard Notes предоставляет подробную официальную документацию². Процесс:

1. Подготовка рабочей директории:

mkdir standardnotes && cd standardnotes

2. Получение конфигурационных файлов:

curl https://raw.githubusercontent.com/standardnotes/server/main/.env.sample > .env
curl https://raw.githubusercontent.com/standardnotes/server/main/docker-compose.example.yml > docker-compose.yml
curl https://raw.githubusercontent.com/standardnotes/server/main/docker/localstack_bootstrap.sh > localstack_bootstrap.sh
chmod +x localstack_bootstrap.sh

3. Генерация секретов и настройка .env:

openssl rand -hex 32  # для AUTH_JWT_SECRET, VALET_TOKEN_SECRET и др.
openssl rand -hex 12  # для DB_PASSWORD

Ключевые переменные: DB_PASSWORD, AUTH_JWT_SECRET, VALET_TOKEN_SECRET, ENCRYPTION_SERVER_KEY. Пароль БД указывается в трёх местах: .env и два раза в docker-compose.yml (MYSQL_ROOT_PASSWORD, MYSQL_PASSWORD)².

4. Запуск:

docker compose pull && docker compose up -d

5. Проверка:

Сервер доступен по http://localhost:3000. Логи: tail -f logs/*.log².

6. Настройка HTTPS (для продакшна):

Reverse proxy (Nginx, Traefik или Caddy) с SSL-сертификатом. Standard Notes предоставляет отдельную документацию по настройке HTTPS⁷.

Notesnook: Docker

Официальная документация минимальна (помечена как TODO)⁴. Базовый процесс:

1. Получение docker-compose.yml:

wget https://raw.githubusercontent.com/streetwriters/notesnook-sync-server/master/docker-compose.yml

2. Запуск:

docker compose up

Docker Compose автоматически поднимает MongoDB, MinIO и три core-сервиса⁴.

Однако для production-развёртывания этого недостаточно. Сообщество создало расширенные конфигурации⁵⁶⁸, которые включают:

• Создание структуры директорий для данных (database/, storage/, config/)
• Настройку .env файла с доменами, SMTP-credentials, токенами API
• Конфигурацию reverse proxy с поддержкой WebSocket для субдоменов
• Инициализацию MongoDB replica set

Пример структуры:

/srv/notesnook/
  database/     # MongoDB data
  storage/      # MinIO data
  config/       # Environment и конфигурация

Для Notesnook требуется настройка нескольких субдоменов: отдельные для API, Identity, Messenger и (опционально) web-клиента⁵.

Сравнение процесса развёртывания

Подписка и premium-функции

Standard Notes: модель подписки для self-hosted

Standard Notes предлагает два пути получения premium-функций на self-hosted сервере¹⁰:

Путь 1 — Server-side подписка (бесплатно):

Создаётся вручную через SQL-команды в MySQL. Разблокирует серверные функции (синхронизация файлов, история ревизий, email-бэкапы), но не разблокирует клиентские функции (Super Notes, вложенные теги, расширенные редакторы)¹⁰.

Путь 2 — Offline-подписка (платно):

Приобретается на сайте Standard Notes. Разблокирует все функции, включая клиентские. Стоимость значительно ниже облачной подписки¹¹:

Для пользователя с существующим ключом Standard Notes: offline-подписка активируется через код в приложении. Процесс: покупка offline-плана на сайте, получение кода активации, ввод в Desktop/Mobile клиенте через Settings. Существующий ключ облачной подписки не переносится на self-hosted сервер напрямую — это разные системы авторизации¹⁰.

Notesnook: бесплатная модель

Notesnook при селф-хостинге не требует подписки для использования серверных функций⁴. Все возможности синхронизации доступны бесплатно на собственном сервере. Однако некоторые клиентские функции (вложения, расширенное редактирование) требуют Pro-подписки Notesnook ($49.99/год или $4.99/мес)¹², при этом пока не документировано, как именно подписка взаимодействует с self-hosted инстансом.

Интеграция с клиентскими приложениями

Standard Notes

Desktop-приложения (Windows, macOS, Linux) и мобильные (iOS, Android) полностью поддерживают подключение к self-hosted серверу²:

1. Открыть меню аккаунта
2. Нажать “Advanced options”
3. Выбрать “Custom” в разделе “Sync Server”
4. Ввести URL сервера (например, https://sync.example.org)
5. Зарегистрировать новый аккаунт или войти в существующий

Web-приложение (app.standardnotes.com) не поддерживает подключение к self-hosted серверу из-за Content Security Policy (CSP), ограничивающей домены для подключения³. Для веб-доступа необходимо развернуть собственный экземпляр web-приложения:

docker run -d -p 3001:80 standardnotes/web

Это существенное ограничение: для полноценного использования с браузера требуется дополнительный контейнер и настройка домена.

Notesnook

Начиная с версии 3.0.14, все клиенты Notesnook поддерживают настройку custom server URL через Settings > Server¹³:

• Desktop: Windows, macOS, Linux
• Mobile: iOS, Android
• Web: web.notesnook.com (или self-hosted web-клиент)

Преимущество Notesnook — возможность динамически переключаться между серверами без переустановки приложения¹³. Все клиенты работают идентично с self-hosted инстансом и облачным сервисом.

Сравнение клиентской интеграции

End-to-end шифрование

Standard Notes

Шифрование происходит полностью на стороне клиента до отправки данных на сервер. Сервер хранит только зашифрованные данные и не имеет возможности их расшифровать (zero-knowledge архитектура)¹⁴. При self-hosted развёртывании модель шифрования не меняется — ключи шифрования генерируются и хранятся на устройстве пользователя.

Standard Notes прошёл независимый аудит безопасности, результаты которого опубликованы¹⁴.

Notesnook

Notesnook использует XChaCha20-Poly1305 для шифрования с Argon2 для деривации ключей¹⁵. Как и в случае Standard Notes, шифрование — клиентское, сервер получает только зашифрованные данные.

Дополнительно Notesnook предоставляет инструмент Vericrypt — офлайн-верификатор, позволяющий убедиться, что данные действительно зашифрованы end-to-end¹⁶. Vericrypt работает с реальными данными аккаунта и подтверждает корректность деривации ключей.

Notesnook не проходил формальный аудит безопасности, но весь код открыт (включая серверную часть), что позволяет независимую верификацию¹⁵.

Влияние self-hosted на шифрование

В обоих случаях self-hosting не ослабляет шифрование. Напротив, он добавляет контроль над метаданными: владелец сервера контролирует access-логи, IP-адреса подключений и временные метки синхронизации, которые в облачной модели доступны провайдеру.

Резервное копирование и миграция

Standard Notes

Бэкап сервера:

docker compose down
# Скопировать директорию data/ целиком
cp -r data/ /backup/standardnotes-$(date +%Y%m%d)/
docker compose up -d

Миграция из облака: Экспорт данных из облачного аккаунта (Settings > Backups > Download), затем импорт на self-hosted сервере через регистрацию нового аккаунта и импорт бэкапа. Аккаунт не “переносится” — создаётся новый⁷.

Миграция V1 → V2: Standard Notes предоставляет инструкции по обновлению legacy-инсталляций до версии 2².

Notesnook

Бэкап: MongoDB и MinIO требуют раздельного бэкапа. Для MongoDB: mongodump, для MinIO: копирование директории данных⁴.

Миграция из облака: Notesnook поддерживает экспорт в несколько форматов (Markdown, HTML, текст). Импорт на self-hosted сервере возможен через стандартный механизм импорта в клиенте¹³.

Типичные проблемы и решения

Standard Notes

Бесконечный цикл авторизации (infinite login loop)

Наиболее часто упоминаемая проблема в сообществе⁹¹⁷. Причина — неверно заданная переменная COOKIE_DOMAIN в .env. Значение должно точно соответствовать домену, через который клиенты подключаются к серверу.

# Правильно:
COOKIE_DOMAIN=sync.example.org
# Неправильно (с протоколом или портом):
COOKIE_DOMAIN=https://sync.example.org:3000

Ошибки загрузки файлов

Files Server работает на отдельном порте (3125 по умолчанию). Если reverse proxy не маршрутизирует этот порт, загрузка файлов не работает. Решение — настроить отдельный проксирующий location или субдомен для файлового сервера².

Проблемы мобильных приложений с сертификатами

Self-signed сертификаты или сертификаты от нестандартных CA могут не приниматься мобильными клиентами. Решение — использовать Let’s Encrypt⁹.

Web-приложение не подключается

Штатное ограничение: app.standardnotes.com блокирует запросы к нестандартным серверам через CSP³. Решение — развернуть собственный экземпляр web-приложения.

Notesnook

Нестабильность (альфа-стадия)

Главная проблема — self-hosting находится в альфа-стадии. Разработчики прямо предупреждают: “expect a lot of things not to work when connected to your own instance”⁴. Рекомендация — использовать для экспериментов, не для production.

Ошибки при загрузке вложений

Пользователи сообщают о “Network Error” и файлах размером 0 при загрузке через MinIO¹⁸. Причина — некорректная конфигурация MinIO endpoint или отсутствие HTTPS. Решение — использовать HTTPS для MinIO endpoint и проверить bucket policies.

MongoDB replica set

Notesnook требует инициализации MongoDB replica set, что не всегда очевидно из минимальной документации⁵. Без replica set некоторые операции (транзакции, change streams) не работают.

SMTP-конфигурация

Для регистрации и восстановления пароля требуется рабочий SMTP-сервер. Без него — невозможно создать аккаунт через web-интерфейс⁵.

Отсутствие документации

Основная практическая проблема. Официальная документация помечена как TODO. Сообщество создало неофициальные гайды⁵⁶⁸, но они быстро устаревают.

Обновление сервера

Standard Notes

Процесс обновления документирован²:

docker compose down
# Обновить docker-compose.yml, .env, localstack_bootstrap.sh
docker compose pull
docker compose up -d

Перед обновлением рекомендуется сделать полный бэкап данных.

Notesnook

Процесс обновления не документирован официально. Предполагаемый подход:

docker compose down
docker compose pull
docker compose up -d

Риск: при отсутствии миграционных скриптов обновления могут сломать существующую базу данных.

Итоговое сравнение

Рекомендации

Standard Notes — обоснованный выбор для production self-hosting:

• Зрелая инфраструктура с документированным процессом развёртывания
• Прошёл аудит безопасности
• При наличии существующего ключа: потребуется приобрести offline-подписку ($39/год) для полного набора функций на self-hosted сервере — облачная подписка не переносится
• Основной недостаток — необходимость отдельного контейнера для web-приложения

Notesnook — перспективный, но незрелый вариант:

• Бесплатный self-hosting без ограничений серверных функций
• Более современная клиентская архитектура (динамическое переключение серверов)
• Не готов для production-использования (альфа-стадия, нет документации, нет поддержки)
• Стоит отслеживать развитие — команда заявила, что self-hosting станет приоритетом после стабилизации v3¹³

Для пользователя с существующим ключом Standard Notes оптимальный путь: развернуть Standard Notes Server через Docker, приобрести offline Professional подписку ($39/год), настроить reverse proxy с Let’s Encrypt, подключить desktop и mobile клиенты через “Custom Sync Server”. Web-доступ — через отдельный контейнер standardnotes/web.

Дискуссионные вопросы и противоречия

Стоимость self-hosting vs. облачной подписки. Offline-подписка Standard Notes ($39/год) дешевле облачной ($120/год), но к ней добавляется стоимость серверной инфраструктуры (VPS от $5-10/мес). При использовании домашнего сервера экономия существенна; при аренде VPS — менее очевидна⁹.

Notesnook: open-source без реального self-hosting. Несмотря на AGPLv3-лицензию и открытый серверный код, практическая возможность self-hosting остаётся ограниченной из-за альфа-стадии и отсутствия документации. Часть сообщества рассматривает это как “номинальный open-source”¹⁸.

Безопасность self-hosted vs. облачного. E2E-шифрование одинаково в обоих случаях. Аргумент за self-hosting — контроль над метаданными и отсутствие зависимости от жизнеспособности компании-провайдера. Аргумент против — необходимость самостоятельно обеспечивать безопасность сервера (обновления, firewall, мониторинг)¹⁴¹⁵.

Quality Metrics