Dify на своём сервере: конструктор AI-агентов без кода

1. TL;DR

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

• Используем Ubuntu Server 24.04 LTS.
• Устанавливаем Docker Engine 28.x и Docker Compose v2.
• Разворачиваем Dify 1.x из официального репозитория.
• Публикуем приложение через Caddy и HTTPS.
• Проверяем контейнеры, API, домен и резервное копирование.

2. Содержание

Инструкция рассчитана на администратора, который умеет подключаться к Linux-серверу по SSH и имеет зарегистрированный домен. Команды выполняются от обычного пользователя с правами sudo, если явно не указано иное.

Перед началом подготовьте доменное имя, например dify.example.com. В DNS создайте A-запись, указывающую на IPv4-адрес сервера. Если используется IPv6, добавьте AAAA-запись только после проверки корректной настройки firewall.

3. Что мы настраиваем и зачем

Что такое Dify

Dify — open-source-платформа для разработки приложений на базе больших языковых моделей. Она объединяет визуальный редактор промптов, workflow-движок, управление моделями, базы знаний, RAG-поиск, публикацию web-приложений и REST API.

В типичном сценарии пользователь задаёт вопрос в чате. Dify принимает запрос, при необходимости ищет релевантные фрагменты в документах, передаёт контекст языковой модели, применяет дополнительные правила и возвращает ответ. Такой процесс можно настроить через визуальные блоки без разработки отдельного backend-сервиса.

Какие задачи решает self-hosted Dify

• Внутренний корпоративный чат по документам и инструкциям.
• AI-агент для поддержки клиентов или первой линии helpdesk.
• Генерация текстов, классификация обращений и извлечение данных.
• RAG-поиск по PDF, DOCX, Markdown и другим материалам.
• Прототипирование AI-функций перед интеграцией в SaaS-продукт.
• Единый API-шлюз для нескольких поставщиков языковых моделей.

Что будет готово в конце

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

Важно понимать границы этой установки. Dify не превращает обычный VPS в самостоятельную языковую модель. Для генерации ответов нужно подключить внешний API провайдера либо развернуть локальную модель через Ollama, vLLM или другой совместимый сервер. Локальная модель дополнительно потребует GPU или большого объёма RAM.

Cloud-managed или self-hosted

Self-hosted-вариант имеет смысл, когда нужны контроль сетевого периметра, собственные политики хранения данных, предсказуемые ресурсы или возможность изменять инфраструктуру. Он также удобен для разработки, но требует регулярного обслуживания: обновлений, проверки диска, бэкапов и контроля секретов.

4. Какой VPS-конфиг нужен под эту задачу

Минимальная конфигурация

Dify запускается набором контейнеров, поэтому потребляет заметно больше ресурсов, чем один небольшой веб-сервис. На нагрузку влияют число одновременных workflow, размер индексов RAG, количество документов и выбранные модели.

Практичный стартовый вариант для команды из нескольких человек — 4 vCPU, 8 ГБ RAM, NVMe-диск от 100 ГБ и резервное копирование за пределами сервера. Можно взять подходящий VPS с такими характеристиками и позднее увеличить ресурсы без смены архитектуры.

Почему важен быстрый диск

В Dify одновременно работают PostgreSQL, Redis, векторное хранилище и фоновые задачи. Медленный HDD увеличивает время запуска контейнеров, индексации документов и выполнения workflow. SSD является минимально разумным вариантом, а NVMe предпочтителен при частых загрузках файлов и нескольких пользователях.

Когда нужен dedicated

Выделенный сервер оправдан, если требуется собственная локальная языковая модель, большой индекс документов, десятки или сотни параллельных запросов, строгая изоляция ресурсов или GPU. Для Dify без локальной LLM dedicated обычно не нужен: приложение может обращаться к внешнему API, а VPS остаётся достаточно экономичным.

Выбор локации

Регион сервера влияет на задержку до пользователей, доступность API-провайдеров и юридические требования к данным. Для интерактивного чата желательно выбирать дата-центр ближе к основной аудитории. Если Dify обращается к внешней модели в другом регионе, измеряйте задержку до обоих endpoints, а не только до сервера.

