Установка Dify на VPS через Docker Compose

Что такое Dify и что именно вы собираетесь запускать

Dify — это платформа для самостоятельного развертывания, предназначенная для создания приложений на базе больших языковых моделей. Вы получаете веб-интерфейс для проектирования чат-ботов, агентов и конвейеров поиска (retrieval pipelines), API для вызова этих приложений из вашего кода, а также единое пространство для управления промптами, наборами данных и ключами моделей. Это инструмент, который небольшие команды разворачивают для того, чтобы все работали на общей закрытой базе, а не разбрасывали API-ключи по разным скриптам. Если термины «агент», «вызов инструмента» (tool call) и «конвейер поиска» вам пока не до конца понятны, изучение этих концепций с нуля поможет сделать так, чтобы экраны конструктора Dify воспринимались как привычные элементы управления, а не как стена из немаркированных переключателей.

Самостоятельный запуск означает работу с множеством взаимосвязанных компонентов. По состоянию на октябрь 2026 года, стандартный документированный стек Dify запускает 15 постоянно работающих контейнеров, а также одну разовую задачу, которая устанавливает права доступа к файлам и завершается. Семь из них — это собственные сервисы Dify: API-сервер, websocket-сервер, фоновый воркер, планировщик, веб-интерфейс, плагин-демон и агентский бэкенд. Остальные восемь — это зависимости: база данных Postgres, кэш Redis, векторная база данных Weaviate, фронтенд-прокси nginx, две «песочницы» для кода и два SSRF-прокси. Docker Compose связывает их воедино, но это полноценный стек, и минимальные системные требования Dify составляют 4 GiB оперативной памяти и два ядра CPU. Если на этом же VPS будут работать другие сервисы, рассчитывайте ресурсы исходя из реальных показателей, а не заявленных, поскольку реальный порог потребления памяти у PhotoPrism и Immich значительно выше их опубликованных минимумов, и фотосервер, делящий с Dify один хост, в первую очередь лишит ресурсов базу данных и векторное хранилище Dify. Конкуренция за CPU проявляется так же: библиотека Jellyfin, стилизованная под видеосалон 90-х, почти не потребляет ресурсов при просмотре обложек, но как только кто-то запускает транскодирование, воркеры Dify встают в очередь. Утешением служит то, что количество контейнеров Dify остается неизменным независимо от того, сколько приложений вы на нем создадите. Это более предсказуемая модель потребления ресурсов, чем в OpenBot, где каждый ИИ-сотрудник получает собственный контейнер и собственный браузер, и каждый новый ИИ-сотрудник повышает минимальный порог потребления памяти.

Поскольку Dify хранит ваши API-ключи к моделям и, зачастую, конфиденциальные документы, загруженные для поиска, относитесь к серверу, на котором она работает, как к критически важному с первой же минуты. В этом руководстве описывается установка, а затем — настройка безопасности, которую следует применять к любому сервису, хранящему секретные данные.

Предварительные требования

Вам потребуется VPS под управлением Ubuntu 24.04 с объемом оперативной памяти не менее 4 GiB и двумя ядрами процессора, Docker с установленным плагином Docker Compose (для Dify требуется Compose версии 2.24.0 или выше), а также пользователь с правами sudo или членством в группе docker. Команда клонирования ниже также использует git, curl и jq. Если вы новичок в Docker, в статье основы Docker Compose на VPS описаны процесс установки и базовые команды, которые подразумеваются в этом руководстве. Рекомендуется иметь доменное имя, направленное на сервер, так как для Dify предпочтительнее использовать TLS, а не прямой IP-адрес.

Шаг 1: Получение Dify и файлов Compose

Dify хранит настройки Docker в основном репозитории. Клонируйте последний релиз, а не ветку разработки, и перейдите в каталог docker:

git clone --branch "$(curl -s https://api.github.com/repos/langgenius/dify/releases/latest | jq -r .tag_name)" https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

Если клонирование завершается ошибкой "Remote branch null", значит, запрос к GitHub API не вернул данных; выберите версию на странице релизов и передайте её в --branch вручную.

