Dify на VPS: конструктор ИИ-агентов и RAG-ботов без кода

Зачем нужен отдельный инструмент, если есть API нейросети

Задача «чтобы бот отвечал по нашим документам» звучит просто, а на деле состоит из десятка мелких. Документы нужно разобрать из PDF и DOCX в текст. Текст — разрезать на фрагменты так, чтобы мысль не обрывалась на середине. Каждый фрагмент — превратить в набор чисел и сложить в специальную базу. На вопрос пользователя — найти в этой базе подходящие фрагменты, приложить их к вопросу и отправить модели. Ответ — вернуть в чат, сохранить историю переписки и не потерять контекст в следующем сообщении.

Всё это называется скучным словом RAG — генерация ответа с опорой на найденные документы. Написать такое руками — неделя работы программиста плюс поддержка. Dify даёт готовый конвейер: вы загружаете файлы мышкой, выбираете модель из списка и получаете рабочего бота со ссылкой, которую можно отправить коллегам.

Dify, n8n или Flowise — что брать

Все три — визуальные конструкторы, и их постоянно путают. Разница в том, вокруг чего построен инструмент.

Простое правило. Нужен только чат по документам и минимум возни — AnythingLLM. Нужны расписания, почта, таблицы и десятки сервисов — n8n. Нужно собрать продукт с чатом, знаниями, историей и публичной ссылкой — Dify. Именно за это он платит самым тяжёлым набором сервисов из всех четырёх.

Сколько это ест на самом деле

Dify — это не один контейнер. На чистой установке запускаются 15 контейнеров: сам API, отдельный сервис веб-сокетов для совместного редактирования, фоновый обработчик задач и его планировщик, веб-интерфейс, PostgreSQL, Redis, векторная база Weaviate, демон плагинов, бэкенд агентов, две песочницы для выполнения кода, два прокси и внутренний Nginx. Цифры, снятые на реальной установке 1.16.1 сразу после запуска:

Шаг 1. Подготовка сервера

Дальше всё делается на чистой Ubuntu 24.04. Нужен домен: заранее направьте A-запись поддомена (например dify.example.com) на IP сервера — сертификат без этого не выпустится. Ставим обновления и Docker:

sudo apt update && sudo apt upgrade -y
curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

Последняя команда разрешает запускать Docker без sudo, но применится только после нового входа. Выйдите из SSH и зайдите заново, затем проверьте версию Compose — нужна 2.24 или новее, на ней держится вся конфигурация Dify:

docker compose version

Если у сервера 4 ГБ памяти, сразу сделайте файл подкачки. Это не роскошь: без него индексация первого же большого документа может закончиться тем, что ядро убьёт контейнер.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Шаг 2. Скачать Dify

Берём конкретную версию, а не главную ветку: в main попадают недоделанные изменения. Флаг --depth 1 скачивает только последний срез вместо всей истории проекта — около 190 МБ.

git clone --depth 1 --branch 1.16.1 https://github.com/langgenius/dify.git ~/dify
cd ~/dify/docker
cp .env.example .env

Всё дальнейшее происходит в папке ~/dify/docker. Сам docker-compose.yamlтрогать не нужно вообще: вся настройка живёт в .env плюс один маленький файл-дополнение, который мы создадим на шаге 4. Это важно для будущих обновлений — изменённый docker-compose.yaml помешал бы переключиться на новую версию.

Шаг 3. Пароли и ключи

В .env.example пароли баз заполнены значениями по умолчанию, одинаковыми у всех и лежащими в открытом репозитории, а ключи подписи оставлены пустыми или с пометкой «замени перед продакшеном». Базы наружу не смотрят, но привести это в порядок всё равно нужно — и обязательно до первого запуска: пароль PostgreSQL задаётся в момент создания базы, после этого его так просто не поменять. Команда ниже генерирует случайные значения и подставляет их сама:

SECRET=$(openssl rand -base64 42)
DBPASS=$(openssl rand -base64 32 | tr -d '=+/')
REDISPASS=$(openssl rand -base64 32 | tr -d '=+/')
AGENTKEY=$(openssl rand -base64 32 | tr '+/' '-_' | tr -d '=')
AGENTTOKEN=$(openssl rand -base64 32 | tr -d '=+/')

