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

MAATRIX

Saleor — не очередной коробочный интернет-магазин с шаблонами и плагинами, а API-платформа: бэкенд отдаёт данные через GraphQL, а витрину вы либо берёте готовую (Saleor Storefront на Next.js), либо пишете свою на любом фреймворке. Это осознанный выбор для проектов, которым тесно в Bitrix или WooCommerce — маркетплейсы, мультирегиональные магазины, кастомный checkout. Плата за гибкость — Saleor требует больше от сервера и от вас: это не «залил файлы по FTP», а полноценный стек из Django-приложения, PostgreSQL, Redis и очередей на Celery. Разберём, как поднять его на VPS с нуля и не упереться в типичные грабли.

Что нужно понимать перед установкой

Saleor Core написан на Python (Django + GraphQL через graphene), хранит данные в PostgreSQL, использует Redis как брокер для Celery (фоновые задачи: отправка писем, обработка вебхуков, пересчёт цен) и опционально — для кэша. Сама админка (Saleor Dashboard) и витрина (Storefront) — отдельные приложения на React/Next.js, которые обращаются к Core по GraphQL API.

Это значит, что на одном VPS у вас фактически четыре-пять сервисов:

• saleor-api — сам бэкенд (Django + gunicorn/uvicorn);
• worker — Celery-воркер для фоновых задач;
• postgres — база данных;
• redis — брокер очередей и кэш;
• dashboard и/или storefront — фронтенды (можно вынести на отдельный сервер или CDN).

Официально проект тестируется на Docker, и это на порядок проще, чем ставить всё вручную через systemd-юниты — версии Python, Node.js и системных библиотек (Pillow, libpq, WeasyPrint для PDF-инвойсов) достаточно капризны к окружению. Дальше в статье — установка через Docker Compose.

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

Saleor не лёгкий проект. Минимум для теста — 2 vCPU / 4 ГБ RAM, но это конфигурация «посмотреть, что это такое», а не «принимать заказы». Для рабочего магазина с реальным трафиком закладывайте больше:

PostgreSQL и Celery-воркеры под нагрузкой упираются в RAM раньше, чем в CPU — если видите частые OOM-килы, сначала добавляйте память, а не ядра. Для медиафайлов (изображения товаров) закладывайте запас на диске или сразу планируйте S3-совместимое хранилище — это выносится в настройках через django-storages.

Для установки нужен VPS с публичным IP, root-доступом по SSH и чистой Ubuntu 24.04 или Debian 12 — дальше все команды даны под Ubuntu.

Подготовка сервера и установка Docker

Подключаемся по SSH и обновляем систему:

apt update && apt upgrade -y
apt install -y curl git ufw

Ставим Docker и Docker Compose plugin официальным скриптом:

curl -fsSL https://get.docker.com | sh
systemctl enable --now docker

Проверяем:

docker --version
docker compose version

Если хотите разобраться в установке Docker подробнее и понять, что делает скрипт под капотом, — это отдельная тема, здесь ограничимся минимумом для запуска Saleor.

Настраиваем базовый firewall — оставляем только SSH, HTTP и HTTPS:

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Создаём пользователя без root для повседневной работы и добавляем его в группу docker, чтобы не гонять всё через sudo:

adduser saleor
usermod -aG docker saleor

Разворачиваем Saleor через Docker Compose

Клонируем официальный репозиторий с готовым compose-файлом для платформы:

su - saleor
git clone https://github.com/saleor/saleor-platform.git
cd saleor-platform
cp .env.example .env

В saleor-platform уже собран весь стек: api, worker, db, redis, dashboard, storefront, mailpit (для локальной отладки почты) и nginx-заглушка. Для продакшена этот compose нужно доработать — вынести секреты, отключить debug-сервисы и настроить внешний reverse-proxy, но как отправная точка он рабочий.

Открываем .env и правим ключевые переменные:

nano .env

Обязательно смените:

SECRET_KEY=сгенерируйте-длинную-случайную-строку
ALLOWED_HOSTS=your-domain.com
API_URI=https://your-domain.com/graphql/

Сгенерировать SECRET_KEY можно так:

openssl rand -base64 48

Проверьте блок с базой данных — по умолчанию контейнер db поднимает PostgreSQL с логином/паролем из .env, для рабочего проекта задайте свой пароль, а не оставляйте дефолтный.

Запускаем стек:

docker compose up -d

Первый запуск качает образы и собирает зависимости — на VPS со средним каналом это займёт 5-15 минут. Следим за логами:

docker compose logs -f api

Дожидаемся строк о применённых миграциях и запущенном сервере. Затем создаём суперпользователя для входа в Dashboard:

docker compose exec api python3 manage.py createsuperuser

Настройка PostgreSQL и Redis для продакшена

Дефолтные настройки Postgres и Redis из compose-файла годятся для теста, но не для нагрузки. Несколько вещей, которые стоит поправить сразу.

Persistent volumes. Убедитесь, что в docker-compose.yml для сервисов db и redis заданы именованные volumes, а не анонимные — иначе при пересоздании контейнера (например, после docker compose down) данные потеряются:

services:
  db:
    volumes:
      - saleor-db-data:/var/lib/postgresql/data
  redis:
    volumes:
      - saleor-redis-data:/data

volumes:
  saleor-db-data:
  saleor-redis-data:

Бэкапы БД. Настройте регулярный дамп PostgreSQL до того, как в базе появятся реальные заказы:

docker compose exec db pg_dump -U saleor saleor > /home/saleor/backups/saleor-$(date +%F).sql

Вынесите это в cron. Если проект вырастет, имеет смысл вынести PostgreSQL на отдельный сервер — тогда пригодится статья про настройку PostgreSQL на VPS и про тюнинг PostgreSQL — параметры shared_buffers, work_mem и max_connections по умолчанию не рассчитаны на прод-нагрузку.

Redis. Проверьте, что maxmemory-policy не оставлен в значении по умолчанию noeviction — при заполнении памяти это приведёт к ошибкам записи вместо вытеснения старых ключей. Если Redis используется и как брокер Celery, и как кэш, разумно развести их по разным базам (REDIS_URL с индексом /0, /1) или вообще поднять два инстанса. Частые проблемы разбора и настройки Redis под нагрузкой — в статье про Redis на VPS.

Reverse-proxy, домен и SSL

Saleor API и Dashboard по умолчанию слушают на внутренних портах контейнеров — наружу их пускать напрямую не стоит. Ставим перед стеком reverse-proxy с автоматическим SSL. Проще всего это делает Caddy — двух строк в Caddyfile обычно хватает:

your-domain.com {
    reverse_proxy /graphql/* localhost:8000
    reverse_proxy /dashboard/* localhost:9000
    reverse_proxy /* localhost:3000
}

Если у вас уже есть опыт с Nginx и нужен более гибкий контроль (лимиты, кэш ответов), берите его — сравнение подходов есть в статье Caddy или Nginx — что выбрать, а пошаговая установка Caddy с автоматическим SSL — в отдельном разборе. Для более сложных сетапов с несколькими Docker-стеками на одном сервере удобен Traefik — он сам находит контейнеры по labels и не требует ручного редактирования конфига при каждом деплое, см. Traefik как reverse-proxy для Docker.

DNS-записи (A-запись домена на IP сервера) настройте заранее — SSL-сертификат Let's Encrypt не выпустится, пока домен не резолвится на ваш VPS.

Проверьте, что переменная API_URI в .env и настройки CORS/CSRF в Saleor указывают на реальный домен с https://, иначе Dashboard будет ругаться на смешанный контент или блокировать запросы.

Медиафайлы и внешнее хранилище

По умолчанию Saleor хранит загруженные изображения товаров локально в volume контейнера. Это работает, но плохо масштабируется: при переезде на другой сервер или при горизонтальном масштабировании воркеров файлы «размазываются» между инстансами. Для прод-конфигурации лучше сразу подключить S3-совместимое хранилище через переменные окружения:

AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
AWS_STORAGE_BUCKET_NAME=saleor-media
AWS_S3_ENDPOINT_URL=https://s3.your-provider.com

Saleor Core собран с поддержкой django-storages, так что достаточно правильно выставить переменные — код менять не нужно. Это же решает проблему бэкапа медиафайлов: дамп базы отдельно, файлы — отдельно, через версионирование бакета.

Обновление и обслуживание

Saleor активно развивается, и мажорные релизы иногда меняют схему БД и требуют ручных шагов из changelog — не обновляйтесь вслепую в проде. Общий порядок безопасного обновления:

1. Сделайте дамп БД и снапшот volumes.
2. Проверьте release notes новой версии на breaking changes.
3. На тестовом окружении (клон VPS или отдельный staging) прогоните обновление и миграции.
4. В проде: git pull, затем docker compose pull && docker compose up -d, следом docker compose exec api python3 manage.py migrate.

Логи Celery-воркера стоит проверять отдельно — если после обновления перестали приходить письма подтверждения заказов или не срабатывают вебхуки, часто дело именно в воркере, а не в API:

docker compose logs -f worker

Мониторьте использование диска — образы Docker и старые слои со временем накапливаются, docker system prune раз в месяц (с осторожностью, без -a на проде без проверки) держит диск в порядке.

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