Як розгорнути Dify на VPS через Docker Compose

Що таке Dify і що ви погоджуєтеся запускати

Dify — це платформа, яку можна розгорнути на власній інфраструктурі для створення застосунків на базі великих мовних моделей. Вона надає вебінтерфейс для розробки чат-застосунків, агентів і retrieval-пайплайнів, API для виклику цих компонентів із власного коду, а також єдине місце для керування промптами, наборами даних і ключами моделей. Це інструмент, який невелика команда розгортає як спільну приватну основу, замість того щоб зберігати API-ключі в різних скриптах. Якщо такі поняття, як agent, tool call і retrieval pipeline, вам ще не цілком зрозумілі, спочатку розберіть ці концепції з нуля. Тоді екрани конструктора Dify сприйматимуться як зрозумілі елементи керування, а не як набір перемикачів без пояснень.

Самостійне розгортання означає запуск кількох компонентів. Dify постачається як набір Docker-контейнерів: API-сервер, фоновий worker, вебfrontend, база даних Postgres, кеш Redis і векторна база даних. Усі вони з’єднані за допомогою Docker Compose. Це більше, ніж один бінарний файл, але Compose налаштовує взаємодію компонентів, а VPS із запасом у кілька гігабайтів RAM працює з таким навантаженням без проблем. Якщо на цьому VPS працюватимуть і інші сервіси, визначайте його конфігурацію за виміряними показниками, а не за заявленими мінімальними вимогами, оскільки фактичні мінімальні обсяги RAM для PhotoPrism та Immich значно перевищують опубліковані значення, а photo server на тому самому сервері спочатку залишатиме без ресурсів базу даних і vector store Dify. Конкуренція за CPU працює так само: бібліотека Jellyfin, стилізована під відеомагазин 90s майже не створює навантаження під час перегляду обкладинок, але щойно хтось запускає transcode, worker Dify стає в чергу за ним. Перевага в тому, що кількість контейнерів Dify не змінюється незалежно від кількості створених застосунків. Це передбачуваніша модель витрат, ніж у OpenBot, де кожен AI coworker отримує власний контейнер і власний браузер, а кожен новий працівник знову підвищує мінімальну потребу в пам’яті.

Оскільки Dify зберігає API-ключі моделей і часто приватні документи, завантажені для retrieval, із першої хвилини вважайте сервер, на якому він працює, чутливим ресурсом. Цей посібник встановлює Dify, а потім захищає його так само, як і будь-який сервіс, що зберігає секрети.

Передумови

Вам потрібен VPS під керуванням Ubuntu 24.04 із встановленими Docker і плагіном Docker Compose, а також користувач із sudo або членством у групі docker. Якщо Docker для вас новий, у матеріалі основи Docker Compose на VPS описано встановлення та основні команди, які передбачає цей посібник. Бажано також мати доменне ім’я, спрямоване на сервер, оскільки перед Dify потрібен TLS, а не прямий доступ за IP-адресою.

Крок 1: Отримайте Dify та його Compose-файли

Dify зберігає конфігурацію Docker в основному репозиторії. Клонуйте репозиторій і перейдіть до каталогу docker:

git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env

Файл .env містить усю конфігурацію. Прочитайте його перед запуском. Спочатку зверніть увагу на параметри паролів і секретів: SECRET_KEY, пароль Postgres і пароль Redis. Файл-приклад містить стандартні значення-заповнювачі. Якщо залишити їх без змін, це найпоширеніша причина компрометації self-hosted Dify. Згенеруйте справжній секретний ключ:

openssl rand -base64 42

Вставте його у SECRET_KEY і задайте сильне унікальне значення для кожного поля пароля у файлі.

Крок 2: Запустіть його

Запустіть стек:

docker compose up -d

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

docker compose ps

Кожен сервіс має прочитати running. Dify за замовчуванням обслуговує вебінтерфейс через вбудований контейнер nginx на порту 80. Під час першого переходу до http://YOUR_SERVER/install створіть обліковий запис адміністратора. Зробіть це негайно, перш ніж до порту зможе підключитися будь-хто інший, оскільки до створення цього облікового запису будь-який користувач, який відкриє сторінку, може зареєструвати його та отримати контроль над вашим екземпляром.

Крок 3: Не виставляйте його безпосередньо в мережу. Розмістіть TLS і firewall перед ним

Саме на цьому етапі завершується більшість швидких інсталяцій і починається більшість інцидентів. Власний nginx Dify слухає порт 80 без шифрування на всіх інтерфейсах. Не допускайте передавання облікових даних адміністратора та ключів моделей через звичайний HTTP. Також не залишайте внутрішні сервіси доступними ззовні.

Захистіть сервер за допомогою firewall із політикою заборони за замовчуванням. Дозвольте лише SSH і вебтрафік:

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

Пам’ятайте, що firewall, який фільтрує лише IPv4, може залишити ті самі порти відкритими через IPv6. Це проблема з firewall для IPv6, через яку часто потерпають користувачі self-hosted систем. Переконайтеся, що фільтрація працює для обох стеків.