Для production-сервера также нужны публичный IPv4, возможность открыть TCP-порты 80 и 443, автоматические snapshots либо внешнее хранилище бэкапов. Не рассчитывайте на snapshot как на единственную копию: повреждение аккаунта или удаление VPS может уничтожить и snapshot.

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

Подключение и обновление системы

Ниже предполагается чистый сервер Ubuntu Server 24.04 LTS с пользователем root. Замените IP-адрес на адрес своего VPS.

ssh [email protected]

Сначала обновим индекс пакетов и установленные компоненты.

apt update && apt full-upgrade -y
apt install -y ca-certificates curl gnupg git jq unzip vim ufw fail2ban unattended-upgrades

Первая команда устанавливает обновления безопасности. Вторая добавляет утилиты для репозиториев, диагностики, firewall и автоматической установки security-обновлений.

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

Не используйте постоянный SSH-доступ под root. Создайте отдельного пользователя и добавьте его в группу sudo.

adduser deploy
usermod -aG sudo deploy
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

На локальном компьютере сгенерируйте ключ ED25519, если его ещё нет.

ssh-keygen -t ed25519 -C "dify-admin"

Скопируйте открытый ключ на сервер. Команда запросит пароль пользователя deploy.

ssh-copy-id [email protected]
ssh [email protected]

Убедитесь, что sudo работает.

sudo -v
id

Настройка SSH

До отключения входа по паролю проверьте, что новая SSH-сессия с ключом открывается. Затем создайте отдельный drop-in-файл.

sudo tee /etc/ssh/sshd_config.d/ hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
EOF

В команде выше не должно быть пробела внутри пути. Корректный вариант, если оболочка не обработала строку с пробелом:

sudo tee /etc/ssh/sshd_config.d/hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
EOF
sudo sshd -t
sudo systemctl reload ssh

Проверка sshd -t обязательна: она не позволяет применить синтаксически неправильную конфигурацию. Старую SSH-сессию не закрывайте, пока не проверите новый вход в отдельном окне.

Firewall и fail2ban

Откроем SSH, HTTP и HTTPS. Порт SSH лучше ограничить своим IP-адресом, если он постоянный.

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

Включим защиту SSH от перебора паролей и ключей.

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

В production полезно ограничить SSH правилом вроде sudo ufw allow from 198.51.100.25 to any port 22 proto tcp. Не выполняйте его, пока не знаете свой актуальный адрес: ошибочное правило может закрыть доступ.

Автоматические security-обновления

sudo dpkg-reconfigure -plow unattended-upgrades
sudo systemctl status unattended-upgrades --no-pager

Автоматические обновления полезны для пакетов операционной системы, но не заменяют плановое обновление Docker-образов Dify. Версию приложения меняйте отдельно и только после бэкапа.

6. Установка ПО — пошагово

Шаг 1. Установка Docker Engine

Для Dify в 2026 году используйте Docker Engine 27 или 28 и Docker Compose v2. Не устанавливайте старый пакет docker-compose из случайного PPA: актуальная команда — docker compose.

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

Команды добавляют официальный ключ Docker и подготавливают каталог для подписанных репозиториев.

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list >/dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Проверим версии и тестовый контейнер.

sudo docker version
sudo docker compose version
sudo docker run --rm hello-world

Добавьте пользователя deploy в группу Docker, чтобы не использовать sudo для каждой команды.

sudo usermod -aG docker "$USER"
newgrp docker
docker ps

Членство в группе Docker фактически предоставляет права root. Поэтому доступ к серверу должен быть защищён SSH-ключами, firewall и ограниченным числом администраторов.

Шаг 2. Загрузка Dify

Официальный self-hosted-пакет Dify находится в Git-репозитории проекта. Для production зафиксируйте проверенный релиз, а не оставляйте приложение на произвольной ветке разработки. Ниже показан пример для линейки Dify 1.x; перед установкой сверяйте имя последнего стабильного тега в официальном репозитории.

