Dify в Docker: установка, первичная настройка и подключение моделей

Dify в Docker ставится четырьмя командами, но дальше начинаются вопросы: что проверить, если страница не открывается, как создать администратора и куда вписать ключ модели. Ниже — установка Dify через Docker Compose по официальной документации, первичная настройка и подключение моделей через OpenAI-совместимый шлюз. Версии и состав контейнеров у Dify обновляются, поэтому если что-то отличается от текста, ориентируйтесь на страницу «Deploy Dify with Docker Compose» в документации Dify (docs.dify.ai).

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

Минимальные требования по документации Dify:

• процессор: 2 ядра и больше;
• память: 4 GiB и больше;
• Docker Compose версии 2.24.0 и новее (проверьте командой docker compose version);
• на Linux — Docker 19.03+, на macOS и Windows — Docker Desktop (для macOS в документации советуют выделить виртуальной машине Docker не менее 2 vCPU и 8 GiB памяти; на Windows нужен WSL 2, а код и данные лучше держать в файловой системе Linux).

Для клонирования репозитория понадобятся git, а для команды из документации ещё curl и jq. Исходники и описание проекта лежат в репозитории github.com/langgenius/dify↗.

Dify в Docker: установка по шагам

1. Клонируйте репозиторий

Команда из документации берёт последний релиз через GitHub API:

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

Если она падает с fatal: Remote branch null not found in upstream origin, GitHub, скорее всего, ограничил запросы без авторизации и jq вернул null. Укажите версию явно, подставив номер последнего релиза со страницы Releases:

git clone --branch <версия> https://github.com/langgenius/dify.git

2. Подготовьте конфигурацию и запустите

cd dify/docker
cp .env.example .env
docker compose up -d

В .env лежат основные значения запуска; опциональные настройки поставщиков лежат шаблонами в docker/envs/. Если меняете настройки, после правки перезапустите: docker compose down, затем docker compose up -d.

Первый запуск скачивает образы и занимает несколько минут. Запускается около полутора десятков контейнеров: основные сервисы (api, worker, web, plugin_daemon и другие), зависимости (db_postgres, redis, weaviate, nginx, sandbox, ssrf_proxy) и одноразовая задача init_permissions, которая выставляет права на хранилище и завершается.

3. Проверьте, что всё поднялось

docker compose ps

У каждого контейнера должен быть статус Up или healthy. Статус Exited у init_permissions — нормально.

4. Создайте администратора

Откройте страницу инициализации:

• на своей машине: http://localhost/install;
• на сервере: http://IP_сервера/install.

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

Подключение моделей через шлюз

В Dify модели подключаются через провайдеров. Для любого OpenAI-совместимого API используется плагин OpenAI-API-compatible. Кратко, подробности по каждому полю — в статье подключение Zukko к Dify↗:

1. В кабинете Zukko↗ создайте ключ fetch_... (показывается один раз).
2. В Dify откройте Integrations → Model Provider, установите плагин OpenAI-API-compatible (из Marketplace) и нажмите Add Model. В старых версиях путь к разделу может отличаться: ищите Model Provider в настройках рабочего пространства.
3. Укажите тип модели LLM, имя модели из GET https://api.zukko.pro/v1/models (например, claude-sonnet-5-5 или deepseek-v4.1-flash), ключ и API Base URL https://api.zukko.pro/v1 (именно с /v1, без /chat/completions).
4. Поставьте реальный размер контекста модели: если оставить значение по умолчанию, Dify будет считать, что модель принимает мало токенов.
5. Сохраните: Dify проверит данные перед тем, как сделать модель доступной.

Перед этим полезно убедиться, что сервер вообще достаёт до шлюза. Выполните на машине с Dify:

curl https://api.zukko.pro/v1/models \
  -H "Authorization: Bearer fetch_ваш_ключ"

Если список моделей пришёл, сеть в порядке. Плагины ставятся из Marketplace, поэтому серверу нужен выход в интернет. Документация API Zukko — в разделе chat completions↗.

Для эмбеддингов базы знаний нужен отдельный провайдер: в каталоге Zukko моделей эмбеддингов нет, только чат-модели.

