Dify: jak zainstalować na własnym VPS przez Docker Compose

Czym jest Dify i co uruchamiasz

Dify to platforma z możliwością samodzielnego hostowania, służąca do budowania aplikacji w oparciu o duże modele językowe. Otrzymujesz interfejs WWW do projektowania aplikacji czatowych, agentów i potoków pobierania danych (retrieval pipelines), API do wywoływania ich z własnego kodu oraz centralne miejsce do zarządzania promptami, zbiorami danych i kluczami modeli. Jest to narzędzie, które mały zespół wdraża, aby wszyscy pracowali na jednej, współdzielonej i prywatnej bazie, zamiast rozpraszać klucze API w różnych skryptach. Jeśli pojęcia takie jak agent, wywołanie narzędzia (tool call) czy potok pobierania danych są jeszcze niejasne, przeanalizowanie tych koncepcji od podstaw sprawi, że ekrany kreatora Dify staną się zrozumiałe, zamiast przypominać ścianę nieopisanych przełączników.

Samodzielne uruchomienie oznacza obsługę wielu współpracujących elementów. Według stanu na październik 2026, udokumentowany domyślny stos Dify uruchamia 15 długo działających kontenerów oraz jedno zadanie jednorazowe, które ustawia uprawnienia plików i kończy działanie. Siedem z nich to własne usługi Dify: serwer API, serwer websocket, proces roboczy w tle (background worker), harmonogram, frontend WWW, demon wtyczek oraz backend agenta. Pozostałe osiem to zależności: baza danych Postgres, pamięć podręczna Redis, wektorowa baza danych Weaviate, brama wejściowa nginx, dwie piaskownice kodu oraz dwa proxy SSRF. Docker Compose łączy je wszystkie w całość, ale jest to pełnoprawny stos, a udokumentowane minimum dla Dify to 4 GiB pamięci RAM i dwa rdzenie CPU. Jeśli na tym samym VPS-ie mają działać inne usługi, dobierz zasoby na podstawie zmierzonych wartości, a nie deklarowanych, ponieważ rzeczywiste minimalne zapotrzebowanie na pamięć RAM w PhotoPrism i Immich znacznie przewyższa wartości publikowane, a serwer zdjęć współdzielący maszynę w pierwszej kolejności doprowadzi do braku zasobów dla bazy danych i magazynu wektorowego Dify. Rywalizacja o zasoby CPU działa podobnie: biblioteka Jellyfin wystylizowana na wypożyczalnię kaset wideo z lat 90. prawie nie zużywa zasobów podczas przeglądania okładek, ale w momencie rozpoczęcia transkodowania, kolejki procesów roboczych Dify zostają spowolnione. Pocieszeniem jest fakt, że liczba kontenerów Dify pozostaje stała niezależnie od liczby zbudowanych aplikacji, co jest bardziej przewidywalnym kosztem niż w przypadku OpenBot, gdzie każdy współpracownik AI otrzymuje własny kontener i własną przeglądarkę, a każde nowe wdrożenie podnosi bazowe zużycie pamięci.

Ponieważ Dify przechowuje Twoje klucze API do modeli oraz często prywatne dokumenty wgrane w celu pobierania danych, traktuj maszynę, na której działa, jako wrażliwą od pierwszej minuty. Ten przewodnik przeprowadza instalację, a następnie zabezpiecza system w sposób, w jaki należy zabezpieczać każdą usługę przechowującą sekrety.

Wymagania wstępne

Wymagany jest serwer VPS z systemem Ubuntu 24.04, posiadający co najmniej 4 GiB pamięci RAM oraz dwa rdzenie procesora. Niezbędne jest zainstalowanie Docker wraz z wtyczką Docker Compose (Dify wymaga wersji Compose 2.24.0 lub nowszej) oraz użytkownik z uprawnieniami sudo lub członkostwem w grupie docker. Poniższe polecenie klonowania wykorzystuje również git, curl oraz jq. Jeśli Docker jest nowym zagadnieniem, podstawy Docker Compose na VPS zawierają informacje o instalacji oraz kluczowe polecenia, na których opiera się ten przewodnik. Warto posiadać domenę skierowaną na serwer, ponieważ zaleca się stosowanie TLS przed Dify zamiast korzystania z samego adresu IP.

