Свой бэкенд на VDS вместо Firebase и Supabase: развертывание PocketBase v0.40.4 в Docker Compose с Nginx Reverse Proxy, автопродлением SSL и бэкапами

Разработка бэкенда для современных пет-проектов, Telegram-ботов, мобильных приложений и клиентских MVP часто превращается в инженерный оверинжиниринг. Вместо быстрой проверки бизнес-гипотезы разработчик тратит несколько дней на развертывание PostgreSQL или MySQL, настройку Redis, выбор ORM, реализацию JWT-авторизации, валидацию схем и написание десятков однотипных CRUD-контроллеров. Если развернуть популярный self-hosted комбайн вроде Supabase, сервер мгновенно загружается десятком контейнеров (Postgres, GoTrue, PostgREST, Kong, Realtime), требуя от 3–4 ГБ оперативной памяти и регулярно падая по OOM Killer на доступных виртуальных серверах.

Альтернатива в виде облачного Google Firebase несет серьезные риски: жесткая привязка к проприетарной инфраструктуре, проблемы с оплатой зарубежными картами и риск внезапной блокировки аккаунта. Идеальным инженерным выходом стало использование PocketBase v0.40.4 — открытого автономного бэкенда (Backend-as-a-Service), который поставляется в виде одного скомпилированного бинарника на Go со встроенной СУБД SQLite и потребляет всего 15–30 МБ оперативной памяти.

1. Зачем разработчикам и сисадминам свой PocketBase: отказ от Firebase и Supabase

PocketBase объединяет все базовые потребности веб-сервиса в одном процессе: встроенную реляционную базу данных, готовую веб-панель администратора, автоматическую генерацию REST API, подписки в реальном времени (Realtime SSE), управление пользователями с OAuth2 и безопасное файловое хранилище.

2. 5 прикладных сценариев применения: боты, MVP, реестры и сбор заявок

Для системных администраторов, вебмастеров и фулстек-разработчиков PocketBase становится универсальным швейцарским ножом инфраструктуры:

• 1. Бэкенд и админка для Telegram-ботов: При создании чат-ботов на Python (aiogram) или Node.js заказчику всегда требуется панель для просмотра поступивших заказов, изменения статусов заявок и редактирования каталога. Бот обращается к PocketBase через обычные HTTP-запросы, а заказчик получает готовую адаптивную веб-панель без единой строчки фронтенд-кода.
• 2. Сверхбыстрый запуск MVP мобильных приложений и SPA: Разработчикам на React, Vue, Svelte или Flutter достаточно подключить официальный клиентский SDK (pocketbase-js или pocketbase-dart). Авторизация пользователей, фильтрация данных и загрузка аватарок работают прямо из коробки с клиентской стороны без необходимости писать серверный API.
• 3. Внутренний реестр IT-активов и инвентаризация: Вместо громоздких систем (GLPI, Jira) системный администратор за 15 минут создает таблицы для учета серверов VDS, лицензий, доменов, дат окончания SSL-сертификатов и оборудования с разграничением прав для сотрудников.
• 4. Централизованный сбор лидов с десятков сайтов: Все посадочные страницы и формы обратной связи отправляют заявки на единый защищенный эндпоинт PocketBase. Заявки надежно сохраняются в базе, не теряются при сбоях почтовых серверов и мгновенно дублируются в Telegram.
• 5. Чат техподдержки и дашборды в реальном времени: Благодаря встроенным Realtime-подпискам (Server-Sent Events) любые изменения в базе мгновенно отображаются в интерфейсе оператора без необходимости настраивать WebSockets и брокеры сообщений.

3. Архитектура PocketBase v0.40.4: Go, SQLite в режиме WAL и потребление 25 МБ RAM

Секрет высокой производительности и низкого потребления ресурсов PocketBase v0.40.4 кроется в его архитектуре. Сервер написан на компилируемом языке Go с использованием оптимизированного HTTP-маршрутизатора и встроенной СУБД SQLite.

