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

MAATRIX

Google Docs и Notion удобны, но каждый символ, который вы туда печатаете, физически лежит на чужих серверах и в теории читаем провайдером сервиса. CryptPad решает это иначе: документы, таблицы, канбан-доски и заметки шифруются в браузере ещё до отправки на сервер — сам сервер видит только зашифрованный набор байт и никогда не имеет ключа. Ниже — рабочая установка CryptPad на VPS через Docker с HTTPS и разбором нюансов, которые не видны в официальной документации с первого взгляда.

Как устроено шифрование в CryptPad и что это значит на практике

CryptPad — это не «облако с шифрованием на диске», как у многих self-hosted альтернатив Google Docs. Модель здесь принципиально другая: ключ шифрования генерируется и живёт только в браузере пользователя (он зашит в URL-фрагменте после #, который браузер физически не отправляет на сервер по протоколу HTTP). Сервер хранит и синхронизирует уже зашифрованные блоки данных, не имея возможности их расшифровать — совместное редактирование, история версий, комментарии идут через WebSocket, но контент шифруется до того, как покинет вкладку браузера.

Отсюда два практических следствия. Во-первых, если пользователь потеряет ссылку на документ (а вместе с ней — ключ в URL-фрагменте), восстановить содержимое администратор сервера не сможет физически, а не потому что «не предусмотрено». Это надо явно проговорить с командой перед началом работы. Во-вторых, поисковый индекс и серверное сканирование вложений в таком виде не работают — сервер не знает, что внутри.

Требования к серверу и подготовка

CryptPad заметно легче, чем Nextcloud или OnlyOffice — он не тянет за собой PostgreSQL или Redis для базовой работы, хранилище по умолчанию — файловая система. Официально заявленный минимум — 1 vCPU и 1 ГБ RAM для персонального использования, но на практике для команды от 5-10 человек с активным совместным редактированием стоит закладывать от 2 vCPU и 2-4 ГБ RAM: сборка мусора (garbage collection) неиспользуемых блоков и генерация превью документов периодически создают всплески нагрузки.

Понадобится:

• VPS с Ubuntu 24.04 или Debian 12;
• установленный Docker и Docker Compose (если ещё не настроен — см. пошаговую установку Docker с нуля);
• доменное имя, направленное на IP сервера (без валидного домена и HTTPS часть криптографических API браузера, на которые опирается CryptPad, попросту не активируется);
• открытые порты 80 и 443, а также один внутренний порт для WebSocket, если разносите API и веб-часть.

Обновите систему и проверьте свободное место — при активном использовании диск заполняется быстрее, чем кажется, из-за истории версий документов:

sudo apt update && sudo apt upgrade -y
df -h
free -h

Если Docker ещё не установлен:

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

Установка через Docker Compose

Официальный образ поддерживается сообществом (cryptpad/cryptpad), но собирается из исходников проекта — сборка не такая быстрая, как для типового Docker-образа, первый запуск может занять несколько минут.

Создайте рабочую директорию:

mkdir -p ~/cryptpad/{data,customize,config}
cd ~/cryptpad

Базовый docker-compose.yml:

services:
  cryptpad:
    image: cryptpad/cryptpad:latest
    container_name: cryptpad
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
      - "127.0.0.1:3003:3003"
    environment:
      - CPAD_MAIN_DOMAIN=pad.example.com
      - CPAD_SANDBOX_DOMAIN=pad-sandbox.example.com
    volumes:
      - ./data:/cryptpad/data
      - ./customize:/cryptpad/customize
      - ./config:/cryptpad/config

Порт 3000 — основной интерфейс, 3003 — API/WebSocket-сервер. Оба сознательно проброшены только на 127.0.0.1 — снаружи всё пойдёт через Nginx.

Важный момент, который часто упускают: CryptPad по соображениям безопасности браузера ожидает два разных домена — основной (CPAD_MAIN_DOMAIN) и «песочницу» (CPAD_SANDBOX_DOMAIN) для iframe, в котором рендерится непосредственно содержимое документов. Это часть модели изоляции — content security policy не даёт скриптам основного домена дотянуться до данных внутри iframe даже теоретически. Проще всего завести поддомен: pad.example.com и pad-sandbox.example.com, оба указывающие на один и тот же VPS.

Запуск:

docker compose up -d
docker compose logs -f cryptpad

Настройка config.js

Полный контроль над CryptPad идёт через файл config/config.js — он создаётся из шаблона при первом старте, но обычно требует правки под конкретный сервер. Скопируйте пример и отредактируйте:

docker exec cryptpad cat /cryptpad/config/config.example.js > config/config.js

Ключевые параметры, которые стоит проверить:

httpUnsafeOrigin: "https://pad.example.com",
httpSafeOrigin: "https://pad-sandbox.example.com",

httpAddress: "0.0.0.0",
httpPort: 3000,

adminEmail: "admin@example.com",

// список администраторов панели /admin/ — задаётся публичным ключом,
// а не логином/паролем (см. раздел ниже)
adminKeys: [],

После правки config.js перезапустите контейнер:

docker compose restart cryptpad

Nginx как reverse proxy и SSL

Наружу CryptPad отдаём через Nginx с Let's Encrypt — если Nginx ещё не настроен, см. установку Nginx как reverse proxy на VPS. Понадобятся два server-блока — для основного домена и для sandbox-домена.

server {
    listen 80;
    server_name pad.example.com pad-sandbox.example.com;
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }
    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl http2;
    server_name pad.example.com;

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

    client_max_body_size 150m;

    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_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    location /cryptpad_websocket {
        proxy_pass http://127.0.0.1:3003;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
    }
}