Для TLS найкраще прив’язати вебпорт Dify до loopback і розмістити перед ним reverse proxy із сертифікатом Let’s Encrypt. Тоді в публічному інтернеті буде доступний лише proxy, який працює через HTTPS. .env Dify дає змогу змінити відкритий порт. Налаштуйте прив’язування до 127.0.0.1 і вкажіть цю адресу для proxy. Рекомендації щодо захисту агентів у матеріалі безпечний запуск AI-агента на VPS також застосовні тут: залишайте компоненти на loopback, відкривайте лише необхідне та використовуйте один захищений зовнішній шлюз для TLS. Якщо інтерфейс інструмента потрібен лише вам і для нього взагалі не потрібен сертифікат, не використовуйте proxy. Підключайтеся через SSH tunnel, як у матеріалі self-hosting сканера безпеки open-kritt: його dashboard прив’язаний до loopback і передається на ваш laptop замість публікації. Якщо Dify потрібен усій команді, але не має бути доступним із публічного інтернету, використовуйте overlay network. Вона масштабує цю схему за межі одного laptop: публікація приватної підмережі сервера у вашому tailnet дає змогу кожному схваленому пристрою підключатися до builder за приватною адресою, тоді як firewall залишається закритим для всього, крім SSH. Якщо ви адмініструєте цей сервер через coding agent, а не вручну, заздалегідь визначте, які дії він може виконувати без нагляду. Перед передаванням йому ключів це особливо важливо, оскільки режим дозволів, у якому ви залишаєте Claude Code, визначає, чи зупиниться він для підтвердження перед перезаписом .env або перезапуском stack. Якщо одна сесія переглядає журнали контейнерів, а інша редагує конфігурацію proxy, ці дві сесії можуть передавати текст одна одній на тому самому сервері. Це зручніше, ніж щоразу копіювати вивід між терміналами під час перезапуску stack.

Крок 4: Регулярно встановлюйте оновлення

Dify швидко розвивається, а оновлення містять виправлення безпеки. Оновлення складається з отримання змін і перезапуску з каталогу docker:

git pull
docker compose pull
docker compose up -d

Перед переходом на нову основну версію прочитайте примітки до випуску, оскільки Dify іноді змінює схему .env між випусками, а нова змінна, яку ви не налаштували, може спричинити помилку запуску контейнера.

Крок 5: Створіть резервні копії даних, які неможливо відновити

У Dify є два типи даних, які неможливо замінити: база даних Postgres, що містить ваші застосунки, користувачів і налаштування, та volume із завантаженими документами й векторним індексом. Обидва типи даних зберігаються в Docker volumes у каталозі docker. Створюйте їхні snapshot за розкладом і копіюйте ці snapshot за межі сервера. У цих snapshot в одному файлі містяться всі model key та завантажені документи, тому шифруйте їх перед передаванням за межі сервера. Причина та сама, через яку резервна копія Vaultwarden виявляється слабкою ланкою навіть надійного password server. Model API key можна перевипустити, а застосунок, на створення якого ви витратили тиждень, — ні. Цей самий принцип стосується будь-якого агента, стан якого має зберегтися після заміни машини, на якій він працює: підтримання KiroCrew у стані постійно запущеного контейнера зводиться до створення snapshot пам’яті та розкладів, які інакше зникнуть після наступного перезавантаження.

Якщо ви хочете, щоб агенти, створені в цьому середовищі, працювали не лише з вашими наборами даних і шукали інформацію в live web, підключення їх до self-hosted SearXNG instance дає змогу зберігати потік пошукових запитів на обладнанні під вашим контролем. Однак перед увімкненням цього режиму варто ознайомитися з поверхнею prompt injection, яка при цьому виникає. Для більш автономного агента, що виконує код, дивіться self-hosting Agent Zero, а в матеріалі створення власного AI agent на VPS розглянуто основи, спільні для всіх цих рішень.

FAQ

Які системні вимоги потрібні для self-hosted Dify?

Dify працює як стек Docker Compose приблизно з шести контейнерів. Тому плануйте VPS щонайменше з 2 GB вільної RAM, бажано з 4 GB, кількома ядрами CPU і достатнім дисковим простором для завантажених документів та векторного індексу. Навантаження на пам’ять створюють база даних і векторне сховище, а не сам Dify.

Чи безпечно напряму відкривати Dify на порту 80?

Ні. Вбудований web server Dify працює через звичайний HTTP і обробляє вхід до адміністративної панелі та API keys моделей. Розмістіть перед ним reverse proxy із сертифікатом Let’s Encrypt, прив’яжіть власний порт Dify до loopback і дозвольте доступ до інтернету лише HTTPS proxy. Додайте firewall із політикою заборони за замовчуванням для IPv4 та IPv6.

Як оновити self-hosted Dify?

У каталозі docker виконайте git pull, а потім docker compose pull і docker compose up -d, щоб завантажити нові images і перезапустити сервіси. Спочатку прочитайте release notes, оскільки між версіями Dify іноді додає нові змінні .env, а відсутня змінна може завадити запуску контейнера.

Що потрібно зробити одразу після встановлення Dify?

Відкрийте /install і негайно створіть обліковий запис адміністратора. Поки цього облікового запису немає, будь-хто, хто має доступ до сторінки, може його створити. Налаштуйте обліковий запис одразу після того, як контейнери перейдуть у справний стан, і до відкриття firewall для зовнішнього доступу.