В отличие от связок с внешними СУБД (PostgreSQL / MySQL), где каждый запрос проходит через сетевой TCP-сокет, сериализацию и парсинг протокола, PocketBase обращается к SQLite напрямую в памяти процесса. По умолчанию база данных функционирует в режиме WAL (Write-Ahead Logging). Важно различать два ключевых показателя производительности, подтвержденных официальными бенчмарками PocketBase:

• Одновременные Realtime-соединения (Concurrent Connections): На базовом одноядерном виртуальном сервере PocketBase способен удерживать более 10 000 одновременных SSE-подписок при минимальном расходе памяти (~100–150 МБ).
• Пропускная способность запросов (RPS / QPS): Для простых операций чтения из базы система обеспечивает 5 000–7 000 запросов в секунду (RPS) при среднем времени отклика менее 10 мс. Разумеется, реальная производительность зависит от сложности фильтров, индексов и скорости дисковой подсистемы.

Важно учитывать архитектурную особенность: несмотря на использование SQLite в режиме WAL, PocketBase применяет собственный механизм мьютекса на уровне приложения. Записи в базу выполняются последовательно (одна за другой), а операции чтения могут кратковременно ожидать завершения активной транзакции записи. Это означает, что для сценариев с интенсивной непрерывной записью (write-heavy) пропускная способность будет ниже, чем для преимущественного чтения (read-heavy). Если в вашем проекте планируются тысячи параллельных вставок в секунду, обязательно проводите предварительное нагрузочное тестирование.

4. Требования к серверу VDS и сайзинг дисковой подсистемы NVMe

Поскольку PocketBase чрезвычайно экономичен по оперативной памяти, ключевым фактором производительности становится скорость операций ввода-вывода (IOPS) дисковой подсистемы:

• Процессор (vCPU): 1 виртуальное ядро с частотой от 3.0 ГГц обеспечивает комфортную работу для большинства ботов и пет-проектов. Для высоконагруженных API рекомендуется 2 vCPU.
• Оперативная память (RAM): 1 ГБ RAM достаточно для работы PocketBase (25–50 МБ), Nginx (30 МБ), системных служб Ubuntu и дискового кэша.
• Диск (NVMe): Настоятельно рекомендуются быстрые NVMe-накопители. SQLite в режиме WAL активно сбрасывает страницы журнала на диск, поэтому скорость NVMe критична для времени отклика при записи.
• Запас дискового пространства: Для безопасного выполнения бэкапов требуется запас свободного места в размере как минимум 2x от текущего объема директории pb_data.
• Сетевой интерфейс: Статический публичный IPv4-адрес для выпуска SSL-сертификатов Let's Encrypt через Certbot.

5. Надежные VDS-провайдеры для размещения продакшен-бэкенда

Для стабильной работы базы данных SQLite критически важно выбирать хостинг-провайдеров с честной KVM-виртуализацией без оверселлинга дисковых ресурсов:

6. Манифест Docker Compose: монтирование pb_data, лимиты CPU/RAM и изоляция портов

Для развертывания PocketBase создадим изолированную директорию /opt/pocketbase на сервере Ubuntu 24.04 LTS. Все данные приложения (база SQLite, файлы хранилища и журнал транзакций) будут сохраняться в подкаталоге pb_data, что обеспечивает сохранность информации при любых обновлениях контейнера.

# Создание рабочей директории и каталога данных
sudo mkdir -p /opt/pocketbase/pb_data
cd /opt/pocketbase

Важный нюанс Docker-образов: Разработчик PocketBase принципиально не публикует собственный официальный образ в Docker Hub, оставляя право сборки за администратором. В официальной документации предлагается минимальный Dockerfile на базе легковесного Alpine Linux. Создадим файл /opt/pocketbase/Dockerfile:

FROM alpine:latest

ARG PB_VERSION=0.40.4

