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

MAATRIX

Облачные заметки удобны ровно до момента, когда вы вспоминаете, что каждая синхронизация проходит через чужой сервер, а доступ к архиву за десять лет зависит от того, не заблокируют ли аккаунт и не закроется ли сервис. Standard Notes с самого начала строился как приложение со сквозным шифрованием и открытым кодом — но по-настоящему независимым архив заметок становится только тогда, когда сервер, который их хранит, тоже ваш. Ниже — пошагово, как развернуть self-hosted Standard Notes на VPS: от Docker Compose до домена, бэкапов и подключения приложений.

Зачем самому хостить сервер Standard Notes

Standard Notes шифрует содержимое заметок на устройстве ещё до отправки на сервер — в этом смысле официальное облако standardnotes.com не читает текст ваших записей и в базовом сценарии self-hosting не даёт прироста приватности контента. Но у собственного сервера есть три практических причины:

• Независимость от чужой инфраструктуры. Аккаунт не заблокируют, тарифы не поменяют, сервис не закроют — история заметок живёт столько, сколько живёт ваш сервер и его бэкапы.
• Бесплатный доступ к «расширенным» функциям. На официальном облаке часть тем, редакторов и плагинов доступна только по платной подписке. На своём сервере такие ограничения обычно снимаются, потому что подписочная логика привязана именно к серверу, а не к клиентскому приложению — но проверяйте это в актуальной документации, поведение может отличаться от версии к версии.
• Контроль над метаданными. Даже при шифрованном теле заметки сервер видит время создания, размер, факт синхронизации. На своей инфраструктуре эти метаданные не покидают ваш периметр.

Обратная сторона — ответственность за апдейты, бэкапы и доступность сервера ложится на вас. Если это не пугает, переходим к делу.

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

Standard Notes self-hosted — это не один контейнер, а связка из нескольких сервисов (API-шлюз, аутентификация, синхронизация, файлы, вебсокеты, ревизии) плюс PostgreSQL и Redis. Точный набор сервисов в docker-compose.yml может немного меняться от версии к версии — сверяйтесь с актуальным файлом в репозитории при установке. Для комфортной работы небольшой команды или личного архива этого достаточно:

На 2 ГБ RAM сервис поднимется и будет работать для одного-двух пользователей, но при пиках (массовая синхронизация после долгого офлайна, загрузка вложений) стоит иметь запас — иначе Postgres или Node-процессы может убивать OOM killer. Дополнительно понадобится домен или поддомен (например, notes.вашдомен.ru), направленный A-записью на IP сервера, и открытые порты 80/443.

Устанавливаем Docker и разворачиваем сервер

Начинаем с чистого VPS на Ubuntu 24.04. Обновляем систему и ставим Docker официальным скриптом:

apt update && apt upgrade -y
apt install -y ca-certificates curl git
curl -fsSL https://get.docker.com | sh
usermod -aG docker $USER

После usermod перелогиньтесь (или выполните newgrp docker), чтобы работать с Docker без sudo. Проверяем, что Compose-плагин на месте:

docker compose version

Клонируем официальный репозиторий сервера Standard Notes:

git clone https://github.com/standardnotes/server.git standardnotes-server
cd standardnotes-server
cp .env.sample .env

Файл .env — это конфигурация всех сервисов: базы данных, секретов шифрования, публичных URL и лимитов. Его и предстоит заполнить.

Переменные окружения и ключи шифрования

В .env есть блок секретов, которые нельзя оставлять значениями по умолчанию — на них держится безопасность аутентификации и токенов. Обычно это переменные вроде AUTH_JWT_SECRET, ENCRYPTION_SERVER_KEY, VALET_TOKEN_SECRET, PSEUDO_KEY_PARAMS_KEY, WEBSOCKETS_JWT_SECRET — конкретный список смотрите в вашей копии .env.sample, он может отличаться в зависимости от версии сервера. Сгенерировать случайные значения удобно так:

for var in AUTH_JWT_SECRET ENCRYPTION_SERVER_KEY VALET_TOKEN_SECRET PSEUDO_KEY_PARAMS_KEY WEBSOCKETS_JWT_SECRET; do
  echo "$var=$(openssl rand -hex 32)"
done

Полученные строки вставьте в .env вместо заглушек. Дальше отредактируйте:

