Индекс журналаDockup / заметка с места
Note / self-host-directus

Как разместить Directus на собственном сервере в 2026 году: база данных, загрузки и публичный URL

Разместите Directus на собственном сервере с корректными портами, постоянным хранилищем, HTTPS, секретами, резервными копиями и проверками обновлений. Узнайте, как исправить ситуацию, когда выбран неправильный database client.

Рассматривайте Directus как небольшую систему, а не как Docker image. Пользовательская цель Directus ясна: REST и GraphQL API, а также административный интерфейс для работы с данными. Развёртывание можно считать успешным только после того, как вы сможете создать администратора, коллекцию и роль, записать данные через REST, выполнить запрос через GraphQL и загрузить файл.

Это различие помогает обнаружить типичную проблему, с которой операторы сталкиваются после локального тестирования: выбран неправильный database client или хранилище загрузок недоступно для записи. Кроме того, план резервного копирования и обновления становится достаточно конкретным для практической проверки.

Убедитесь, что Directus переживает замену

Container image можно скачать заново, а базу данных, загрузки, extensions, flows и snapshots схемы — нельзя. Подключите /directus/database до создания администратора, запишите безопасные тестовые данные и замените container, чтобы убедиться, что этот путь действительно сохраняется. Проверяйте фактическое mount-подключение, а не доверяйте имени Compose-файла, и убедитесь, что runtime user может записывать данные туда, где этого ожидает Directus.

Выберите срок хранения и расположение вне хоста, затем отрепетируйте восстановление, не затрагивая production. Проверка считается успешной только тогда, когда возвращаются схема, роли, flows, items, extensions и загрузки, а проверки REST и GraphQL завершаются успешно. Для состояния, хранящегося в базе данных, сочетайте snapshots хранилища с экспортами, согласованными с приложением, как описано в статье восстановление на определённый момент времени и snapshots.

Production-архитектура Directus

Обозначьте вокруг Directus три границы: входящий трафик к порту 8055, постоянное состояние и вспомогательные требования. Container можно заменить, но для двух других компонентов нужны явно назначенные ответственные. Сетевой контракт Directus — Postgres, а для масштабируемых развёртываний опционально Redis и object storage. Размещайте private endpoints во внутреннем DNS, разрешайте только необходимые исходящие подключения и выдайте Directus service credential с ограниченными правами.

Схема считается полной, когда чистый client может создать администратора, коллекцию и роль, записать данные через REST, выполнить запрос через GraphQL и загрузить файл. Собирайте данные о времени выполнения и ресурсах для database connection pool, concurrency API-запросов, Flow workers, генерации thumbnails и upload storage. Если транзакция завершается ошибкой, первая граница, которая ведёт себя не так, как описано в документации, подсказывает, нужно ли проверять routing, локальную capacity или вспомогательный service.

Проверьте развёртывание Directus от начала до конца

Создайте небольшой disposable fixture Directus и сохраняйте его для каждого релиза. Fixture должен проверять реальный workflow: создать администратора, коллекцию и роль, записать данные через REST, выполнить запрос через GraphQL и загрузить файл. Зафиксируйте image digest, внешний hostname, адрес dependency и ожидаемый результат, чтобы следующий оператор мог повторить тест без интерпретации этого руководства.

Запустите fixture три раза. Сначала используйте свежее развёртывание. Затем замените container, не затрагивая durable state. В третий раз восстановите backup в пустом окружении. Третий запуск считается успешным только тогда, когда возвращаются схема, роли, flows, items, extensions и загрузки, а проверки REST и GraphQL завершаются успешно. Во время каждого запуска собирайте latency и сведения об использовании ресурсов для database connection pool, concurrency API-запросов, Flow workers, генерации thumbnails и upload storage. Это станет базой для alerts, а не произвольным процентом загрузки CPU.

Наконец, намеренно проверьте негативный сценарий: временно запретите test identity доступ к Postgres, а также к Redis и object storage, если они используются в масштабируемом развёртывании. Убедитесь, что Directus явно сообщает об ошибке и не повреждает состояние, восстановите корректные условия и повторите успешную транзакцию. Release record с этими четырьмя результатами — более убедительное доказательство, чем screenshots dashboard или однократный ответ curl.

Запустите Directus с наблюдаемыми настройками по умолчанию

Запускайте Directus так, чтобы маршрут оставался private до завершения создания администратора.

docker run -d \
  --name directus \
  --restart unless-stopped \
  -p 127.0.0.1:8055:8055 \
  -v directus-data:/directus/database \
  -v directus-uploads:/directus/uploads \
  -v directus-extensions:/directus/extensions \
  -e SECRET=replace-with-a-long-random-value \
  -e KEY=replace-with-a-second-long-random-value \
  -e ADMIN_EMAIL=admin@example.com \
  -e ADMIN_PASSWORD=replace-with-a-strong-bootstrap-password \
  -e DB_CLIENT=sqlite3 \
  -e DB_FILENAME=/directus/database/data.db \
  -e PUBLIC_URL=https://app.example.com \
  directus/directus:latest