RUN apk add --no-cache unzip ca-certificates wget

ADD https://github.com/pocketbase/pocketbase/releases/download/v${PB_VERSION}/pocketbase_${PB_VERSION}_linux_amd64.zip /tmp/pb.zip
RUN unzip /tmp/pb.zip -d /pb/ && rm /tmp/pb.zip

EXPOSE 8090

CMD ["/pb/pocketbase", "serve", "--http=0.0.0.0:8090", "--dir=/pb/pb_data"]

Сгенерируем надежный 32-символьный шестнадцатеричный ключ шифрования для защиты чувствительных настроек PocketBase (паролей SMTP, токенов OAuth2 и ключей S3):

openssl rand -hex 16

Создадим манифест docker-compose.yml. Вы можете собирать образ локально из созданного Dockerfile либо использовать проверенный независимый образ сообщества (ghcr.io/muchobien/pocketbase:v0.40.4):

services:
  pocketbase:
    build: .
    # Альтернатива без локальной сборки:
    # image: ghcr.io/muchobien/pocketbase:v0.40.4
    container_name: pocketbase
    restart: unless-stopped
    mem_limit: 512m
    cpus: 1.0
    # Альтернатива для совместимости со Swarm:
    # deploy:
    #   resources:
    #     limits:
    #       cpus: '1.0'
    #       memory: 512M
    ports:
      - "127.0.0.1:8090:8090"
    volumes:
      - ./pb_data:/pb/pb_data
    environment:
      - TZ=Europe/Moscow
      - GOMEMLIMIT=450MiB
      - PB_ENCRYPTION_KEY=ВАШ_СГЕНЕРИРОВАННЫЙ_32_СИМВОЛЬНЫЙ_КЛЮЧ
    ulimits:
      nofile:
        soft: 65535
        hard: 65535
    healthcheck:
      test: ["CMD-SHELL", "wget --no-verbose --tries=1 --spider http://127.0.0.1:8090/api/health || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 3
      start_period: 5s

Соберем образ и запустим сервис в фоновом режиме:

sudo docker compose build
sudo docker compose up -d
sudo docker compose ps
sudo docker compose logs -f

7. Настройка Nginx Reverse Proxy: проксирование SSE, буферизация и автопродление SSL

Для публикации API на собственном домене (например, api.example.com) и организации безопасного шифрованного канала настроим Nginx в качестве обратного прокси-сервера.

Чтобы избежать ошибки «курицы и яйца» (когда Nginx отказывается стартовать из-за отсутствия еще не выпущенных файлов SSL), сначала создадим базовый виртуальный хост на 80 порту /etc/nginx/sites-available/pocketbase.conf:

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:8090;
        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;
    }
}

Активируем конфигурацию и выполним проверку синтаксиса:

sudo ln -s /etc/nginx/sites-available/pocketbase.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Выпустим доверенный SSL-сертификат Let's Encrypt с автоматической настройкой 301-редиректа на HTTPS:

sudo certbot --nginx -d api.example.com --redirect

После выпуска сертификата приведем файл /etc/nginx/sites-available/pocketbase.conf к финальному продакшен-виду, настроенному для долгоживущих соединений Server-Sent Events (SSE):

server {
    listen 80;
    server_name api.example.com;
    return 301 https://$host$request_uri;
}

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

    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    client_max_body_size 50M;

    location / {
        proxy_pass http://127.0.0.1:8090;
        proxy_http_version 1.1;

        # Настройки для Realtime Server-Sent Events (SSE)
        proxy_set_header Connection '';
        proxy_read_timeout 360s;
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding off;

        # Передача реального IP клиента
        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;
    }
}

Нюанс работы за Cloudflare: Если вы используете Cloudflare в режиме проксирования (оранжевое облако), бесплатный тариф принудительно разрывает любые неактивные HTTP/SSE-соединения через 100 секунд. Это приводит к периодическому разрыву подписок в браузере. Для решения проблемы настройте периодическую отправку keep-alive ping на клиенте либо переключите запись поддомена API в режим DNS-only (серое облако).