sed -i \
  -e "s|^SECRET_KEY=.*|SECRET_KEY=$SECRET|" \
  -e "s|^DB_PASSWORD=.*|DB_PASSWORD=$DBPASS|" \
  -e "s|^REDIS_PASSWORD=.*|REDIS_PASSWORD=$REDISPASS|" \
  -e "s|^CELERY_BROKER_URL=.*|CELERY_BROKER_URL=redis://:$REDISPASS@redis:6379/1|" \
  -e "s|^DIFY_AGENT_SERVER_SECRET_KEY=.*|DIFY_AGENT_SERVER_SECRET_KEY=$AGENTKEY|" \
  -e "s|^DIFY_AGENT_API_TOKEN=.*|DIFY_AGENT_API_TOKEN=$AGENTTOKEN|" \
  .env

Три детали, из-за которых ручная правка часто ломает установку. Пароль Redis попадает ещё и в адрес очереди CELERY_BROKER_URL — поменяли в одном месте, обязаны поменять во втором, иначе фоновый обработчик молча не запустится. Пароли баз очищены от символов = + /, потому что они подставляются внутрь адреса подключения и слэш его сломает. А ключ DIFY_AGENT_SERVER_SECRET_KEY обязан быть ровно 32 байтами в формате base64url без выравнивания — именно это делает связка tr; любое другое значение и сервис агентов уйдёт в бесконечный перезапуск.

Теперь пароль установки. Пока он задан, посторонний не сможет создать администратора, даже если наткнётся на ваш адрес раньше вас. Придумайте свой, до 30 символов:

sed -i 's|^INIT_PASSWORD=.*|INIT_PASSWORD=MoyParolUstanovki2026|' .env

Шаг 4. Домен и закрытые порты

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

Заодно уводим внутренний Nginx Dify с портов 80 и 443 на локальный адрес: наружу его выставит настоящий Nginx с сертификатом. Подставьте свой домен в первую строку:

DOMAIN=dify.example.com

sed -i \
  -e "s|^CONSOLE_API_URL=.*|CONSOLE_API_URL=https://$DOMAIN|" \
  -e "s|^CONSOLE_WEB_URL=.*|CONSOLE_WEB_URL=https://$DOMAIN|" \
  -e "s|^SERVICE_API_URL=.*|SERVICE_API_URL=https://$DOMAIN|" \
  -e "s|^APP_API_URL=.*|APP_API_URL=https://$DOMAIN|" \
  -e "s|^APP_WEB_URL=.*|APP_WEB_URL=https://$DOMAIN|" \
  -e "s|^FILES_URL=.*|FILES_URL=https://$DOMAIN|" \
  -e "s|^TRIGGER_URL=.*|TRIGGER_URL=https://$DOMAIN|" \
  -e "s|^ENDPOINT_URL_TEMPLATE=.*|ENDPOINT_URL_TEMPLATE=https://$DOMAIN/e/{hook_id}|" \
  -e "s|^NEXT_PUBLIC_SOCKET_URL=.*|NEXT_PUBLIC_SOCKET_URL=wss://$DOMAIN|" \
  -e "s|^EXPOSE_NGINX_PORT=.*|EXPOSE_NGINX_PORT=127.0.0.1:8080|" \
  -e "s|^EXPOSE_NGINX_SSL_PORT=.*|EXPOSE_NGINX_SSL_PORT=127.0.0.1:8443|" \
  .env

Остался один порт, про который забывают все инструкции. Демон плагинов публикует наружу порт 5003 для удалённой отладки — на всех интерфейсах, а не только на локальном. Закрыть его через ufw не получится: Docker пишет свои правила ниже пользовательских и обходит их. Правильный способ — файл-дополнение к конфигурации, который переопределяет привязку порта:

cat > docker-compose.override.yaml <<'EOF'
services:
  plugin_daemon:
    ports: !override
      - "127.0.0.1:5003:5003"
EOF

Метка !override означает «замени список портов целиком, а не добавь к нему». Без неё Compose просто дописал бы вторую строку к первой, и открытый порт остался бы на месте. Compose подхватывает файл с таким именем автоматически, дополнительных ключей в командах не нужно.

И необязательное, но приятное. Раз в полчаса Dify отправляет на свои серверы анонимную статистику использования. Если это не нравится, допишите в .env строку DISABLE_TELEMETRY=true — в примере конфигурации её нет, но платформа её понимает.

Шаг 5. Запуск

docker compose up -d