Krok 1: Pobranie Dify i plików Compose

Dify przechowuje konfigurację Docker w głównym repozytorium. Należy sklonować najnowszą wersję (release), a nie gałąź deweloperską, a następnie przejść do katalogu 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

Jeśli klonowanie kończy się błędem "Remote branch null", oznacza to, że wyszukiwanie przez GitHub API nie zwróciło wyników; należy wybrać wersję ze strony wydań i przekazać ją ręcznie do --branch.

Plik .env stanowi główną konfigurację. Należy zapoznać się z jego treścią przed rozpoczęciem jakichkolwiek działań. Wartościami, które mają kluczowe znaczenie na początku, są te określające hasła i klucze sekretne: SECRET_KEY, hasło do Postgres oraz hasło do Redis. Pole SECRET_KEY jest domyślnie puste; jeśli pozostanie w tym stanie, Dify wygeneruje klucz automatycznie i zapisze go w swoim katalogu danych. Kwestia haseł wygląda inaczej: przykładowy plik ustawia to samo difyai123456 zarówno dla Postgres, jak i Redis, a także stałe, publicznie znane klucze dla piaskownicy kodu (code sandbox), demona wtyczek oraz Weaviate. Pozostawienie tych wartości w postaci dostarczonej w pliku jest najczęstszą przyczyną, dla której samodzielnie hostowana instancja Dify zostaje przejęta. Jeśli użytkownik woli ustawić własny klucz sekretny, może go wygenerować:

openssl rand -base64 42

Należy wkleić wygenerowany ciąg do SECRET_KEY oraz ustawić silne, unikalne wartości dla każdego pola hasła i klucza w pliku. Hasło do Redis występuje również wewnątrz CELERY_BROKER_URL, dlatego należy je zmienić także w tym miejscu, w przeciwnym razie proces worker nie uzyska połączenia z Redis.

Krok 2: Uruchomienie

Uruchom stos:

docker compose up -d

Pierwsze uruchomienie pobiera kilka obrazów i inicjuje bazę danych, więc należy odczekać około minuty. Sprawdź, czy kontenery działają poprawnie:

docker compose ps

Każda usługa działająca w tle powinna mieć status running; zadanie jednorazowego nadawania uprawnień kończy działanie po wykonaniu swojego zadania. Dify udostępnia interfejs WWW przez wbudowany kontener nginx, domyślnie na porcie 80. Podczas pierwszej wizyty pod adresem http://YOUR_SERVER/install należy utworzyć konto administratora. Wykonaj tę czynność niezwłocznie, zanim ktokolwiek inny uzyska dostęp do portu, ponieważ do momentu utworzenia tego konta każda osoba, która załaduje stronę, może przejąć instancję i uzyskać do niej pełne uprawnienia.

Krok 3: Nie wystawiaj usługi bezpośrednio. Zastosuj TLS i firewall

W tym miejscu kończy się większość szybkich instalacji i zaczyna większość incydentów. Wbudowany w Dify serwer nginx nasłuchuje na porcie 80, przesyłając dane otwartym tekstem na każdym interfejsie, a także publikuje port 443. Dane logowania administratora oraz klucze modeli nie powinny być przesyłane przez zwykły HTTP, a usługi wewnętrzne nie powinny być dostępne z zewnątrz.

Zabezpiecz serwer za pomocą firewalla z domyślną polityką blokowania (default-deny), zezwalając jedynie na ruch SSH oraz webowy:

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