Применим обновленные параметры веб-сервера:

sudo nginx -t
sudo systemctl reload nginx

8. Харденинг безопасности: Rate Limiting, защита суперпользователей по IP и MFA

Создадим первого суперпользователя системы через встроенную консольную утилиту:

sudo docker compose exec pocketbase /pb/pocketbase superuser create admin@example.com MyStrongMasterPassword123

После входа в веб-интерфейс (https://api.example.com/_/) обязательно выполните следующие настройки безопасности:

• Настройка Trusted Proxy для встроенного Rate Limiter: В разделе Settings > Application настройте доверенные заголовки прокси (X-Real-IP, X-Forwarded-For) и укажите IP-адрес проксирующего хоста (127.0.0.1 или локальную подсеть Docker). Без этой настройки PocketBase будет видеть все входящие запросы как исходящие с одного IP 127.0.0.1, и встроенный Rate Limiter заблокирует весь входящий трафик при первом же всплеске активности.
• Белый список IP-адресов для суперпользователей: Начиная с версии v0.38.0, PocketBase поддерживает ограничение доступа к админке по доверенным IP или CIDR-подсетям (Settings > Application > Superuser IPs). Задать или сбросить белый список можно через CLI:

  # Ограничить доступ к админке только локалхостом и вашим статическим рабочим IP
  sudo docker compose exec pocketbase /pb/pocketbase superuser ips 127.0.0.1 203.0.113.45

• Встроенная двухфакторная аутентификация (MFA/OTP): Начиная с v0.38+, _superusers является полноценной auth-коллекцией. В настройках коллекции в веб-интерфейсе можно включить двухфакторную аутентификацию (MFA) с отправкой одноразового пароля (Email OTP) при каждой попытке входа. Настройте SMTP-сервер в Settings > Mail settings. В случае сбоя доставки почты вы всегда можете сгенерировать экстренный OTP-код прямо в терминале сервера:

  sudo docker compose exec pocketbase /pb/pocketbase superuser otp admin@example.com

9. Резервное копирование SQLite в режиме WAL без повреждения данных

Поскольку PocketBase использует SQLite в режиме Write-Ahead Logging (WAL), текущие транзакции временно записываются в файлы data.db-wal и data.db-shm. Если просто скопировать файл data.db обычной командой cp во время активной записи, полученная копия может оказаться поврежденной.

Для надежного создания резервных копий существует три проверенных инженерных подхода:

1. Встроенная система бэкапов PocketBase (Рекомендуется)

Начиная с версии v0.16+, PocketBase включает встроенный механизм автоматического создания бэкапов без остановки приложения. Система выполняет операцию PRAGMA wal_checkpoint(TRUNCATE), фиксирует все незавершенные транзакции и упаковывает базу данных вместе со всеми пользовательскими файлами из каталога pb_data/storage/ в единый ZIP-архив.

Настроить автоматическое расписание можно прямо в веб-интерфейсе: Settings > Backups. Укажите стандартное cron-выражение (например, 0 3 * * * для запуска каждую ночь в 03:00) и количество хранимых копий (например, 7). Бэкапы можно сохранять локально либо автоматически выгружать в отдельный S3-бакет.

Также создать бэкап можно через API с токеном суперпользователя:

curl -X POST 'https://api.example.com/api/backups'   -H 'Authorization: Bearer ВАШ_ТОКЕН_СУПЕРПОЛЬЗОВАТЕЛЯ'   -H 'Content-Type: application/json'   -d '{"name": "manual_backup.zip"}'

2. Создание снимка базы на лету через sqlite3 .backup

Если вам требуется снять моментальный дамп только самой базы данных без остановки контейнера и без упаковки тяжелых медиафайлов, используйте встроенную команду SQLite:

sudo sqlite3 /opt/pocketbase/pb_data/data.db ".backup '/backup/pocketbase/data_$(date +%F).db'"

3. Внешний скрипт бэкапа с паузой контейнера и алертом в Telegram

Для создания полного внешнего архива всей папки pb_data (база, логи, файлы) с гарантированной атомарностью используйте скрипт с кратковременной паузой контейнера:

#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR="/backup/pocketbase"
APP_DIR="/opt/pocketbase"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
ARCHIVE="$BACKUP_DIR/pb_backup_$DATE.tar.gz"

mkdir -p "$BACKUP_DIR"
cd "$APP_DIR"

# Гарантированное возобновление работы контейнера при любых сбоях
trap 'sudo docker compose unpause pocketbase >/dev/null 2>&1 || true' EXIT INT TERM

echo "[$(date)] Приостановка контейнера для консистентного снапшота..."
sudo docker compose pause pocketbase

echo "[$(date)] Создание архива данных pb_data..."
sudo tar -czf "$ARCHIVE" -C "$APP_DIR" pb_data

sudo docker compose unpause pocketbase
trap - EXIT INT TERM

echo "[$(date)] Резервная копия успешно создана: $ARCHIVE"

# Ротация: удаление копий старше 7 дней
find "$BACKUP_DIR" -type f -name "pb_backup_*.tar.gz" -mtime +7 -delete

# Уведомление в Telegram
TELEGRAM_BOT_TOKEN="ВАШ_ТОКЕН_БОТА"
TELEGRAM_CHAT_ID="ВАШ_CHAT_ID"

if [ -n "$TELEGRAM_BOT_TOKEN" ] && [ "$TELEGRAM_BOT_TOKEN" != "ВАШ_ТОКЕН_БОТА" ]; then
    MESSAGE="✅ Резервная копия PocketBase создана:
Файл: $(basename "$ARCHIVE")
Размер: $(du -h "$ARCHIVE" | cut -f1)
Сервер: $(hostname)"
    curl -s -X POST "https://api.telegram.org/bot$TELEGRAM_BOT_TOKEN/sendMessage"         -d "chat_id=$TELEGRAM_CHAT_ID"         --data-urlencode "text=$MESSAGE" > /dev/null || true
fi

10. Решение типичных проблем: Too many open files, ошибка 413 и блокировка по Rate Limit

В процессе промышленной эксплуатации PocketBase администраторы могут столкнуться со следующими характерными ситуациями:

• Ошибка «Too many open files» при росте Realtime-клиентов: Каждое активное Server-Sent Events соединение удерживает открытый сокет. Помимо настройки блока ulimits: nofile в Docker Compose, убедитесь, что лимиты не ограничены на уровне самой операционной системы хоста. Проверьте текущий лимит командой ulimit -n. Если PocketBase запускается в виде классической службы systemd, добавьте в секцию [Service] строку LimitNOFILE=65535.
• Процесс аварийно завершается во время нагрузочного теста (OOM): На серверах с 1 ГБ RAM сборщик мусора Go может не успевать освобождать память при резком наплыве параллельных запросов, из-за чего ядро Linux активирует OOM Killer. Убедитесь, что в переменных окружения контейнера задана директива GOMEMLIMIT=450MiB, и проверьте системный журнал командой dmesg | grep -i oom.
• Ошибка 413 Request Entity Too Large: Nginx по умолчанию запрещает передачу файлов крупнее 1 МБ. Убедитесь, что в блоке server задана директива client_max_body_size 50M; (или больше под задачи вашего хранилища), и выполните sudo nginx -s reload.
• Логи и мониторинг доступности: PocketBase сохраняет внутренние системные логи в файле pb_data/logs.db. В разделе Settings > Logs настройте срок хранения логов (параметр maxDays: 7). Для мониторинга доступности сервиса внешними чекерами используйте встроенный эндпоинт /api/health, который возвращает статус 200 OK при нормальной работе приложения и доступности базы SQLite.