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

MAATRIX

Если вы устали от того, что headless CMS хранит схему контента где-то в базе или в закрытой админке, а любое изменение поля превращается в ручной клик по интерфейсу без версионирования — Payload решает именно эту проблему. Это TypeScript-first CMS, где коллекции, поля и права доступа описываются кодом, живут в git и разворачиваются вместе с приложением. Ниже — рабочий процесс установки на чистый VPS: от Node.js и PostgreSQL до Nginx, SSL и автозапуска через PM2.

Что такое Payload и чем он отличается от Strapi или WordPress

Payload — это не «CMS с админкой поверх готовой базы», а фреймворк на Next.js, где сама админка генерируется из вашего кода. Вы описываете коллекцию Posts как TypeScript-объект с полями, хуками и правилами доступа — и получаете REST API, GraphQL API и админ-панель одновременно, без лишней настройки через UI.

Ключевые отличия от привычных решений:

• Схема — это код. Коллекции и поля хранятся в .ts-файлах, а не в записях базы данных. Откат к прошлой версии схемы — это git checkout, а не восстановление дампа.
• Node.js-стек целиком. Не PHP (как WordPress) и не отдельный Node-процесс с собственной админкой (как Strapi), а фреймворк, встроенный в Next.js App Router — можно рендерить фронтенд и админку в одном проекте.
• Локальный API. Из серверных компонентов Next.js можно дергать payload.find() напрямую, без HTTP-запроса к самому себе.
• Поддержка PostgreSQL, MongoDB и SQLite через официальные адаптеры — выбор базы не зашит намертво.

Если вы уже разворачивали Strapi на VPS, процесс покажется знакомым: тот же принцип headless-архитектуры, но здесь база кода первична, а не админ-панель.

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

Payload сам по себе не тяжёлый, но сборка Next.js в продакшен-режиме и живой процесс с админкой требуют определённого запаса. Ориентир для одного проекта средней нагрузки:

Сборка (next build) — самый прожорливый по памяти этап: на 1 ГБ RAM без свопа сборка часто падает с OOM. Если берёте минимальную конфигурацию, добавьте своп заранее:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Обновите систему и поставьте базовые пакеты:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl git build-essential

Если файрвол ещё не настроен, закройте всё лишнее до открытия сервисов наружу — процесс описан в статье про настройку UFW на VPS.

Установка Node.js и создание проекта

Payload 3.x требует Node.js 18.20.2+ или 20.9.0+ (актуальная LTS-ветка на конец августа 2026 — Node 22). Ставим через NodeSource:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node -v
npm -v

Создаём системного пользователя для приложения — не запускайте Node-процесс от root:

sudo adduser --disabled-password --gecos "" payloadapp
sudo su - payloadapp

Дальше всё выполняем от имени payloadapp. Создаём проект через официальный инсталлятор — он спросит шаблон (берём blank или website), пакетный менеджер и адаптер базы данных:

npx create-payload-app@latest my-payload-app
cd my-payload-app

На вопрос про базу данных выбирайте Postgres — для продакшена на VPS это надёжнее SQLite (который не любит параллельные записи) и проще в администрировании, чем MongoDB, если у вас уже есть опыт с реляционными базами.

PostgreSQL: база данных для Payload

Если PostgreSQL ещё не установлен, ставим его отдельно — подробный процесс с созданием роли и базы разобран в статье про установку PostgreSQL на VPS. Коротко для этого проекта:

sudo apt install -y postgresql postgresql-contrib
sudo -u postgres psql -c "CREATE USER payloaduser WITH PASSWORD 'замените_на_сложный_пароль';"
sudo -u postgres psql -c "CREATE DATABASE payloaddb OWNER payloaduser;"

В файле .env проекта (создаётся автоматически при инициализации, но проверьте значения) указываем строку подключения:

DATABASE_URI=postgresql://payloaduser:замените_на_сложный_пароль@localhost:5432/payloaddb
PAYLOAD_SECRET=сгенерируйте_случайную_строку_минимум_32_символа

