Dify zelf hosten op een VPS met Docker Compose

Wat Dify is en waar u zich voor aanmeldt

Dify is een zelf-hostbaar platform voor het bouwen van applicaties op basis van large language models. U krijgt een webinterface voor het ontwerpen van chat-apps, agents en retrieval-pipelines, een API om deze vanuit uw eigen code aan te roepen, en één centrale plek voor het beheer van prompts, datasets en modelsleutels. Het is het type tool dat een klein team opzet zodat iedereen op een gedeelde, private basis bouwt, in plaats van API-sleutels te verspreiden over verschillende scripts. Als termen als agent, tool call en retrieval pipeline nog onduidelijk zijn, zal het vanaf nul doornemen van deze concepten ervoor zorgen dat de builder-schermen van Dify aanvoelen als bekende bedieningselementen in plaats van een muur met onbekende schakelaars.

Het zelf draaien van deze software betekent het beheren van veel bewegende onderdelen. Sinds oktober 2026 start de gedocumenteerde standaardstack van Dify 15 langlopende containers, plus een eenmalige taak die bestandsrechten instelt en vervolgens afsluit. Zeven daarvan zijn de eigen services van Dify: de API-server, een websocket-server, een background worker, een scheduler, de web-frontend, een plugin-daemon en een agent-backend. De andere acht zijn afhankelijkheden: een Postgres-database, een Redis-cache, een Weaviate-vectordatabase, een nginx-toegangspoort, twee code-sandboxes en twee SSRF-proxies. Docker Compose verbindt ze allemaal met elkaar, maar dit is een serieuze stack; het gedocumenteerde minimum van Dify is 4 GiB RAM en twee CPU-cores. Als die VPS ook andere taken moet uitvoeren, baseer de grootte dan op gemeten waarden in plaats van op geadverteerde specificaties, omdat de werkelijke RAM-ondergrenzen van PhotoPrism en Immich aanzienlijk hoger liggen dan hun gepubliceerde minima. Een fotoserver die de machine deelt, zal als eerste de database en vector-store van Dify uithongeren. CPU-contentie werkt op dezelfde manier: een Jellyfin-bibliotheek in de stijl van een videotheek uit de jaren 90 kost bijna niets om te serveren zolang er alleen door artwork wordt gebladerd, maar zodra iemand een transcode start, komen de workers van Dify in de wachtrij te staan. De troost is dat het aantal containers van Dify gelijk blijft, ongeacht hoeveel apps u erop bouwt. Dit is een voorspelbaarder kostenplaatje dan bij OpenBot, waarbij elke AI-collega een eigen container en browser krijgt en elke nieuwe medewerker de geheugenbehoefte verder verhoogt.

Omdat Dify uw model-API-sleutels en vaak ook privédocumenten bevat die u voor retrieval hebt geladen, moet u de server vanaf de eerste minuut als gevoelig beschouwen. Deze handleiding installeert de software en verhardt deze vervolgens op de manier waarop u elke service die geheimen bevat, zou beveiligen.

Vereisten

U heeft een VPS nodig met Ubuntu 24.04, minimaal 4 GiB RAM en twee CPU-cores. Zorg dat Docker met de Docker Compose-plugin is geïnstalleerd (Dify vereist Compose 2.24.0 of hoger) en dat u beschikt over een gebruiker met sudo-rechten of lidmaatschap van de docker-groep. Het onderstaande clone-commando maakt tevens gebruik van git, curl en jq. Als Docker nieuw voor u is, behandelt de basis van Docker Compose op een VPS de installatie en de kerncommando's waarvan deze handleiding uitgaat. Het is aanbevolen om een domeinnaam naar de server te laten wijzen, aangezien u TLS voor Dify wilt gebruiken in plaats van een kaal IP-adres.

Stap 1: Dify en de bijbehorende Compose-bestanden ophalen

Dify bewaart de Docker-configuratie in de hoofdrepository. Kloon de meest recente release, niet de development-branch, en ga naar de docker-directory:

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

Als het klonen mislukt met een "Remote branch null"-fout, dan heeft de GitHub API-opzoeking geen resultaat opgeleverd; kies een versie van de releases-pagina en geef deze handmatig door aan --branch.

Het bestand .env is de kernconfiguratie. Lees dit door voordat u begint. De waarden die als eerste van belang zijn, zijn de instellingen voor wachtwoorden en secrets: SECRET_KEY, het Postgres-wachtwoord en het Redis-wachtwoord. SECRET_KEY wordt leeg meegeleverd; als u dit zo laat, genereert Dify een sleutel en slaat deze op in de opslagdirectory. De wachtwoorden zijn een ander verhaal: het voorbeeldbestand stelt hetzelfde difyai123456 in voor zowel Postgres als Redis, en gebruikt vaste, publiekelijk bekende sleutels voor de code sandbox, de plugin daemon en Weaviate. Deze ongewijzigd laten is de meest voorkomende reden dat een zelfgehoste Dify-installatie wordt gecompromitteerd. Als u liever uw eigen secret key instelt, genereer er dan een:

openssl rand -base64 42

Plak deze in SECRET_KEY en stel een sterke, unieke waarde in voor elk wachtwoord- en sleutelveld in het bestand. Het Redis-wachtwoord staat ook in CELERY_BROKER_URL, dus wijzig het daar ook, anders kan de worker Redis niet bereiken.

Stap 2: Starten

Start de stack:

docker compose up -d

De eerste keer worden er diverse images gedownload en wordt de database geïnitialiseerd. Wacht daarom een minuut. Controleer of de containers gezond zijn:

docker compose ps

Elke langlopende service moet de status running hebben; de taak voor rechtenbeheer stopt zodra deze is voltooid. Dify biedt de webinterface standaard aan via een meegeleverde nginx-container op poort 80. Bij uw eerste bezoek aan http://YOUR_SERVER/install maakt u het beheerdersaccount aan. Doe dit direct, voordat iemand anders de poort kan bereiken. Zolang dat account niet bestaat, kan iedereen die de pagina laadt deze claimen en de eigenaar van uw instantie worden.

Stap 3: Stel het niet onbeveiligd bloot. Plaats TLS en een firewall voor de service

Dit is het punt waar de meeste snelle installaties stoppen en de meeste incidenten beginnen. De eigen Nginx van Dify luistert op poort 80, in platte tekst, op elke interface, en publiceert ook poort 443. U wilt niet dat uw inloggegevens voor beheerders en uw modelsleutels via onversleuteld HTTP worden verstuurd, en u wilt niet dat de interne services vanaf het internet bereikbaar zijn.

Beveilig de server met een firewall die standaard alles blokkeert (default-deny) en alleen SSH- en webverkeer toestaat:

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

Onthoud dat een firewall die alleen IPv4 afdekt, dezelfde poorten open kan laten staan op IPv6; dit is de IPv6-firewallkloof waar veel zelf-hosters in trappen. Controleer of beide stacks worden gefilterd. Wees u er ook van bewust dat poorten die Docker publiceert, worden beheerd door de eigen firewallregels van Docker, niet door ufw, en dat de standaard stack de debug-poort van de plugin-daemon, 5003, op elke interface publiceert. Stel EXPOSE_PLUGIN_DEBUGGING_PORT in .env in op 127.0.0.1:5003, tenzij u daadwerkelijk plugins vanaf een andere machine wilt debuggen.

Voor TLS is de schoonste methode om de webpoort van Dify te binden aan localhost en een reverse proxy met een Let's Encrypt-certificaat ervoor te plaatsen, zodat het enige dat op het publieke internet staat, de proxy is die HTTPS spreekt. Met .env van Dify kunt u de blootgestelde poort wijzigen; stel deze in om te binden op 127.0.0.1 en laat uw proxy daarnaar verwijzen. Doe hetzelfde voor EXPOSE_NGINX_SSL_PORT, omdat de Nginx van Dify standaard poort 443 claimt en uw proxy deze nodig heeft. De ideeën voor het beveiligen van agents in veilig draaien van een AI-agent op een VPS zijn hier ook van toepassing: houd de actieve onderdelen op localhost, stel alleen bloot wat publiek moet zijn en laat één beveiligde voordeur TLS afhandelen. Waar de interface van een tool alleen voor u is en helemaal geen certificaat nodig heeft, kunt u de proxy overslaan en deze bereiken via een SSH-tunnel, zoals het zelf-hosten van de open-kritt security scanner het dashboard aan localhost bindt en doorstuurt naar uw laptop in plaats van het te publiceren. Als een heel team Dify nodig heeft, maar het publieke internet niet, schaalt een overlay-netwerk dat idee voorbij één laptop: het adverteren van het private subnet van de server naar uw tailnet zorgt ervoor dat elk goedgekeurd apparaat de builder kan bereiken op een privaat adres, terwijl de firewall voor al het andere verkeer behalve SSH gesloten blijft. Als u deze server beheert via een coding agent in plaats van handmatig, bepaal dan hoeveel deze onbeheerd mag doen voordat u de sleutels overhandigt, want de permissiemodus waarin u Claude Code achterlaat bepaalt of deze stopt om toestemming te vragen voordat .env wordt herschreven of de stack wordt herstart. Als u uiteindelijk in de ene sessie containerlogs bekijkt terwijl u in een andere de proxy-configuratie bewerkt, kunnen die twee sessies tekst naar elkaar sturen op dezelfde machine, wat efficiënter is dan telkens uitvoer tussen terminals kopiëren wanneer u de stack herstart.