sudo mkdir -p /opt
sudo chown deploy:deploy /opt
cd /opt
git clone https://github.com/langgenius/dify.git
cd /opt/dify/docker

Если вы выбрали конкретный стабильный тег, переключите репозиторий на него. Значение тега должно существовать в момент установки.

git fetch --tags
git tag --sort=-v:refname | head -n 10
git checkout 1.9.1

Если в официальном репозитории уже выпущен более новый стабильный релиз, замените 1.9.1 на него. Не смешивайте файлы из разных релизов и не копируйте старый .env без проверки новых параметров.

Шаг 3. Создание файла окружения

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

cd /opt/dify/docker
cp .env.example .env
chmod 600 .env
sed -n '1,80p' .env

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

python3 - <<'PY'
import secrets
for name in ("SECRET_KEY", "INIT_PASSWORD", "DB_PASSWORD", "REDIS_PASSWORD"):
    print(f"{name}={secrets.token_urlsafe(32)}")
PY

Скопируйте полученные значения в соответствующие строки .env. Для автоматического редактирования можно использовать редактор:

nano /opt/dify/docker/.env

Шаг 4. Запуск контейнеров

Перед первым запуском проверьте, какие compose-файлы входят в выбранный релиз.

cd /opt/dify/docker
docker compose config --quiet

Если команда завершилась без сообщения об ошибке, конфигурация синтаксически корректна. Запустите стек в фоне.

docker compose up -d

Первый запуск может занять несколько минут: Docker скачает образы PostgreSQL, Redis, векторного хранилища, API, worker и web-компонентов.

Шаг 5. Проверка состояния

docker compose ps
docker compose logs --tail=100 api
docker compose logs --tail=100 worker

Большинство контейнеров должны иметь состояние Up или running. Однократное состояние health: starting после запуска нормально, но оно должно измениться через несколько минут.

Шаг 6. Локальная проверка HTTP

Проверьте, какой порт опубликован compose-конфигурацией.

docker compose port nginx 80
curl -I http://127.0.0.1

Если в выбранной версии внешний proxy-контейнер называется иначе, используйте имя из вывода docker compose ps. Ответ 200, 301 или 302 означает, что HTTP-слой отвечает. Ошибка 502 требует проверки backend-контейнеров.

7. Конфигурация

Основные параметры Dify

Ниже приведены параметры, которые обычно требуется проверить в /opt/dify/docker/.env. Названия отдельных переменных могут меняться между релизами, поэтому ориентируйтесь на комментарии текущего .env.example.

cd /opt/dify/docker
grep -E '^(SECRET_KEY|INIT_PASSWORD|CONSOLE_API_URL|CONSOLE_WEB_URL|SERVICE_API_URL|FILES_URL|DB_|REDIS_|VECTOR|LOG_LEVEL)' .env

Для домена Dify обычно задают URL консоли, API и файлового сервиса. Пример:

CONSOLE_API_URL=https://dify.example.com
CONSOLE_WEB_URL=https://dify.example.com
SERVICE_API_URL=https://dify.example.com
APP_WEB_URL=https://dify.example.com
FILES_URL=https://dify.example.com

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

Подключение провайдера языковой модели

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

Для первого теста задайте недорогую модель с ограниченным контекстом и установите лимиты расходов у API-провайдера. Затем создайте простое Chatflow-приложение с системной инструкцией и одним тестовым вопросом. Проверяйте не только качество ответа, но и количество токенов, latency и ошибочные вызовы инструментов.

Подключение базы знаний

1. Создайте Dataset в панели Dify.
2. Загрузите небольшой набор документов без конфиденциальных данных.
3. Выберите способ разбиения текста и размер чанка.
4. Дождитесь завершения индексации.
5. Создайте приложение с блоком поиска по Dataset.
6. Проверьте ответ на вопрос, который явно есть в документах.

Если документы содержат таблицы, сканы или сложную вёрстку, проверьте качество извлечения текста отдельно. RAG не исправляет ошибки OCR и не гарантирует точную цитату при неправильном разбиении исходного файла.

Reverse proxy через Caddy