• DB_DATABASE, DB_USERNAME, DB_PASSWORD — задайте свой пароль для Postgres, не оставляйте пример из репозитория;
• CORS_ORIGIN — домен, с которого клиенты будут обращаться к серверу (например, https://notes.вашдомен.ru, а также https://app.standardnotes.com, если планируете заходить через официальный веб-клиент на свой сервер);
• переменные с публичным URL сервера — укажите тот же домен, который позже направите на VPS.

Секретные значения из .env — это фактически ключи от вашей установки: доступ к ним равносилен доступу к серверу. Файл должен читаться только владельцем (chmod 600 .env) и никогда не попадать в открытый git-репозиторий или бэкап без шифрования.

Когда .env готов, поднимаем стек:

docker compose up -d
docker compose ps

Все сервисы должны перейти в состояние running/healthy. Если какой-то контейнер перезапускается в цикле — смотрите логи:

docker compose logs -f api-gateway

Чаще всего причина — опечатка в .env или недоступная база данных на старте (первые секунды Postgres ещё инициализируется, это нормально).

Домен, реверс-прокси и SSL

Направьте A-запись notes.вашдомен.ru на IP сервера и дайте DNS минут 10–30 на распространение. Дальше два варианта.

Вариант 1 — встроенный Caddy. В части сборок docker-compose уже включает сервис Caddy, который сам выпускает и продлевает сертификат Let's Encrypt при условии, что 80 и 443 порты сервера смотрят наружу и не заняты ничем другим. Достаточно указать домен и e-mail в соответствующих переменных .env и открыть порты в файрволе.

Вариант 2 — свой реверс-прокси на хосте (актуально, если на этом же VPS уже крутятся другие сайты на nginx). Тогда встроенный Caddy в compose лучше отключить или перевести на нестандартный порт, а перед ним поставить свой nginx с TLS-терминацией:

server {
    listen 443 ssl http2;
    server_name notes.вашдомен.ru;

    ssl_certificate     /etc/letsencrypt/live/notes.вашдомен.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/notes.вашдомен.ru/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 90s;
    }
}

Сертификат в этом сценарии выпускает certbot стандартным способом (certbot --nginx -d notes.вашдомен.ru); о разнице между certbot и acme.sh есть отдельный разбор — certbot или acme.sh — что выбрать для сервера, а о выборе между Caddy и nginx в целом — Caddy или nginx — что выбрать для сервера.

Не забудьте про файрвол — на боевом сервере наружу должны смотреть только 80/443 (и SSH на нестандартном порту), остальные порты Docker-сервисов должны слушать 127.0.0.1, а не 0.0.0.0. Базовая настройка UFW описана в статье как установить и настроить файрвол UFW на VPS.

Подключение приложений, бэкапы и обновления

Когда https://notes.вашдомен.ru открывается по HTTPS без ошибок сертификата, переходите в официальное приложение Standard Notes (десктоп, мобильное или веб-клиент). В настройках аккаунта найдите пункт про смену сервера — обычно это «Advanced Options» → «Sign in to a different server» или аналогичный пункт в разделе Account — и укажите там адрес своего сервера. Регистрация аккаунта проходит уже на этом экране, отдельно от учётки standardnotes.com.

Бэкапы. Критичны две вещи: дамп базы данных и файл .env с секретами (без него старый дамп будет бесполезен — токены и ключи перевыпустятся заново). Дамп Postgres:

docker compose exec -T postgres pg_dump -U standardnotes standardnotes > /backup/sn_$(date +%F).sql

Дополнительно бэкапьте volume с загруженными файлами/вложениями (если используете файловый сервис) и сам .env — храните его копию отдельно и в зашифрованном виде, например через gpg -c. Кстати, поскольку тело заметок клиент шифрует ещё до отправки, содержимое дампа само по себе для посторонних бесполезно без ключа шифрования пользователя — но метаданные и структура всё равно чувствительны, так что относитесь к бэкапу как к секретному. Автоматизировать регулярный дамп удобно через cron — как это настроить, разобрано в статье как установить и настроить cron-задачи на VPS.

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

cd standardnotes-server
git pull
docker compose pull
docker compose up -d

После апдейта проверьте docker compose logs -f на предмет ошибок миграций и убедитесь, что клиент по-прежнему синхронизируется.

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