Stap 4: Houd de software up-to-date

Dify ontwikkelt zich snel en updates bevatten vaak beveiligingspatches. Omdat u een release-tag heeft gekloond, betekent updaten dat u de volgende tag moet uitchecken in plaats van een branch te pullen. Maak eerst een back-up van de database en voer daarna vanuit de map docker het volgende uit:

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

Database-migraties worden automatisch uitgevoerd bij het opstarten en sommige hiervan kunnen niet ongedaan worden gemaakt; daarom is de back-up noodzakelijk. Lees voor elke upgrade de release notes, niet alleen bij grote versies: Dify geeft aan dat de upgradestappen per release verschillen. De notes van 1.17.1 (september 2026) adviseren bijvoorbeeld gebruikers die de meegeleverde Weaviate met bestaande data draaien, om niet direct naar die versie te springen, maar elke minor release stapsgewijs te doorlopen. Dify wijzigt tussen releases ook het .env-schema. Vergelijk daarom na het uitchecken van een nieuwe tag .env.example met uw .env en voer uw wijzigingen door. Een nieuwe variabele die u niet heeft ingesteld, kan er namelijk voor zorgen dat een container niet start.

Stap 5: Maak back-ups van wat u niet opnieuw kunt genereren

Twee zaken op een Dify-server zijn onvervangbaar: de Postgres-database, die uw apps, gebruikers en instellingen bevat, en het volume waarin geüploade documenten en de vectorindex zijn opgeslagen. Beide bevinden zich in Docker-volumes in de map docker. Maak volgens een vast schema snapshots en kopieer deze snapshots van de server af. Deze snapshots bevatten elke modelsleutel en elk geüpload document in één enkel bestand; versleutel ze daarom voordat ze de server verlaten, om dezelfde reden dat een Vaultwarden-back-up het zwakke punt blijkt van een verder solide wachtwoordserver. Een model-API-sleutel kan opnieuw worden uitgegeven; de app waar u een week aan heeft gebouwd niet. Dezelfde redenering geldt voor elke agent waarvan de status langer moet meegaan dan de machine waarop deze draait: KiroCrew als een altijd actieve container laten draaien komt neer op het maken van snapshots van het geheugen en de schema's die anders bij de volgende herstart zouden verdwijnen.

Wanneer u wilt dat de agents die u hier bouwt verder kijken dan uw eigen datasets en het live internet doorzoeken, zorgt het koppelen aan een zelfgehoste SearXNG-instantie ervoor dat de zoekopdrachten op hardware blijven die u beheert, al is het de moeite waard om u in te lezen in het risico op prompt-injectie voordat u dit inschakelt. Voor een meer autonome agent die code kan uitvoeren, zie Agent Zero zelf hosten, en uw eigen AI-agent bouwen op een VPS behandelt de fundamenten die aan al deze oplossingen ten grondslag liggen.

FAQ

Wat zijn de systeemvereisten voor het zelf hosten van Dify?

Dify vereist minimaal 4 GiB RAM en twee CPU-cores, evenals Docker Compose 2.24.0 of nieuwer. Deze ondergrens is gebaseerd op de omvang van de standaardstack: 15 continu actieve containers plus een eenmalige initialisatietaak, per oktober 2026. Zorg voor voldoende schijfruimte voor uw geüploade documenten en de vectorindex, en voeg extra geheugen toe als er andere services op dezelfde server draaien.

Is het veilig om Dify rechtstreeks op poort 80 bloot te stellen?

Nee. De meegeleverde webserver van Dify luistert op onversleuteld HTTP en fungeert als toegangspunt voor uw beheerdersaccount en uw model-API-keys. Plaats een reverse proxy met een Let's Encrypt-certificaat voor de applicatie, bind de poort van Dify aan localhost en zorg dat alleen de HTTPS-proxy bereikbaar is vanaf het internet. Combineer dit met een firewall die standaard al het verkeer blokkeert (default-deny) voor zowel IPv4 als IPv6.

Hoe update ik een zelfgehoste Dify-installatie?

Maak een back-up van de database, ga naar de map docker en voer docker compose down, git fetch --tags, git checkout de nieuwe release-tag, docker compose pull en docker compose up -d uit. Lees eerst de release notes, aangezien de stappen voor upgrades per release kunnen verschillen, migraties onomkeerbaar kunnen zijn en Dify soms nieuwe .env-variabelen toevoegt; een ontbrekende variabele kan ervoor zorgen dat een container niet opstart.

Wat is het eerste dat ik moet doen na het installeren van Dify?

Bezoek /install en maak direct het beheerdersaccount aan. Zolang dit account niet bestaat, kan iedereen die de pagina bereikt het account claimen. Configureer dit zodra de containers correct functioneren en voordat u de firewall openstelt voor het internet.