Встроенный proxy Dify удобен для локального запуска, но отдельный Caddy упрощает получение и продление сертификата. В этом варианте Caddy будет слушать порты 80 и 443 на хосте, а Dify будет доступен только через локальный порт.

Сначала остановите или перенастройте компонент Dify, который уже занимает 80-й порт. Названия сервисов отличаются по версии, поэтому сначала посмотрите список публикаций:

cd /opt/dify/docker
docker compose ps
docker compose port nginx 80 || true
sudo ss -ltnp | grep -E ':(80|443)\b'

Установите Caddy из официального apt-репозитория:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

Создайте конфигурацию Caddy. Если Dify публикует HTTP на другой локальный порт, замените 127.0.0.1:8080 на фактический адрес.

dify.example.com {
    reverse_proxy 127.0.0.1:8080

    header {
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        X-Frame-Options "SAMEORIGIN"
    }

    log {
        output file /var/log/caddy/dify-access.log
        format json
    }
}

Запишите файл, проверьте его и перезапустите Caddy:

sudo caddy fmt --overwrite /etc/caddy/Caddyfile
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl enable --now caddy
sudo systemctl reload caddy
sudo journalctl -u caddy -n 50 --no-pager

Caddy автоматически запросит сертификат Let’s Encrypt, если DNS уже указывает на сервер и порты 80/443 доступны из интернета. Для приватного домена без публичной DNS-записи автоматический публичный сертификат не сработает; в таком случае используйте корпоративный CA или VPN.

Проверка домена и HTTPS

dig +short dify.example.com
curl -I https://dify.example.com
curl -sS -o /dev/null -w '%{http_code}\n' https://dify.example.com

Проверьте срок действия сертификата:

echo | openssl s_client -connect dify.example.com:443 -servername dify.example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Проверка контейнеров и ресурсов

cd /opt/dify/docker
docker compose ps
docker stats --no-stream
df -h
free -h
sudo journalctl -u docker --since "30 minutes ago" --no-pager

Оставляйте минимум 15–20 процентов свободного диска. Docker-образы, логи и загруженные документы постепенно увеличивают потребление. При заполнении диска PostgreSQL и Redis могут завершиться с ошибками, даже если CPU и RAM свободны.

Создание первого приложения

1. Откройте URL Dify и завершите первоначальную настройку администратора.
2. Добавьте модель в разделе Model Provider.
3. Создайте Chatflow или Workflow.
4. Задайте системную инструкцию и ограничение области ответа.
5. Опубликуйте приложение и протестируйте web-интерфейс.
6. Для интеграции скопируйте API-ключ приложения, а не пароль администратора.

API-ключи считайте паролями: выдавайте отдельный ключ для каждого сервиса, храните его в секрет-хранилище и отзывайте после завершения эксперимента. Не помещайте ключ в JavaScript-код, который отправляется браузеру пользователю.

8. Бэкапы и обслуживание

Что необходимо сохранять

• PostgreSQL: пользователи, приложения, настройки и метаданные.
• Файлы Dify: загруженные документы, изображения и результаты обработки.
• Векторное хранилище: индексы Dataset либо исходные документы для восстановления.
• .env и выбранные compose-файлы.
• Конфигурацию Caddy и firewall.
• Список версий Docker-образов и Git-тег Dify.

Файл .env содержит секреты, поэтому резервная копия должна быть зашифрована. Не складывайте его в публичный Git-репозиторий и не отправляйте в обычное объектное хранилище без шифрования.

Локальный дамп PostgreSQL

Точная команда зависит от имени контейнера и базы в выбранном релизе. Получить имя можно так:

cd /opt/dify/docker
docker compose ps --services
docker compose ps | grep -E 'postgres|db'

Если сервис базы называется db, пример дампа выглядит следующим образом:

mkdir -p /opt/backups/dify
docker compose exec -T db pg_dump -U postgres dify | gzip > "/opt/backups/dify/postgres-$(date +%F-%H%M).sql.gz"
find /opt/backups/dify -type f -name '.sql.gz' -mtime +14 -delete

sudo apt install -y restic
sudo install -d -m 700 /etc/restic
sudo nano /etc/restic/dify.env

