Strapi или Directus: что выгоднее и когда

MAATRIX

Как только фронтенд отделяется от бэкенда — на React, Next.js, мобильном приложении или сразу трёх витринах — встаёт вопрос, откуда брать контент. Ставить полноценную CMS с собственным рендерингом ради JSON-ответа избыточно, писать API с нуля долго. Здесь и появляются headless CMS, а среди них два имени звучат чаще всего — Strapi и Directus. Оба открыты, оба ставятся на обычный VPS, оба отдают REST и GraphQL, но подход к данным у них принципиально разный, и от этого зависит, какой впишется в вашу задачу без переделок.

Что это вообще такое

Strapi — классическая headless CMS в привычном смысле: вы описываете типы контента через Content-Type Builder (статьи, товары, страницы), Strapi сам создаёт под них таблицы в базе и админку для редактирования. База данных — внутренняя, Strapi ей владеет и управляет через свои миграции. Это инструмент «контент как в WordPress, но без фронтенда» — понятный редакторам, с ролями, черновиками и версионированием полей.

Directus работает иначе: это не CMS в классическом смысле, а слой API и админки поверх уже существующей SQL-базы. Directus не создаёт свою схему — он подключается к вашим таблицам (существующим или новым), интроспектирует их и на лету строит REST/GraphQL API и админ-панель. Если у вас уже есть база от старого проекта, ERP-выгрузка или таблицы, спроектированные вручную под конкретную логику, Directus наденет на них API и интерфейс без миграции данных куда-либо.

Разница примерно как между конструктором, который сам решает, из чего собрать дом, и универсальной системой доступа, которая встраивается в дом, построенный до неё. Обе задачи законны, но это разные задачи.

Архитектура и подход к данным

В Strapi база — деталь реализации. Content-Type Builder генерирует модели, Strapi ведёт миграции сам, а формат хранения (какие колонки, какие связующие таблицы для many-to-many) — внутренняя логика фреймворка, трогать её руками не стоит. Из коробки поддерживаются PostgreSQL, MySQL и SQLite — для продакшена практически всегда берут PostgreSQL, SQLite годится только для разработки и совсем небольших проектов без параллельной записи.

npx create-strapi-app@latest my-project
# при установке выбираете БД: postgres рекомендуется для прод-окружения
cd my-project
npm run develop

Подробный разбор установки и первого запуска — в статье как установить и настроить Strapi на VPS.

В Directus всё наоборот: схема — это ваши таблицы, и Directus лишь хранит метаданные (лейблы полей, интерфейсы отображения, права доступа) в служебных directus_* таблицах рядом с вашими. Можно подключить существующую базу с сотней таблиц, и Directus тут же построит по ней API — ничего не мигрируя и не создавая заново. Поддержка баз шире: PostgreSQL, MySQL, SQLite, MS SQL Server, OracleDB, CockroachDB.

npx create-directus-project my-project
cd my-project
npx directus start

Пошаговая установка на чистый VPS — в статье как установить и настроить Directus на VPS.

Практическое следствие: если проект стартует с нуля и вы хотите, чтобы CMS сама предложила разумную структуру хранения — берите Strapi. Если база уже есть и трогать её схему рискованно (продакшен, легаси, чужой код завязан на конкретные имена таблиц) — Directus зайдёт без миграций.

Установка и запуск на VPS

Оба варианта — приложения на Node.js, оба нормально живут за reverse-proxy (nginx или Caddy) с процесс-менеджером вроде PM2 или systemd-юнитом, оба разворачиваются и через Docker Compose. Минимальный стек Strapi в проде:

services:
  strapi:
    image: strapi/strapi:5
    environment:
      DATABASE_CLIENT: postgres
      DATABASE_HOST: postgres
      DATABASE_NAME: strapi
      DATABASE_USERNAME: strapi
      DATABASE_PASSWORD: ${DB_PASSWORD}
      APP_KEYS: ${APP_KEYS}
      JWT_SECRET: ${JWT_SECRET}
    ports:
      - "1337:1337"
    depends_on:
      - postgres

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: strapi
      POSTGRES_USER: strapi
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - strapi-db:/var/lib/postgresql/data

volumes:
  strapi-db:

Для Directus стек похожий, но переменных окружения больше — нужен KEY/SECRET для подписи токенов и явное указание админского логина при первом запуске:

services:
  directus:
    image: directus/directus:11
    environment:
      KEY: ${DIRECTUS_KEY}
      SECRET: ${DIRECTUS_SECRET}
      DB_CLIENT: pg
      DB_HOST: postgres
      DB_DATABASE: directus
      DB_USER: directus
      DB_PASSWORD: ${DB_PASSWORD}
      ADMIN_EMAIL: admin@example.com
      ADMIN_PASSWORD: ${ADMIN_PASSWORD}
    ports:
      - "8055:8055"
    depends_on:
      - postgres

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: directus
      POSTGRES_USER: directus
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - directus-db:/var/lib/postgresql/data

volumes:
  directus-db:

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

API, GraphQL и автоматизация

Strapi отдаёт REST API из коробки сразу после создания типа контента — /api/articles, /api/products и так далее, с фильтрами, пагинацией и populate для связей через query-параметры. GraphQL — официальный плагин, ставится отдельно (@strapi/plugin-graphql) и добавляет соответствующую схему. Автоматизации на события (создали запись — отправили вебхук) реализуются через Webhooks в настройках или через Lifecycle Hooks в коде — писать логику руками придётся в большинстве нетривиальных сценариев.

Directus отдаёт REST и GraphQL одновременно и без дополнительной установки — оба интерфейса включены всегда. Плюс к этому в Directus встроены Flows — визуальный конструктор автоматизаций прямо в админке: триггер (создание записи, вебхук, расписание по cron) соединяется с цепочкой операций (HTTP-запрос, отправка письма, трансформация данных, условие) без единой строчки кода. Для сценариев «уведомить в Telegram при новом лиде» или «синхронизировать заказ с внешней системой» это закрывает задачу без n8n или Make рядом.

Если автоматизация — заметная часть проекта, Directus экономит отдельный сервис оркестрации. Если нужен только чистый CRUD-бэкенд для контента, а логику вы и так пишете в приложении, разница между «GraphQL ставится плагином» и «GraphQL уже включён» не критична.

Лицензия и что это значит на практике

Здесь стоит быть честным, потому что разница не техническая, а юридическая. Ядро Strapi распространяется по лицензии MIT — можно использовать, форкать, встраивать в свой продукт и даже предлагать как услугу хостинга без ограничений; платные функции (расширенный аудит, SSO определённых типов) вынесены в Enterprise-тариф, но сам фреймворк свободен полностью.

Directus использует Business Source License 1.1 (BSL) — код открыт, читать, менять и самостоятельно разворачивать для своих задач можно свободно, но лицензия ограничивает конкретный сценарий: предлагать Directus как управляемый хостинг третьим лицам в виде конкурирующего сервиса без отдельного соглашения с правообладателем. Для подавляющего большинства случаев — свой проект, свой VPS, свой продукт поверх Directus — это ограничение не задевает вообще. Оно становится важным только если вы сами планируете продавать «Directus как услугу» массово, конкурируя с официальным Directus Cloud.

Практический вывод: если для проекта принципиальна максимально свободная лицензия без нюансов (например, требование юридического отдела) — Strapi проще защитить перед комплаенсом. Если ограничение BSL не пересекается с вашей бизнес-моделью — оно не имеет значения.

Ресурсы на сервере и когда что выбрать

Цифры ниже — ориентир, а не гарантированный бенчмарк: конкретное потребление зависит от числа типов контента, объёма данных, числа одновременных запросов и настроек кэша.

Подробные цифры по памяти и как их замерить на своём сервере — в статьях сколько RAM нужно для Strapi и сколько RAM нужно для Directus. На бюджетном VPS 1–2 ГБ оба варианта запускаются и работают, но с ростом числа коллекций и трафика comfortable-порог для обоих — от 2 ГБ и выше вместе с базой на том же сервере; на 1 ГБ лучше вынести PostgreSQL отдельно или держать проект совсем небольшим.

Берите Strapi, если: проект стартует с нуля, нужен привычный опыт «CMS для контента» с понятной админкой для редакторов, а лицензионная чистота MIT важна для бизнеса.

Берите Directus, если: у вас уже есть база данных (своя или унаследованная), схему которой лучше не трогать; нужны GraphQL и REST сразу без установки плагинов; полезны встроенные Flows вместо отдельного n8n; вы работаете с базами вроде MS SQL или Oracle, которые Strapi не поддерживает.

Если задача шире, чем контент-модель, и ближе к «строгая типизация на TypeScript плюс полный контроль над кодом миграций», стоит присмотреться и к Payload CMS — третьему заметному игроку в этой нише с другим набором компромиссов.

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