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

Що таке Dify і що саме ви запускаєте

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

Самостійне розгортання означає запуск великої кількості компонентів. Станом на October 2026 документований стек Dify за замовчуванням запускає 15 довгоживучих контейнерів і одноразове завдання, яке налаштовує права доступу до файлів і завершується. Сім із них — власні сервіси Dify: API server, websocket server, background worker, scheduler, web frontend, plugin daemon і agent backend. Ще вісім — залежності: база даних Postgres, кеш Redis, векторна база даних Weaviate, nginx як зовнішній шлюз, два code sandbox і два SSRF proxy. Docker Compose з’єднує їх усі, але це повноцінний стек, а документована мінімальна конфігурація Dify — 4 GiB RAM і два CPU cores. Якщо цей VPS також запускатиме інші сервіси, розраховуйте ресурси за виміряними значеннями, а не за заявленими мінімальними вимогами, оскільки фактичні мінімальні потреби PhotoPrism та Immich у RAM значно вищі за опубліковані мінімальні вимоги, а photo server, який працює на тому самому сервері, спочатку створить дефіцит ресурсів для бази даних і vector store Dify. Конкуренція за CPU працює так само: бібліотека Jellyfin, оформлена як відеомагазин 90s майже не потребує ресурсів під час звичайного перегляду обкладинок, але щойно хтось запускає transcode, worker Dify стає в чергу за ним. Перевага полягає в тому, що кількість контейнерів Dify не змінюється незалежно від кількості створених на його основі застосунків. Це передбачуваніше навантаження, ніж у OpenBot, де кожен AI coworker отримує власний контейнер і власний браузер, а кожен новий AI coworker знову підвищує мінімальний обсяг пам’яті.

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

Передумови

Потрібен VPS під керуванням Ubuntu 24.04 щонайменше з 4 GiB RAM і двома ядрами CPU, встановленим Docker із плагіном Docker Compose, а також користувач із sudo або членством у групі docker. Наведена нижче команда клонування також використовує git, curl і jq. Якщо Docker для вас новий, у матеріалі основи Docker Compose на VPS описано встановлення та основні команди, які передбачає цей посібник. Варто також мати доменне ім’я, спрямоване на сервер, оскільки перед Dify краще налаштувати TLS, а не використовувати голу IP-адресу.

Крок 1: Завантажте Dify та його Compose-файли

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

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

Якщо клонування завершується помилкою «Remote branch null», запит до GitHub API не повернув результату. Виберіть версію на сторінці релізів і вручну передайте її до --branch.

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

openssl rand -base64 42

Вставте його у SECRET_KEY і задайте надійне унікальне значення для кожного поля з паролем і ключем у файлі. Пароль Redis також указано у CELERY_BROKER_URL, тому змініть його і там. Інакше worker не зможе підключитися до Redis.

Крок 2: Запуск

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

docker compose up -d

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

docker compose ps

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

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

Саме на цьому етапі завершується більшість швидких інсталяцій і починається більшість інцидентів. Власний nginx Dify прослуховує порт 80 без шифрування на всіх інтерфейсах і також публікує порт 443. Не можна передавати облікові дані адміністратора та ключі моделей через звичайний 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. Це проблема з пропущеним IPv6 firewall, через яку часто виникають інциденти в self-hosted середовищах. Переконайтеся, що правила фільтрації діють для обох стеків. Також врахуйте, що порти, опубліковані Docker, обробляються власними правилами firewall Docker, а не правилами ufw. Стандартний стек публікує порт налагодження plugin daemon, 5003, на всіх інтерфейсах. Встановіть EXPOSE_PLUGIN_DEBUGGING_PORT у .env у значення 127.0.0.1:5003, якщо ви справді не плануєте налагоджувати plugins з іншої машини.

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

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

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

docker compose down
git fetch --tags
git checkout NEW_VERSION
docker compose pull
docker compose up -d

Міграції бази даних запускаються автоматично під час старту, і деякі з них неможливо скасувати. Саме тому резервну копію потрібно створити заздалегідь. Перед кожним оновленням читайте примітки до релізу, а не лише перед великими оновленнями: Dify зазначає, що кроки оновлення відрізняються між релізами. Наприклад, у примітках до версії 1.17.1 (вересень 2026 року) зазначено: якщо ви використовуєте вбудований Weaviate з наявними даними, не переходьте одразу на цю версію, а послідовно встановіть кожен мінорний реліз. Dify також змінює схему .env між релізами. Тому після переходу на новий тег порівняйте .env.example із вашим .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 вказано мінімум 4 GiB RAM і 2 ядра CPU, а також Docker Compose 2.24.0 або новішої версії. Ці мінімальні вимоги зумовлені розміром стандартного стека: станом на October 2026 він містить 15 довготривалих контейнерів і одне одноразове завдання ініціалізації. Додайте достатньо дискового простору для завантажених документів і векторного індексу. Якщо на сервері працюють інші сервіси, потрібно також більше пам’яті.

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

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

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

Створіть резервну копію бази даних. Потім із каталогу docker виконайте docker compose down, git fetch --tags, git checkout новий тег релізу, docker compose pull і docker compose up -d. Спочатку прочитайте release notes, оскільки кроки оновлення відрізняються між релізами, міграції можуть бути незворотними, а Dify іноді додає нові змінні .env. Відсутня змінна може перешкодити запуску контейнера.

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

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