AWS_ACCESS_KEY_ID=replace-me
AWS_SECRET_ACCESS_KEY=replace-me
RESTIC_REPOSITORY=s3:https://s3.example.net/dify-backups
RESTIC_PASSWORD=replace-with-long-random-password

sudo chmod 600 /etc/restic/dify.env
sudo restic --env-file /etc/restic/dify.env init

sudo tee /usr/local/sbin/backup-dify >/dev/null <<'EOF'
#!/usr/bin/env bash
set -Eeuo pipefail

BASE=/opt/dify/docker
WORK=/var/backups/dify
STAMP=$(date +%F-%H%M)
mkdir -p "$WORK"

cd "$BASE"
docker compose exec -T db pg_dump -U postgres dify | gzip > "$WORK/postgres-$STAMP.sql.gz"

tar --exclude='.log' -czf "$WORK/config-$STAMP.tar.gz" \
  "$BASE/.env" "$BASE/docker-compose.yaml" /etc/caddy/Caddyfile

restic --env-file /etc/restic/dify.env backup "$WORK" /opt/dify
restic --env-file /etc/restic/dify.env forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

find "$WORK" -type f -mtime +2 -delete
EOF

sudo chmod 700 /usr/local/sbin/backup-dify
sudo /usr/local/sbin/backup-dify

Проверьте наличие snapshot:

sudo restic --env-file /etc/restic/dify.env snapshots
sudo restic --env-file /etc/restic/dify.env check

Запуск по расписанию

Создайте cron-задачу от root. Время выберите с учётом часового пояса и нагрузки.

sudo crontab -e

30 3   * /usr/local/sbin/backup-dify >> /var/log/backup-dify.log 2>&1

Минимум раз в месяц выполняйте тестовое восстановление на отдельной машине или временном VPS. Бэкап, который ни разу не восстанавливали, является только предположением о наличии данных.

Обновление Dify

Перед обновлением сохраните текущий Git-тег, конфигурацию, дамп PostgreSQL и список образов.

cd /opt/dify
git rev-parse --short HEAD
cd docker
docker compose images
sudo /usr/local/sbin/backup-dify

Затем получите новый релиз и изучите его release notes. Не обновляйте production напрямую из ветки main. Сначала протестируйте новую версию на копии базы или staging-сервере.

cd /opt/dify
git fetch --tags
git checkout 1.9.1
cd docker
docker compose pull
docker compose config --quiet
docker compose up -d
docker compose ps

После обновления проверьте вход в консоль, создание тестового приложения, поиск по Dataset и API. Для небольшой установки обычно подходит maintenance window на 10–30 минут. Rolling update требует нескольких экземпляров API и worker, общего хранилища и отдельной схемы миграций, поэтому не нужен для первого VPS.

Мониторинг

Начните с простых проверок: свободное место, RAM, состояние контейнеров, ошибки Docker и срок TLS-сертификата. Для постоянной эксплуатации добавьте Uptime Kuma, Prometheus или другой мониторинг, но не размещайте единственный мониторинг на том же VPS.

df -h /
free -m
docker compose -f /opt/dify/docker/docker-compose.yaml ps
docker system df
sudo journalctl -p warning..alert --since today --no-pager

9. Troubleshooting и FAQ

После запуска контейнеры постоянно перезапускаются. Что проверить?

Сначала выполните docker compose ps и посмотрите логи конкретного сервиса: docker compose logs --tail=200 api, worker, db или redis. Частые причины — неправильные секреты в .env, недостаток RAM, занятый порт или несовместимый compose-файл. Проверьте free -h, df -h и docker compose config. После исправления перезапустите только проблемный стек командой docker compose up -d.

Какой VPS-конфиг минимально подойдёт?

Для знакомства с Dify можно начать с 2 vCPU, 4 ГБ RAM и SSD от 50 ГБ, но это нижняя граница для одного пользователя и небольших тестов. Для реальной команды лучше выбрать 4 vCPU, 8 ГБ RAM и NVMe от 80–100 ГБ. Если планируется локальная LLM, эти требования уже не подходят: понадобится отдельный GPU-сервер либо мощный dedicated с большим объёмом RAM.