Файл .env является основным конфигурационным файлом. Изучите его перед началом работы. В первую очередь важны параметры, задающие пароли и секретные ключи: SECRET_KEY, пароль Postgres и пароль Redis. Файл SECRET_KEY поставляется пустым; если оставить его в таком виде, Dify сгенерирует ключ самостоятельно и сохранит его в своем рабочем каталоге. С паролями ситуация иная: в примере файла для Postgres и Redis задан одинаковый difyai123456, а для песочницы кода, демона плагинов и Weaviate указаны стандартные, общеизвестные ключи. Использование этих значений по умолчанию — самая частая причина, по которой скомпрометированные экземпляры Dify оказываются взломаны. Если вы хотите задать собственный секретный ключ, сгенерируйте его:

openssl rand -base64 42

Вставьте полученное значение в SECRET_KEY и установите надежные уникальные значения для всех полей с паролями и ключами в файле. Пароль Redis также указан в CELERY_BROKER_URL, поэтому измените его и там, иначе воркер не сможет подключиться к Redis.

Шаг 2: Запуск

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

docker compose up -d

При первом запуске загружаются образы и инициализируется база данных, поэтому подождите около минуты. Убедитесь, что контейнеры работают корректно:

docker compose ps

Все постоянно работающие сервисы должны иметь статус running; задача по настройке прав доступа завершается сразу после выполнения. По умолчанию Dify предоставляет доступ к веб-интерфейсу через встроенный контейнер nginx на порту 80. При первом посещении http://YOUR_SERVER/install вам потребуется создать учетную запись администратора. Сделайте это незамедлительно, до того как кто-либо еще получит доступ к порту, так как до создания этой учетной записи любой пользователь, открывший страницу, может зарегистрировать её на себя и получить полный контроль над вашим экземпляром.

Шаг 3: Не оставляйте сервис открытым. Настройте TLS и межсетевой экран

На этом этапе большинство быстрых установок заканчиваются, а большинство инцидентов начинаются. Встроенный Nginx в Dify слушает 80 порт в открытом виде на всех интерфейсах и также публикует 443 порт. Недопустимо, чтобы данные для входа администратора и ключи моделей передавались по незашифрованному HTTP, как и то, чтобы внутренние сервисы были доступны извне.

Ограничьте доступ к серверу с помощью межсетевого экрана с политикой default-deny, разрешающей только SSH и веб-трафик:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Помните, что межсетевой экран, настроенный только для IPv4, может оставить те же порты открытыми в IPv6 — это проблема IPv6-фильтрации, на которой попадаются многие владельцы собственных серверов. Убедитесь, что оба стека защищены. Также учитывайте, что порты, публикуемые Docker, управляются собственными правилами Docker, а не ufw, и стандартная конфигурация публикует порт отладки плагинов 5003 на всех интерфейсах. Установите EXPOSE_PLUGIN_DEBUGGING_PORT в .env в значение 127.0.0.1:5003, если только вы не планируете отлаживать плагины с другого компьютера.

Для TLS самый надежный путь — привязать веб-порт Dify к loopback и запустить перед ним reverse proxy с сертификатом Let's Encrypt. В этом случае единственным компонентом, доступным из публичного интернета, будет прокси, работающий по HTTPS. Переменная .env в Dify позволяет изменить порт; установите привязку к 127.0.0.1 и укажите этот порт в настройках прокси. Сделайте то же самое для EXPOSE_NGINX_SSL_PORT, так как встроенный Nginx в Dify по умолчанию занимает 443 порт, который необходим вашему прокси. Рекомендации по защите агентов в статье безопасный запуск AI-агента на VPS применимы и здесь: держите компоненты на loopback, открывайте только необходимое и используйте один защищенный шлюз для TLS. Если интерфейс инструмента предназначен только для вас и не требует сертификата, откажитесь от прокси и используйте SSH-туннель, как это реализовано в self-hosting сканера безопасности open-kritt, где панель управления привязана к loopback и пробрасывается на ваш ноутбук вместо публикации в сеть. Если Dify нужен всей команде, но не публичному интернету, используйте overlay-сеть: объявление приватной подсети сервера в вашей tailnet позволит всем авторизованным устройствам обращаться к конструктору по внутреннему адресу, при этом межсетевой экран останется закрытым для всех, кроме SSH. Если вы администрируете сервер с помощью AI-агента, определите степень его самостоятельности, прежде чем передавать ему права доступа, так как режим прав, в котором вы оставляете Claude Code определяет, будет ли он запрашивать подтверждение перед изменением .env или перезапуском стека. Если вы используете одну сессию для просмотра логов контейнеров, а другую для редактирования конфигурации прокси, эти две сессии могут обмениваться текстом на одном сервере, что удобнее, чем копировать вывод между терминалами при каждой перезагрузке стека.