Pamiętaj, że firewall obsługujący tylko IPv4 może pozostawić te same porty otwarte w protokole IPv6, co tworzy lukę w firewallu IPv6, na którą naraża się wielu użytkowników hostujących usługi samodzielnie. Upewnij się, że oba stosy są filtrowane. Pamiętaj również, że porty publikowane przez Docker są obsługiwane przez własne reguły firewalla Dockera, a nie przez ufw, a domyślny stos publikuje port debugowania wtyczek, 5003, na każdym interfejsie. Ustaw EXPOSE_PLUGIN_DEBUGGING_PORT w .env na 127.0.0.1:5003, chyba że faktycznie zamierzasz debugować wtyczki z innej maszyny.

W przypadku TLS najczystszym rozwiązaniem jest powiązanie portu webowego Dify z interfejsem loopback i uruchomienie przed nim reverse proxy z certyfikatem Let's Encrypt. Dzięki temu jedynym elementem widocznym w publicznym Internecie jest proxy obsługujące HTTPS. Zmienna .env w Dify pozwala na zmianę wystawionego portu; ustaw ją tak, aby powiązać usługę z 127.0.0.1 i skieruj na nią swoje proxy. Zrób to samo dla EXPOSE_NGINX_SSL_PORT, ponieważ domyślny nginx w Dify zajmuje port 443, który jest niezbędny dla Twojego proxy. Zasady utwardzania agentów opisane w bezpiecznym uruchamianiu agenta AI na VPS mają tu zastosowanie: utrzymuj ruchome elementy na loopbacku, wystawiaj tylko to, co musi być publiczne, i pozwól jednej, zabezpieczonej bramie obsługiwać TLS. Jeśli interfejs narzędzia jest przeznaczony tylko dla Ciebie i nie wymaga certyfikatu, pomiń proxy i uzyskaj do niego dostęp przez tunel SSH, tak jak samodzielne hostowanie skanera bezpieczeństwa open-kritt pozwala na powiązanie panelu z loopbackiem i przekierowanie go na laptopa zamiast publikowania w sieci. Jeśli Dify jest potrzebne całemu zespołowi, ale nie publicznemu Internetowi, sieć typu overlay rozszerza tę koncepcję poza jeden laptop: udostępnienie prywatnej podsieci serwera w Twojej sieci tailnet pozwala każdemu autoryzowanemu urządzeniu na dostęp do buildera przez adres prywatny, podczas gdy firewall pozostaje zamknięty na wszystko poza SSH. Jeśli administrujesz serwerem za pomocą agenta kodującego, a nie ręcznie, ustal zakres jego samodzielnych działań, zanim przekażesz mu uprawnienia, ponieważ tryb uprawnień, w którym pozostawisz Claude Code decyduje o tym, czy agent zapyta o zgodę przed nadpisaniem .env lub restartem stosu. Jeśli podczas pracy jedna sesja śledzi logi kontenera, a druga edytuje konfigurację proxy, obie sesje mogą wymieniać tekst między sobą na tej samej maszynie, co jest wygodniejsze niż kopiowanie danych między terminalami przy każdym restarcie stosu.

Krok 4: Utrzymywanie aktualności

Projekt Dify rozwija się dynamicznie, a aktualizacje zawierają poprawki bezpieczeństwa. Ponieważ sklonowano konkretny tag wydania, aktualizacja polega na przełączeniu się na kolejny tag, a nie na pobieraniu zmian z gałęzi. Najpierw należy wykonać kopię zapasową bazy danych, a następnie z katalogu docker wykonać:

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

Migracje bazy danych uruchamiają się automatycznie podczas startu i niektórych z nich nie można cofnąć, dlatego kopia zapasowa jest niezbędna. Przed każdą aktualizacją, nie tylko główną, należy zapoznać się z informacjami o wydaniu. Dify zaznacza, że kroki aktualizacji różnią się między wersjami. Na przykład notatki do wersji 1.17.1 (wrzesień 2026) zalecają użytkownikom korzystającym z dołączonego Weaviate z istniejącymi danymi, aby nie przechodzili bezpośrednio do tej wersji, lecz instalowali po kolei każde wydanie podrzędne. Dify zmienia również schemat .env pomiędzy wydaniami, dlatego po przełączeniu na nowy tag należy porównać .env.example z własnym plikiem .env i przenieść zmiany. Brak ustawienia nowej zmiennej może spowodować, że kontener nie zostanie uruchomiony.