Ориентир по стоимости. Допустим, один запуск рабочего процесса тратит 3 000 токенов входа и 500 выхода, а запусков 1 000. Это 3M входа и 0.5M выхода. Цены на 18 октября 2026, вход / выход за 1M:

• glm-5.3-flash (0.04 / 0.04): 3 × $0.04 + 0.5 × $0.04 = $0.12 + $0.02 = $0.14;
• gpt-6.1-sol (0.27 / 1.32): 3 × $0.27 + 0.5 × $1.32 = $0.81 + $0.66 = $1.47;
• claude-sonnet-5-5 (0.4 / 2): 3 × $0.4 + 0.5 × $2 = $1.20 + $1.00 = $2.20.

Dify вызывает модель по OpenAI-формату, поэтому у Claude кэш скидки не даёт: весь вход считается по цене входа. Пример условный, ваши объёмы смотрите в разделе «Использование» кабинета. Отдельный ключ с дневным и месячным лимитом для Dify задайте заранее (см. лимиты ключей↗).

Типичные проблемы при запуске

Порт 80 занят. Остановите конфликтующий сервис (чаще всего Nginx или Apache на хосте) или смените проброс порта в docker-compose.yaml, например на "8080:80". После этого Dify будет открываться на http://localhost:8080.

502 Bad Gateway. Документация Dify связывает это с тем, что Nginx пересылает запросы на устаревшие IP контейнеров (IP меняются при перезапуске контейнеров). Там советуют узнать текущие IP командой docker inspect и перезапустить Nginx или перечитать его конфигурацию; подробности в разделе Docker Issues документации Dify.

Страница бесконечно грузится, в консоли браузера ошибки CORS. Обычно меняли домен или адрес. Проверьте переменные CONSOLE_API_URL, CONSOLE_WEB_URL, SERVICE_API_URL, APP_API_URL и APP_WEB_URL: они должны совпадать с адресом, по которому вы заходите.

Вход «проходит», но сессия сбрасывается. Если интерфейс и API разнесены по поддоменам за обратным прокси, нужны COOKIE_DOMAIN (общий домен верхнего уровня) и NEXT_PUBLIC_COOKIE_DOMAIN=1.

Контейнеры не поднялись после перезагрузки. Выполните docker compose down, затем docker compose up -d и дождитесь healthy.

Dify не достаёт до сервиса на хосте. Контейнер не видит хост по 127.0.0.1: используйте IP машины в локальной сети. К шлюзу в интернете это не относится.

Ошибки модели после подключения (401, 402, 403 model_not_allowed_for_key, 404 model_not_found) разобраны в статье 401, 402, model not found: ошибки подключения↗.

Обновление и безопасность

Перед обновлением сделайте копию: cp -r dify "dify.bak.$(date +%Y%m%d%H%M%S)". Шаги обновления зависят от релиза, их описывают на странице Releases. После обновления сравните каждый .env.example со своим .env: могли появиться новые переменные, а в Compose-файле — новые сервисы.

Если Dify доступен из интернета, закройте его HTTPS и ограничьте доступ: в Dify хранятся ключи провайдеров, а они дают прямой доступ к вашему балансу. Ключ Zukko лучше завести отдельный, с дневным лимитом.

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

Сколько ресурсов нужно Dify?

Минимум по документации — 2 ядра CPU и 4 GiB RAM. Для реальной нагрузки и базы знаний нужно больше: ориентируйтесь на мониторинг своего сервера.

Можно ли использовать Dify без Docker?

Да, в документации Dify описан запуск из исходного кода, но для начала проще Docker Compose.

Какую модель поставить первой?

Для проверки подключения подойдёт любая недорогая, например deepseek-v4.1-flash или glm-5.3-flash. Под боевой узел выбирайте после теста на 20–30 своих примерах.

Работает ли это с облачной версией Dify?

Подключение модели тем же плагином и с теми же полями доступно и в облачной версии; Docker нужен только для собственного сервера. Что такое Dify вообще, объясняется отдельно в обзорной статье в блоге.

Когда Dify поднялся, создайте ключ на странице API-ключей↗ и добавьте первую модель.