Шаг 4: Поддержание актуальности

Проект Dify развивается быстро, и обновления включают исправления безопасности. Поскольку вы клонировали конкретный тег релиза, обновление подразумевает переключение на следующий тег, а не обновление ветки. Сначала создайте резервную копию базы данных, затем из директории docker выполните:

docker compose down
git fetch --tags
git checkout NEW_VERSION
docker compose pull
docker compose up -d

Миграции базы данных запускаются автоматически при старте, и некоторые из них необратимы, поэтому резервное копирование выполняется в первую очередь. Читайте примечания к релизу перед каждым обновлением, а не только перед мажорными: разработчики Dify предупреждают, что шаги обновления различаются между версиями. Например, примечания к версии 1.17.1 (сентябрь 2026) предписывают пользователям, работающим с комплектным Weaviate и существующими данными, не переходить сразу на эту версию, а последовательно устанавливать каждый минорный релиз. Dify также меняет схему .env между релизами, поэтому сравнивайте .env.example с вашим .env после переключения на новый тег и переносите изменения, так как новая переменная, которую вы не задали, может привести к тому, что контейнер не запустится.

Шаг 5: Резервное копирование данных, которые невозможно восстановить

На сервере с Dify есть два незаменимых компонента: база данных Postgres, в которой хранятся ваши приложения, пользователи и настройки, а также том, где размещены загруженные документы и векторный индекс. Оба они находятся в Docker-томах в директории docker. Создавайте их снимки по расписанию и копируйте эти снимки за пределы сервера. Такие снимки содержат все ключи моделей и загруженные документы в одном файле, поэтому шифруйте их перед отправкой с сервера по той же причине, по которой резервная копия Vaultwarden становится слабым звеном в защите сервера паролей. Ключ API модели можно перевыпустить, а приложение, на создание которого вы потратили неделю, — нет. Тот же принцип применим к любому агенту, состояние которого должно сохраняться дольше, чем время работы машины: поддержание работы KiroCrew в виде постоянно запущенного контейнера сводится к созданию снимков памяти и расписаний, которые в противном случае исчезнут при следующей перезагрузке.

Если вы хотите, чтобы созданные здесь агенты выходили за рамки ваших собственных наборов данных и искали информацию в реальном Интернете, настройка на собственный экземпляр SearXNG позволит оставить поток запросов на оборудовании, которое вы контролируете, хотя перед включением стоит изучить вопрос уязвимости к prompt injection. Для более автономного агента, способного исполнять код, см. самостоятельный хостинг Agent Zero, а в статье создание собственного AI-агента на VPS описаны основы, лежащие в их фундаменте.

FAQ

Каковы системные требования для самостоятельного размещения Dify?

Dify требует минимум 4 GiB оперативной памяти и два ядра CPU, а также Docker Compose версии 2.24.0 или новее. Этот порог обусловлен размером стека по умолчанию: 15 постоянно работающих контейнеров плюс разовая задача инициализации (по состоянию на октябрь 2026 года). Выделите достаточно места на диске для загружаемых документов и векторного индекса, а также добавьте больше оперативной памяти, если на сервере работают другие приложения.

Безопасно ли открывать Dify напрямую на 80 порту?

Нет. Встроенный веб-сервер Dify работает по обычному HTTP, через который проходят данные для входа администратора и API-ключи ваших моделей. Установите перед ним reverse proxy с сертификатом Let's Encrypt, привяжите порт Dify к loopback-интерфейсу и разрешите доступ из Интернета только через HTTPS-прокси. Дополните это настройкой межсетевого экрана с политикой default-deny для IPv4 и IPv6.

Как обновить самостоятельно размещенный Dify?

Создайте резервную копию базы данных, затем в директории docker выполните docker compose down, git fetch --tags, git checkout для нового тега релиза, docker compose pull и docker compose up -d. Сначала ознакомьтесь с примечаниями к выпуску, так как шаги обновления различаются между версиями, миграции могут быть необратимыми, а Dify иногда добавляет новые переменные .env, отсутствие которых может привести к сбою запуска контейнера.

Что нужно сделать в первую очередь после установки Dify?

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