Krok 5: Tworzenie kopii zapasowych danych niemożliwych do odtworzenia

Dwa elementy na serwerze Dify są niezastąpione: baza danych Postgres, która przechowuje aplikacje, użytkowników i ustawienia, oraz wolumen przechowujący przesłane dokumenty i indeks wektorowy. Oba znajdują się w wolumenach Docker w katalogu docker. Należy tworzyć ich migawki zgodnie z harmonogramem i kopiować je poza serwer. Migawki te zawierają wszystkie klucze modeli oraz przesłane dokumenty w jednym pliku, dlatego należy je zaszyfrować przed wysłaniem poza serwer z tego samego powodu, dla którego kopia zapasowa Vaultwarden okazuje się słabym punktem bezpiecznego serwera haseł. Klucz API modelu można wygenerować ponownie; aplikacji, której budowa zajęła tydzień, nie da się odtworzyć. To samo rozumowanie dotyczy każdego agenta, którego stan musi przetrwać restart maszyny: utrzymanie KiroCrew jako stale działającego kontenera sprowadza się do tworzenia migawek pamięci i harmonogramów, które w przeciwnym razie zniknęłyby przy następnym restarcie.

Jeśli agenci budowani w tym środowisku mają wykraczać poza własne zbiory danych i przeszukiwać sieć, skierowanie ich na własną instancję SearXNG pozwala zachować strumień zapytań na kontrolowanym sprzęcie, choć przed uruchomieniem warto zapoznać się z podatnością na prompt injection. W przypadku bardziej autonomicznego agenta wykonującego kod, zobacz samodzielne hostowanie Agent Zero, a budowa własnego agenta AI na VPS omawia fundamenty wszystkich tych rozwiązań.

FAQ

Jakie są wymagania systemowe do samodzielnego hostowania Dify?

Dokumentacja Dify określa minimum 4 GiB pamięci RAM i dwa rdzenie procesora, a także Docker Compose w wersji 2.24.0 lub nowszej. Ten próg wynika z rozmiaru domyślnego stosu: 15 działających w tle kontenerów oraz jednorazowego zadania inicjalizacji, według stanu na październik 2026. Należy zapewnić odpowiednią ilość miejsca na dysku dla przesyłanych dokumentów i indeksu wektorowego, a także zwiększyć ilość pamięci, jeśli na serwerze działają inne usługi.

Czy bezpieczne jest wystawienie Dify bezpośrednio na porcie 80?

Nie. Wbudowany serwer WWW Dify nasłuchuje na zwykłym HTTP, obsługując logowanie administratora oraz klucze API modeli. Należy umieścić przed nim reverse proxy z certyfikatem Let’s Encrypt, powiązać port Dify z interfejsem loopback i udostępnić w Internecie wyłącznie proxy HTTPS. Należy to połączyć z domyślnie blokującą zaporą sieciową, obejmującą zarówno IPv4, jak i IPv6.

Jak zaktualizować samodzielnie hostowane Dify?

Należy wykonać kopię zapasową bazy danych, a następnie z katalogu docker uruchomić docker compose down, git fetch --tags, git checkout z nowym tagiem wydania, docker compose pull oraz docker compose up -d. Przed aktualizacją należy zapoznać się z informacjami o wydaniu, ponieważ kroki aktualizacji różnią się między wersjami, migracje mogą być nieodwracalne, a Dify czasami dodaje nowe zmienne .env, których brak może uniemożliwić uruchomienie kontenera.

Co należy zrobić w pierwszej kolejności po instalacji Dify?

Należy odwiedzić /install i niezwłocznie utworzyć konto administratora. Dopóki to konto nie istnieje, każdy, kto uzyska dostęp do strony, może je przejąć. Należy skonfigurować je w momencie, gdy kontenery są w stanie gotowości, jeszcze przed otwarciem zapory sieciowej na świat.