Что выбрать — VPS или dedicated для этой задачи?

VPS подходит для большинства Dify-проектов, использующих внешние API моделей: он дешевле, проще масштабируется и достаточен для небольшой или средней команды. Dedicated имеет смысл при постоянной высокой нагрузке, локальном inference, большом векторном индексе, GPU или строгой изоляции ресурсов. Начать можно с VPS и перенести Docker Compose на dedicated позднее, если метрики покажут нехватку CPU, RAM, диска или I/O.

Открывается 502 Bad Gateway через домен. Где искать причину?

Проверьте, отвечает ли backend локально: curl -I http://127.0.0.1:8080 или фактический порт из compose-конфигурации. Затем посмотрите sudo journalctl -u caddy -n 100 и docker compose logs --tail=100. Часто Caddy настроен на неправильный порт, контейнер Dify не запущен или порт уже занят встроенным proxy. Также проверьте, что Caddy и Docker используют один и тот же loopback-адрес.

Сертификат Let’s Encrypt не выпускается. Что делать?

Убедитесь, что A-запись домена возвращает публичный адрес VPS: dig +short dify.example.com. Порты 80 и 443 должны быть разрешены одновременно в UFW и в firewall провайдера. Проверьте, не указывает ли AAAA-запись на неработающий IPv6: центр сертификации может выбрать IPv6 и получить ошибку. Логи Caddy покажут точную причину, например DNS failure, timeout или rate limit.

Dify не видит добавленную языковую модель. Почему?

Проверьте API-ключ, endpoint и выбранный тип модели. Если провайдер использует совместимый OpenAI API, URL должен указывать на правильный base path, а не только на домен. Выполните тест соединения из контейнера или с хоста через curl, учитывая, что в контейнере может отсутствовать DNS-доступ или исходящий firewall. Проверьте лимиты аккаунта провайдера и время на сервере через timedatectl.

Индексация документов зависла на одном проценте.

Посмотрите логи worker и векторного хранилища: docker compose logs --tail=200 worker и соответствующего vector-сервиса. Проверьте свободное место, RAM и доступность Redis. Большой PDF, скан без текстового слоя или повреждённый архив может блокировать обработку. Для диагностики загрузите небольшой текстовый файл. Если маленький файл индексируется, проблема, вероятно, в формате или размере исходного документа.

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

Самый простой вариант — закрыть 80/443 для всего интернета и пускать пользователей через WireGuard или корпоративный VPN. Если публичный доступ необходим, используйте длинные уникальные пароли, MFA, отдельные API-ключи, fail2ban и внешний WAF. Не публикуйте Docker-порты PostgreSQL, Redis и векторного хранилища наружу. В firewall должны быть открыты только SSH, HTTP и HTTPS, а SSH желательно ограничить доверенными IP.

Можно ли запустить Dify с локальной моделью на том же VPS?

Технически можно подключить совместимый inference-сервис, но обычный VPS без GPU будет работать медленно. Для небольшой квантованной модели потребуется много RAM, а скорость генерации может оказаться неприемлемой. Практичнее оставить Dify на CPU-VPS, а inference вынести на GPU-сервер. Связь между ними ограничьте приватной сетью, VPN или firewall allowlist и включите TLS для API модели.

10. Выводы и следующие шаги

В результате вы получили self-hosted Dify на Ubuntu с Docker Compose, подключением языковой модели, HTTPS-доменом и базовой схемой резервного копирования. Такая установка подходит для прототипов, внутренних AI-инструментов, RAG-баз знаний и небольших production-команд.

Следующий практический этап — вынести staging в отдельный проект, добавить мониторинг ресурсов и регулярно тестировать восстановление бэкапов. При росте нагрузки измеряйте CPU, RAM, I/O, размер PostgreSQL и время обработки workflow, а не увеличивайте тариф вслепую. Для локальных моделей и постоянной высокой нагрузки заранее планируйте отдельный GPU или dedicated-сервер.