Первый запуск занимает от пяти до пятнадцати минут — почти всё время уходит на скачивание образов. Дальше контейнер API применяет миграции базы и только потом начинает отвечать. Смотрим, что получилось:

docker compose ps

В колонке состояния всё должно быть Up или Up (healthy). Единственное исключение — init_permissions со статусом Exited (0): это разовая задача, которая выставляет права на папки и штатно завершается. Если что-то в состоянии Restarting, смотрите логи именно этого контейнера, например docker compose logs api --tail 50.

Убедимся, что интерфейс отвечает локально и что наружу ничего не торчит:

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8080/install
ss -tln | grep -E ':8080|:8443|:5003'

Шаг 6. Nginx и сертификат

Ставим веб-сервер и создаём для Dify отдельный конфиг:

sudo apt install -y nginx certbot python3-certbot-nginx

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name dify.example.com;

    client_max_body_size 100M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_buffering off;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Три строки здесь неочевидные, и без каждой что-нибудь сломается. client_max_body_size 100M — иначе загрузка документа больше мегабайта упрётся в стандартный лимит Nginx и вернёт ошибку 413. Блок map вместе с заголовками Upgrade и Connection пропускает веб-сокет, на котором держится редактор сценариев. proxy_read_timeout 3600s — ответ модели может идти минутами, а стандартная минута Nginx оборвёт его на середине.

Блок map стоит снаружи server — так и должно быть, он объявляется на весь веб-сервер. Если точно такой же блок уже есть в конфиге другого вашего сайта, ничего страшного: Nginx разрешает объявить его повторно и не ругается.

Включаем конфиг, проверяем синтаксис и выпускаем сертификат:

sudo ln -s /etc/nginx/sites-available/dify /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d dify.example.com

Certbot спросит почту, попросит согласиться с условиями и предложит включить перенаправление с HTTP на HTTPS — соглашайтесь. Он сам допишет в конфиг блок с сертификатом и настроит автопродление.

Если файрвол ещё не настроен — самое время. Наружу нужны только SSH и веб:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

Шаг 7. Первый вход

Откройте https://dify.example.com/install. Сначала Dify спросит пароль установки — то самое значение INIT_PASSWORD. Затем предложит создать администратора: почта, имя и пароль. Почта используется как логин, отправлять на неё письма Dify не обязан, так что подойдёт любая ваша.

Хорошая новость: в self-hosted-версии свободной регистрации нет вообще. Посторонний не заведёт себе аккаунт, даже зная адрес, — новые люди добавляются только по приглашению в Settings → Members. То есть после того, как вы создали администратора, дверь закрыта. Пароль установки своё дело сделал, но удалять его из .env не нужно: он всё равно перестаёт спрашиваться, как только администратор создан.

Шаг 8. Подключить модель

Без модели Dify — пустой конструктор. Провайдеры подключаются как плагины: аватар в правом верхнем углу → Settings → Model Provider, дальше находите нужного в списке, жмёте установку и вводите ключ.

Провайдеров больше сотни, и выбирать стоит не по названию модели, а по удобству: лучше тот, у кого один ключ открывает доступ сразу ко многим моделям — тогда модель в сценарии меняется в один клик, без новой регистрации. Под это описание хорошо подходит OpenRouter; если нужен один конкретный поставщик подешевле — есть отдельный плагин DeepSeek. Ключ вводится один раз и хранится в базе зашифрованным. Шифруется он парой ключей, которая лежит в файлах внутри volumes/app/storage — запомните это место, к бэкапу мы вернёмся: без этой папки ключи провайдеров из базы уже не расшифровать.

Отдельно нужна вторая модель — эмбеддингов. Она не пишет тексты, а превращает их в наборы чисел, по которым потом ищутся нужные фрагменты. Без неё база знаний работать не будет. И вот её как раз имеет смысл держать локально: она маленькая и спокойно живёт на процессоре. Добавляем Ollama в тот же набор контейнеров — допишите в docker-compose.override.yaml:

services:
  plugin_daemon:
    ports: !override
      - "127.0.0.1:5003:5003"

  ollama:
    image: ollama/ollama:latest
    restart: always
    volumes:
      - ./volumes/ollama:/root/.ollama

docker compose up -d ollama
docker compose exec ollama ollama pull bge-m3