PAYLOAD_SECRET генерируется командой:

openssl rand -base64 32

Держите PostgreSQL слушающим только localhost (listen_addresses = 'localhost' в postgresql.conf) — снаружи к базе доступа быть не должно, приложение общается с ней напрямую через сокет на том же сервере.

Сборка и первый запуск

Устанавливаем зависимости и собираем продакшен-версию:

npm install
npm run build

Сборка Next.js + генерация типов Payload может занять пару минут в зависимости от количества коллекций. Если процесс падает по памяти — это тот случай, когда своп из шага подготовки спасает.

Проверяем, что всё работает, в dev-режиме перед выкладкой в продакшен:

npm run dev

По умолчанию Payload поднимается на порту 3000, админка доступна по /admin. При первом заходе система предложит создать первого пользователя (root admin) — это обязательный шаг, без него в панель не попасть.

Для постоянной работы используем продакшен-команду:

npm run build
npm run start

Автозапуск через PM2 и systemd

Держать процесс в терминальной сессии — плохая идея: при разрыве SSH-соединения приложение упадёт. Ставим PM2 для управления процессом, автоперезапуска при сбое и запуска после ребута сервера:

sudo npm install -g pm2
cd ~/my-payload-app
pm2 start npm --name "payload-cms" -- run start
pm2 save
pm2 startup systemd -u payloadapp --hp /home/payloadapp

Последняя команда выведет строку с sudo env PATH=... — выполните её от root, чтобы PM2 зарегистрировался как systemd-сервис и поднимался автоматически при перезагрузке.

Полезные команды для повседневной работы:

pm2 logs payload-cms       # логи приложения в реальном времени
pm2 restart payload-cms    # перезапуск после деплоя
pm2 status                 # статус всех процессов
pm2 monit                  # мониторинг CPU/RAM процесса

Если предпочитаете чистый systemd без PM2 — это тоже рабочий вариант, но PM2 избавляет от написания unit-файла вручную и даёт встроенную ротацию логов через pm2-logrotate.

Nginx как обратный прокси и SSL

Приложение слушает 127.0.0.1:3000 и наружу выходить не должно — весь внешний трафик идёт через Nginx. Если Nginx ещё не настроен как reverse proxy на этом сервере, разберите общий процесс в статье про Nginx как обратный прокси на VPS. Для Payload конфиг выглядит так:

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

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        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;
    }

    client_max_body_size 20M;
}

client_max_body_size важно увеличить сразу — по умолчанию Nginx режет запросы на 1 МБ, а загрузка изображений и файлов через Payload Upload-коллекции легко это превышает.

Активируем сайт и выпускаем сертификат через Let's Encrypt (подробности — в статье про настройку Let's Encrypt SSL на VPS):

sudo ln -s /etc/nginx/sites-available/cms.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d cms.example.com

После выпуска сертификата certbot сам пропишет редирект с HTTP на HTTPS и настроит автопродление через systemd-таймер.

Хранилище файлов и первая коллекция

По умолчанию Payload сохраняет загруженные файлы на диск сервера в папку media внутри проекта. Для одного проекта на одном VPS этого достаточно, но помните: файлы не попадают в бэкап базы данных отдельно — их нужно бэкапить вместе с файловой системой. Если проект растёт и планируется несколько инстансов или CDN перед статикой, стоит подключить плагин @payloadcms/storage-s3 и вынести файлы в S3-совместимое хранилище (тот же MinIO, поднятый на соседнем сервере).

Пример минимальной коллекции — файл src/collections/Posts.ts:

import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  access: {
    read: () => true,
  },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'content', type: 'richText' },
    { name: 'publishedAt', type: 'date' },
  ],
}

После добавления коллекции в payload.config.ts и рестарта процесса (pm2 restart payload-cms) она сразу появляется в админке и в автоматически сгенерированном REST API по адресу /api/posts.

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