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-сервер.