Если процесс зацикливается, сравните ожидаемого user image с владельцем каждого подключённого path. Если container продолжает работать, проверьте порт 8055 локально и сразу переходите к workflow: создайте администратора, коллекцию и роль, запишите данные через REST, выполните запрос через GraphQL и загрузите файл. Фиксируйте version image только после успешной end-to-end проверки и храните точную конфигурацию рядом с service.

Учётные данные, роли и открытые поверхности

Закройте bootstrap window сразу после создания первого доверенного администратора. Конкретная ловушка Directus — продолжать использовать bootstrap admin password после первого входа или бездумно менять SECRET. Более безопасный подход — заменить bootstrap credentials, использовать least-privilege roles и сохранять SECRET неизменным, поскольку он защищает application sessions и tokens.

Создайте SECRET один раз, не храните его в Git и сохраните вместе с recovery manifest, поскольку его изменение может сделать недействительным зашифрованное или подписанное application state. Credentials для dependencies должны передаваться по private networking, а роли внутри Directus должны разрешать только минимально необходимые действия. Не включайте чувствительные request bodies и provider responses в обычные logs.

Сделайте public origin однозначным

Не используйте для Directus временные и постоянные public origins одновременно. Вместо этого задайте PUBLIC_URL как canonical HTTPS address, направьте выбранное DNS-имя на platform route и проксируйте запросы только к порту 8055.

Проверьте этот сценарий извне хоста: создайте администратора, коллекцию и роль, запишите данные через REST, выполните запрос через GraphQL и загрузите файл. Если ingress не работает, в руководстве по устранению ошибки 502 описаны проблемы с портом и listener. Если Directus получает запрос, но выбран неправильный database client или upload storage недоступно для записи, теперь очевидно, что искать нужно за пределами proxy.

Сценарии отказа для Directus

Для Directus отслеживайте транзакцию, а не только процесс: создание администратора, коллекции и роли, запись через REST, запрос через GraphQL и загрузку файла. Объедините latency и error rate с показателями database connection pool, concurrency API-запросов, Flow workers, генерации thumbnails и upload storage, чтобы alert указывал на ограниченный компонент.

Репетиция обновления должна учитывать, что schema migrations Directus, extensions и поддержка database vendor необходимо проверять как единое целое. Восстановите данные, выполните миграцию и запустите транзакцию до замены production-инстанса. Если выбран неправильный database client или upload storage недоступно для записи, не удаляйте данные ради успешного запуска. Сначала последовательно сравните version, variables, mounts и доступность dependencies.

Что Dockup следует автоматизировать для Directus

Platform layer Directus состоит из порта 8055, ingress, TLS, runtime configuration, storage и доступности dependencies. Dockup может воспроизводить эти компоненты для собственной инфраструктуры или сервера, подключённого клиентом.

Затем оператор завершает product layer: задаёт PUBLIC_URL как canonical HTTPS address; применяет это правило доступа — заменяет bootstrap credentials, использует least-privilege roles и сохраняет SECRET неизменным, поскольку он защищает application sessions и tokens; и запускает сценарий «создать администратора, коллекцию и роль, записать данные через REST, выполнить запрос через GraphQL и загрузить файл». Запись результатов этого теста рядом с deployment помогает не путать automated provisioning с готовностью приложения.

Часто задаваемые вопросы

Что нужно Directus для production-развёртывания?

Направьте container Directus через порт 8055 к одному HTTPS origin. Сетевое требование для supporting services — Postgres, а для масштабируемых развёртываний опционально Redis и object storage. Не считайте Directus готовым, пока не сможете создать администратора, коллекцию и роль, записать данные через REST, выполнить запрос через GraphQL и загрузить файл.

Какие данные Directus нужно включать в backup?

Сохраняйте /directus/database и включайте database, uploads, extensions, flows и schema snapshots в один recovery manifest. Восстановление Directus считается успешным только тогда, когда возвращаются схема, роли, flows, items, extensions и загрузки, а проверки REST и GraphQL завершаются успешно.

Нужен ли Directus HTTPS за reverse proxy?

Используйте HTTPS для public origin Directus, а порт 8055 оставьте во внутреннем route. Корректно задайте настройку Directus: установите PUBLIC_URL как canonical HTTPS address. Для Directus HTTPS защищает credentials и пользовательский контент при передаче и обеспечивает согласованное поведение client, зависящее от origin.

Как тестировать обновление Directus?

Восстановите текущее состояние Directus в изолированном deployment, примените candidate version и повторите acceptance transaction. Уделите этому особое внимание, поскольку schema migrations Directus, extensions и поддержка database vendor необходимо проверять как единое целое. Сохраняйте предыдущий image Directus, пока не будут понятны границы data migration и rollback.