Второй домен (pad-sandbox.example.com) можно обслуживать тем же server-блоком, просто добавив его вторым именем в server_name — оба указывают на один и тот же контент на порту 3000, различие в поведении задаёт сам CryptPad по заголовку Host, а не Nginx. Сертификат выпускаем сразу на оба домена через certbot (подробности — в статье про Let's Encrypt SSL на VPS):

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d pad.example.com -d pad-sandbox.example.com

Без раздельной проксировки /cryptpad_websocket на порт 3003 совместное редактирование в реальном времени работать не будет — интерфейс откроется, но синхронизация между вкладками зависнет. Это самая частая причина, по которой «CryptPad вроде запустился, но не сохраняет».

Права администратора, квоты и приватность

В отличие от большинства self-hosted сервисов, у CryptPad нет логина/пароля администратора в привычном виде — доступ к панели /admin/ даётся по публичному ключу учётной записи CryptPad, которую нужно сначала создать как обычный пользователь через веб-интерфейс.

Порядок действий:

1. Откройте https://pad.example.com, зарегистрируйте обычный аккаунт.
2. Зайдите в Settings → Account и скопируйте Public Signing Key.
3. Вставьте этот ключ в массив adminKeys в config.js:

adminKeys: [
    "[cryptpad-user1@pad.example.com/YOUR-PUBLIC-KEY-HERE]"
],

1. Перезапустите контейнер — docker compose restart cryptpad.
2. Теперь этому аккаунту доступна панель /admin/ со статистикой использования, управлением квотами и модерацией.

Лимиты на объём хранимых данных задаются там же, в config.js, блоком defaultStorageLimit (в байтах) — по умолчанию CryptPad довольно щедро выделяет место, и на многопользовательском сервере это стоит сознательно ограничить, иначе один активный пользователь способен занять весь диск загрузками файлов:

defaultStorageLimit: 1 * 1024 * 1024 * 1024, // 1 ГБ на пользователя

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

restrictRegistration: true,

После включения новые аккаунты сможет создавать только администратор через панель /admin/ (раздел invite-ссылок) — это разумный компромисс между полным открытым доступом и ручной выдачей паролей.

Дополнительно стоит закрыть сам сервер файрволом до состояния «наружу видны только 80 и 443»:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

Отдельно стоит понимать: end-to-end шифрование защищает содержимое документов от сервера и от перехвата на сети, но не заменяет контроль доступа. Кто угодно с сохранённой ссылкой на документ (которая содержит ключ) может его открыть — делитесь ссылками так же осторожно, как паролями, и используйте встроенные в CryptPad настройки прав («только просмотр» / «редактирование») для совместных документов.

Резервное копирование и обслуживание

Все данные CryptPad — документы, блобы файлов, метаданные аккаунтов — лежат в примонтированной директории ~/cryptpad/data. Бэкапить нужно именно её целиком вместе с config:

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

Короткая остановка контейнера на время архивации снимает риск бэкапа файла в момент записи — при активном использовании сервиса лучше запускать скрипт по cron ночью.

Отдельная задача, специфичная для CryptPad, — сборка мусора: удалённые пользователем документы физически остаются на диске до плановой очистки, которая встроена в контейнер и идёт по расписанию. На серверах с ограниченным диском стоит время от времени проверять реальное занятое место (du -sh ~/cryptpad/data).

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

docker compose pull
docker compose up -d
docker compose logs -f cryptpad

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