Модель bge-m3 понимает больше сотни языков, включая русский, — для документов на русском это заметно лучше англоязычных моделей. Порт наружу не публикуется: Ollama видна только другим контейнерам Dify.

Теперь в Dify: Settings → Model Provider → установить плагин Ollama → добавить модель. Тип — Text Embedding, имя модели — bge-m3, адрес — http://ollama:11434.

Если Ollama у вас уже установлена на самом сервере, а не в контейнере, — контейнер ollama добавлять не нужно, зато нужно дать плагинам дорогу к хосту. В том же файле-дополнении:

services:
  plugin_daemon:
    ports: !override
      - "127.0.0.1:5003:5003"
    extra_hosts:
      - "host.docker.internal:host-gateway"

После docker compose up -d plugin_daemon адресом модели станет http://host.docker.internal:11434. И проверьте, что сама Ollama слушает не только петлевой адрес: по умолчанию она отвечает лишь на 127.0.0.1 и запрос из контейнера до неё не дойдёт.

Последний штрих: на той же странице Settings → Model Provider есть блок Default Models. Здесь выбираются модели по умолчанию — языковая и эмбеддингов. Пока эмбеддинги не выбраны, создать базу знаний в режиме качественного поиска не получится.

Шаг 9. Бот по своим документам

Собираем то, ради чего всё затевалось. Сначала база знаний, потом приложение, которое ей пользуется.

Шаг 10. Отдать людям

Сначала нажмите Publish — эта кнопка переводит черновик в рабочую версию, до неё бот виден только вам в окне проверки. После публикации на странице приложения появляются три способа отдать его людям.

Ссылка. Готовая страница с чатом на вашем домене — можно просто отправить коллегам.

Виджет на сайт. Кнопка Embedded выдаёт готовый кусок кода с вашим токеном: iframe для встраивания в страницу или скрипт, который рисует кружок чата в углу. Вставляется в шаблон сайта как есть, менять ничего не нужно — адрес там уже ваш, потому что мы прописали домен в .env.

HTTP-API. Раздел API Access внутри приложения выдаёт ключ вида app-.... Дальше бот вызывается откуда угодно — из своего кода, из n8n или из телеграм-бота:

curl -X POST https://dify.example.com/v1/chat-messages \
  -H "Authorization: Bearer app-ВАШ_КЛЮЧ" \
  -H "Content-Type: application/json" \
  -d '{
    "inputs": {},
    "query": "Какой срок возврата товара?",
    "response_mode": "blocking",
    "user": "user-1"
  }'

Поле user — ваш собственный идентификатор пользователя, по нему Dify разделяет истории переписки. Режим blocking ждёт готовый ответ целиком; для чата в интерфейсе используют streaming, чтобы текст появлялся по мере генерации.

Бэкап и обновление

Всё ценное лежит в двух местах: папке volumes и файле .env. Внутри volumes важно всё сразу: db — приложения, диалоги и настройки, weaviate — векторный индекс базы знаний, app/storage — загруженные файлы и те самые ключи шифрования, без которых ключи провайдеров из базы не прочитать. Копия делается при остановленных контейнерах — иначе рискуете снять базу в момент записи:

cd ~/dify/docker
docker compose down
sudo tar czf ~/dify-backup-$(date +%F).tar.gz volumes .env docker-compose.override.yaml
docker compose up -d

Обновление — переключиться на новый тег и подтянуть образы. Номер версии посмотрите на странице релизов проекта:

cd ~/dify/docker
docker compose down
cd ~/dify
git fetch --depth 1 origin tag 1.17.0
git checkout 1.17.0
cd docker
docker compose pull
docker compose up -d

Ваши .env и docker-compose.override.yaml при переключении не пострадают: git их не отслеживает. Но в новой версии могут появиться переменные, которых у вас нет. Проверить это можно одной командой — она сравнивает не значения, а именно набор имён:

cd ~/dify/docker
diff <(grep -oE '^[A-Z_]+' .env | sort) <(grep -oE '^[A-Z_]+' .env.example | sort)

Строки со знаком > — это новые переменные, их нужно дописать в свой .env со значениями из примера. И обязательно прочитайте release notes: миграции базы применяются автоматически при первом старте и назад не откатываются — вернуться на старую версию без бэкапа уже не выйдет.

Частые проблемы

cd ~/dify/docker
docker compose down
sudo rm -rf volumes/db volumes/redis volumes/weaviate volumes/app
docker compose up -d