Als je de managed PaaS al achter je hebt gelaten, is je VPS geprovisioned, is de SSH-sleutel toegevoegd en knippert je terminalcursor op de installatieregel. De enige vraag die overblijft: draai je curl ... | bash voor Coolify, of voor Dokploy?
Beide tools installeer je met één commando. Beide geven je Git-push-deployments, automatische SSL, een web-UI en een reverse proxy bovenop Docker. De interessante verschillen zijn die welke in productie zichtbaar worden: hoe elk een standaard docker-compose.yml, afhandelt, wat er gebeurt tijdens een deploy en hoe elk project reageerde op het nieuws dat deze vergelijking in 2026 opnieuw vormgaf. Twee nieuwsfeiten dragen hier het meeste gewicht: de Coolify CVE-bekendmakingen van januari 2026 en de herstructurering van de Dokploy-licentie van diezelfde maand.
Dit artikel koppelt elke tool aan een specifieke use case in plaats van een winnaar te kronen. Aan het eind weet je hopelijk welke past bij jouw workflow.
Samenvatting
- Coolify is ouder met het grotere ecosysteem (~55k GitHub-sterren, 300+ one-click servicetemplates), zwaarder in rust, overal Apache 2.0, zonder betaald niveau aan de zelf-gehoste kant.
- Dokploy is jonger (~34k sterren), lichter in rust, Apache 2.0-kern plus een aparte Source Available License die toekomstige betaalde features (SSO, RBAC, audit logs, white-labeling) afschermt.
- Coolify kan vandaag geen zero-downtime-deployments via Docker Compose; alleen via Dockerfile, Nixpacks of single-image-deploys. Dokploy levert Docker Swarm als first-class modus; de Swarm van Coolify is gelabeld als experimenteel.
- De Coolify-CVE's van januari 2026 zijn gepatcht in v4.0.0 (April 27, 2026). Werk Coolify bij en stel het dashboard niet publiek bloot.
Wanneer geen van beide tools het juiste antwoord is
Zowel Coolify als Dokploy hebben voor sommige setups de verkeerde vorm. Drie alternatieven die het kort vermelden waard zijn:
- Kamal (van 37signals): voor teams met een of twee apps die geen UI willen; gewoon
kamal deployvanaf je laptop. Eenvoudiger dan Coolify of Dokploy met een ruime marge en de juiste keuze als je geen dashboard wilt. - Dokku: het klassieke, Git-push, single-server-model. Ouder, kleinere scope, zeer stabiel. Het originele "Heroku op één VPS".
- GitHub Actions + Docker Compose op een kale VPS: de kleinst mogelijke stack. Geen orchestratie-UI, maar ook geen orchestratie-overhead. Goed voor een enkele app waar de deployflow
docker compose pull && docker compose up -dwordt getriggerd vanuit CI.
Als jouw vorm één app op één server is, zijn zowel Coolify als Dokploy waarschijnlijk overkill; probeer eerst een van bovenstaande. Als je meerdere apps, meerdere databases of een team met niet-technische leden hebt die een UI nodig hebben om dingen te bedienen, dan is de keuze tussen Coolify en Dokploy de juiste om te maken. Voor een bredere verkenning van opties in deze categorie, zie onze overzicht van zelfgehoste cloudplatformen met een web-UI.
Coolify en Dokploy in één oogopslag
Coolify v4.0.0 stable verscheen op April 27, 2026, na een lange betacyclus. Dokploy zit op v0.29.4 per May 11, 2026. Beide zijn open-source zelf-gehoste PaaS-projecten in de Heroku/Render/Vercel-alternatiefruimte, beide verpakken Docker met een UI, een reverse proxy met HTTPS by default (Traefik) en Git-gebaseerde deploys.
| Functie | Coolify | Dokploy |
|---|---|---|
| Nieuwste stabiele release | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| Licentie | Apache 2.0 | Apache 2.0-kern + Source Available voor betaalde features |
| Tech stack | PHP / Laravel | TypeScript / Node.js |
| GitHub-sterren | ~55,000 | ~34,000 |
| Minimaal RAM (officieel) | 2 GB | 2 GB |
| Minimale CPU (officieel) | 2 kernen | niet gespecificeerd |
| Idle-RAM (door community gerapporteerd) | 500 MB – 1.2 GB | 300 – 400 MB |
| Docker Compose zero-downtime | Niet ondersteund (alleen Dockerfile/Nixpacks) | Standaard Compose-afhandeling |
| Multi-server-clustering | Docker Swarm (experimenteel) | Docker Swarm (native) |
| ARM64-ondersteuning | Ja (incl. Raspberry Pi OS) | Niet vermeld in docs |
| Buildsystemen | Nixpacks, Dockerfile, Docker image | Nixpacks, Dockerfile, Docker image, Heroku Buildpacks, Paketo, Railpack |
| Omgekeerde proxy | Traefik | Traefik |
| Scope zelf-gehoste monitoring | Ingebouwde metrics + log viewer | Basis-resourcemetrics + AI-analyse van log-/buildfouten (v0.29.0+) |
Ons advies: kies Dokploy als je lagere idle-overhead, native multi-server-ondersteuning en standaard Docker Compose-afhandeling zonder platformspecifiek geknutsel wilt. Kies Coolify als je de grotere one-click-app-bibliotheek, ARM64/Raspberry Pi-ondersteuning of pure Apache 2.0 zonder toekomstig betaald niveau in het verschiet wilt.
Resource-footprint en VPS-sizing
Een zelf-gehoste PaaS kan je de kosten van Heroku besparen. Als de orchestratielaag in rust 1,5 GB van je 2 GB VPS opslokt, blijft er niets over om op te deployen. Dus de eerste praktische vraag op een kleine server is: hoeveel kost elke tool je voordat je ook maar één app hebt gedeployed?
Het idle-RAM-gebruik van Coolify hangt af van welke monitoring is ingeschakeld, met een baseline-CPU-footprint van 5–7% die piekt wanneer de metrics-scrape draait. Coolify's eigen documentatie hanteert een representatieve productieworkload van 8 GB RAM, 4 cores en 150 GB opslag waarop 3 Node.js-apps, 4 statische sites en een paar databases draaien. Dat is een redelijke sizing-referentie als jouw stack er vergelijkbaar uitziet.
Dokploy daarentegen draait veel lichter, ruim onder de 2% CPU wanneer er niets wordt gedeployed.
A LogRocket-productieverslag waarin beide tools naast elkaar werden gedraaid, kwam tot dezelfde richtinggevende conclusie: een docker stop && docker start op een Dokploy-app triggert geen volledige rebuild, terwijl dezelfde handeling op Coolify dat wel doet. Dat alleen al verschuift de steady-state-kosten in het voordeel van Dokploy, vooral op kleinere VPS-plannen waar rebuild-stormen je CPU-budget opeten.
Voor sizing is dit de VPS-setup die ik zou aanraden:
- Coolify, lichte workload: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, productiereferentie-workload: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, lichte workload: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, productie-speelruimte: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
Pro-tip: het idle-RAM van Coolify schaalt mee met je monitoring-config. Als je krap in het geheugen zit, verlaag dan het metrics-scrape-interval (of schakel de ingebouwde monitoring helemaal uit als je elders al Prometheus/Grafana draait) voordat je een grotere server inzet.
De deploy-realiteit: Docker Compose, Dockerfile en zero-downtime
De meeste teams komen bij een van deze tools aan met een bestaande docker-compose.yml en een verwachting: plak het bestand, klik op deploy, zie de app verschijnen. Hoe elk platform standaard Compose afhandelt, en wat er gebeurt met lopende requests tijdens de volgende deploy, is waar het praktische onderscheid zichtbaar wordt.
Coolify ondersteunt Docker Compose, Dockerfile, Nixpacks (auto-detectie uit projectbestanden) en directe Docker image-deployments. Er is echter een addertje onder het gras dat het waard is om expliciet te benoemen: zero-downtime-deployments (rolling updates, blue/green) werken in Coolify alleen via Dockerfile, Nixpacks of single-image-deploys. Ze werken niet via Docker Compose. Een Coolify-maintainer bevestigde in een GitHub-discussie dat "for compose based deployments, all containers are stopped before starting the new ones, there is no rolling update for compose based deployments currently." Rolling-ondersteuning voor Compose staat op de roadmap voor v5; v4 krijgt het niet. De workaround die de maintainer voorstelt is om een Compose-stack op te splitsen in afzonderlijke Coolify-services, wat een niet-triviale migratie is als je Compose-bestand echte relaties tussen services uitdrukt.
De consequentie voor de gebruiker komt naar voren in een Hacker News-thread over Coolify, waar één operator het botweg stelde: "any pending request when you update an app is simply killed." Dat klopt vandaag voor Compose-deploys.
De Compose-laag van Coolify voegt ook toe wat het project "magic variables" noemt. Dat betekent automatische injectie van helper-images, network-rewrites en environment-overrides. De bedoeling is efficiënter te zijn; het neveneffect is dat een docker-compose.yml die soepel draait op je laptop soms aanpassing nodig heeft om soepel te draaien op Coolify. Dezelfde Hacker News-thread brengt een representatief geval aan het licht: "Added 8 variables inside docker-compose, only 7 get recognized." Als je Compose-stack klein en standaard is, loop je hier misschien niet tegenaan. Is hij groot of ongebruikelijk, dan wel.
De houding van Dokploy is anders. Het hands-on-verslag van LogRocket constateerde dat Dokploy "can deploy an existing docker-compose.yml with little to no modification" en dicht bij Dockers native label-gebaseerde routingmodel blijft. Hetzelfde verslag merkt op dat container stop/start in Dokploy geen volledige rebuild triggert, terwijl dezelfde actie op Coolify dat wel doet. Dit is een richtinggevend signaal over runtimegedrag, eerder dan een formele "zero-downtime-garantie" uit de Dokploy-docs, maar het strookt met wat zelf-hosters melden op kleinere VPS-instances.
Dokploy ondersteunt ook Heroku Buildpacks, Paketo Buildpacks en Railpack naast Nixpacks en Dockerfile. Voor teams die van Heroku komen met heroku.yml of buildpack-gebaseerde workflows is dat de weg van de minste weerstand.
Belangrijkste les van deze sectie: als je bestaande services een echte Docker Compose-stack zijn, zal Coolify je dwingen je deploymentstrategie te herstructureren of korte downtime per push te accepteren. Dokploy niet.
Beveiliging: de Coolify-CVE-bekendmakingen van januari 2026
Ik lees het bredere verhaal zo: Coolify is vandaag veilig om te draaien als je het bijgewerkt houdt en je het dashboard niet blootstelt aan het publieke internet. De bekendmaking diskwalificeert het project niet. Verantwoorde disclosure werd gevolgd en de patches gingen eruit. Wat het wel onthult is dat het aanvalsoppervlak dat beschikbaar was voor een laag-geprivilegieerde geauthenticeerde gebruiker breder was dan het had moeten zijn. Dat is een ontwerples voor het project en een operationele les voor de operator: verscherp het blootstellingsmodel nu.
Pro-tip: behandel je Coolify-dashboard ook na het patchen als SSH. Bind het aan een privénetwerk, zet het achter een VPN of plaats het achter Tailscale. Stel poort 8000 niet bloot aan het publieke internet alleen omdat het installatiescript dat makkelijk maakt.
Dokploy is ook niet vrijgesteld van dit soort problemen. De release notes van v0.29.3 erkennen een beveiligingskwetsbaarheid die in Dokploy is geïdentificeerd en leveren een beveiligingspatchscript dat je geacht wordt naast de upgrade uit te voeren. Kleiner oppervlak, kortere projecthistorie, maar dezelfde operationele discipline geldt: werk bij op de dag dat patches uitkomen, laat het dashboard niet op het publieke internet staan.
Belangrijkste les van deze sectie: het CVE-verhaal is een gele vlag voor de operationele praktijk van Coolify, geen rode vlag tegen het project, maar het legt de lat hoger voor update-discipline en voor hoe je het dashboard blootstelt.
Licenties: wat gratis is en wat niet
De licentie van Dokploy is geherstructureerd op January 21, 2026. Dit is wat er veranderde en wat het betekent voor zelf-hosters.
Dokploy is nu standaard Apache 2.0 voor de kern, ter vervanging van de eerdere niet-standaard aangepaste Apache 2.0 die gebruikers in verwarring bracht over wat open source was en wat niet. Een aparte Dokploy Source Available License beheert nu code in proprietary/ directory's: zichtbare broncode, betaald voor productiegebruik. De features die volgens Dokploy achter die licentie zullen leven:
- Single Sign-On (SSO/SAML) en geavanceerde toegangscontroles
- Eigen branding en white-labeling
- Hoge beschikbaarheid, auto-scaling en disaster recovery
- Geavanceerde monitoring, integraties en compliance-features
Het project heeft zich expliciet verbonden om nooit een bestaande open-source-feature naar het betaalde niveau te verplaatsen; toekomstige betaalde functionaliteit is gericht op organisaties die enterprise-lijm nodig hebben. 2FA zit vandaag al achter het Startup-niveau op de prijspagina van Dokploy.
De situatie van Coolify is rechttoe rechtaan. Het project is Apache 2.0 op GitHub; elke feature in de zelf-gehoste versie is gratis. Er is een Coolify Cloud-aanbod voor teams die willen dat de maintainer het host, maar de zelf-gehoste versie is een compleet product zonder feature-gates en zonder upgradepad naar een betaald niveau dat je vandaag niet hebt.
Mijn conclusie: voor solo-developers en kleine teams die zelf-hosten op hun eigen VPS is Dokploy functioneel gratis en zal dat blijven. Voor een organisatie die uiteindelijk SSO, fijnmazige RBAC, audit logs of white-labeling nodig heeft, zal Dokploy je uiteindelijk naar een betaald niveau duwen. Coolify niet, want Coolify heeft dat niveau niet op de roadmap.
Een verduidelijking over bronnen heen die het waard is om te maken: de zelf-gehoste build van Dokploy bevat wél basis-resourcemetrics (CPU, geheugen, opslag, netwerk), en v0.29.0 voegde AI-gestuurde analyse van log- en buildfoutentoe. Het monitoringsysteem van Dokploy is alleen in de cloud voor de geavanceerdere monitoringfeatures. De monitoring draait echter nog steeds lokaal op een zelf-gehoste installatie voor basis-resourcemetrics vóór containers.
Multi-server en clustering: realiteit versus marketing
Vroeg of laat is één VPS niet genoeg, en beide projecten promoten multi-server-ondersteuning prominent op hun landingspagina's. De realiteit in de praktijk is niet hetzelfde.
Coolify's officiële schaalbaarheidsdocs zijn er duidelijk over: Docker Swarm-ondersteuning is gelabeld als experimenteel. Het standaard multi-server-patroon gebruikt gevalideerde remote servers verbonden via SSH met een gedeelde Docker Registry ertussen, en Traefik-instances die per server draaien. Swarm-modus vereist minimaal drie servers in dezelfde architectuur (allemaal ARM, of allemaal AMD64). Kubernetes? "Just planned, but not in the roadmap yet, so no ETA." Als je Coolify's eigen pagina hierover leest, is de korte versie: multi-server werkt, Swarm is een beta en Kubernetes is een visie.
Dokploy levert Docker Swarm als first-class modus zonder experimentele vlag. Traefik regelt de routing in zowel single-server- als Swarm-setups. De release van v0.29.0 voegde non-root multi-server-ondersteuning toe, wat een echt gat dicht (geen root-only SSH meer voor het toevoegen van remote nodes).
Als multi-node-clustering iets is dat je de komende zes maanden nodig hebt, niet "ooit op een slide deck", dan is Dokploy vandaag de keuze met het laagste risico.
Belangrijkste les van deze sectie: als clustering op je roadmap voor de korte termijn staat, draait het Swarm-verschil de aanbeveling richting Dokploy, ongeacht de andere assen.
Buildsystemen en taalondersteuning
Teams die van Heroku komen, geven het meest om welke buildpack-ecosystemen elke tool ondersteunt, want dat bepaalt hoeveel herschrijfwerk je project nodig heeft vóór de eerste deploy.
Coolify's buildpad is Nixpacks (standaard, auto-gedetecteerd uit je projectbestanden), Dockerfile of een vooraf gebouwde Docker image. Nixpacks is degelijk voor de gangbare gevallen (Node, Python, PHP, Go, Rust), maar de auto-detectie heeft ruwe randjes. De moeite van het verifiëren waard voor jouw stack: een Nixpacks-issue uit januari 2026 dat Laravel-projecten trof met zowel composer.json en package.json produceerde dubbele Nginx location-blocks, wat een klasse van deployments brak totdat upstream het oploste.
Dokploy ondersteunt Nixpacks, Dockerfile en Docker image, en voegt daar Heroku Buildpacks, Paketo Buildpacks en Railpack bovenop toe. Als je project al netjes bouwt met heroku.yml of een buildpack, laat Dokploy je die workflow behouden. Coolify zal je vragen om te converteren.
Op het eerste gezicht zien beide tools er hetzelfde uit: Git-push-deployments vanuit GitHub, GitLab, Bitbucket, automatische Let's Encrypt SSL, een web-UI voor environment-variabelen en databasebeheer. De breedte van het buildsysteem is een van de weinige plekken waar Dokploy duidelijk verder reikt.
One-click-app-catalogi
Voor niet-technische operators die bekende open-source-diensten willen uitrollen (n8n, Plausible, Supabase, Ghost, Listmonk, de gebruikelijke zelf-gehoste vaste waarden) is de omvang van de one-click-templatebibliotheek een echte differentiator. Voor sommige gebruikers is dat belangrijker dan andere zaken zoals prestaties of lichtgewicht zijn.
Coolify biedt 300+ one-click-services over ongeveer 40 categorieën: AI, analytics, automatisering, databases, beveiliging, opslag en de rest. Het is de grotere bibliotheek met een ruime marge en het praktische antwoord voor niet-developers die een dienst willen uitrollen zonder een Compose-bestand te schrijven.
De templatebibliotheek van Dokploy is kleiner. De huidige Dokploy-docs publiceren geen heldere telling, dus ik geef je geen getal.
Het praktische antwoord: als jouw workflow "deploy n8n, Supabase en Plausible in twee klikken elk" is, wint Coolify deze as overtuigend. Als je je eigen apps schrijft en ze alleen maar gedeployed wilt hebben, doet de catalogusomvang er niet toe en de andere assen wel.
Hoe te kiezen: aanbevelingen per use case
Er is hier geen enkele winnaar. Er zijn matches tussen een tool en een deploymentvorm:
- Niet-technisch team dat een servicebibliotheek wil: Coolify. De catalogus van 300+ templates is een betekenisvol voordeel.
- Docker-native developer die lichtgewicht + standaard Compose-afhandeling wil: Dokploy.
- ARM64-hardware (Raspberry Pi, ARM-gebaseerde VPS): Coolify. Dokploy adverteert ARM64-ondersteuning niet in de huidige docs; ben je op ARM, kies dan standaard Coolify totdat je het tegendeel hebt bevestigd.
- Multi-node-clustering die je dit kwartaal gaat gebruiken: Dokploy. Native Swarm versus experimentele Swarm is de doorslaggevende factor.
- Pure Apache 2.0, geen mogelijk toekomstig betaald niveau: Coolify.
- Migreren van Heroku en Heroku Buildpacks willen behouden: Dokploy.
- Bezorgd over de CVE's van januari 2026: een bijgewerkte Coolify (v4.0.0+) is prima. De echte vraag is je blootstellingsmodel. Als je het dashboard niet aan een privénetwerk of VPN kunt binden, is Dokploy de minder stressvolle keuze: kleiner oppervlak en een kortere geschiedenis van bekendmakingen met hoge ernst.
Een opmerking over het deployen van beide tools
Als je eenmaal hebt gekozen, is de installatie zelf één commando bij beide projecten, maar er is een shortcut die het weten waard is. Zowel Coolify als Dokploy zijn beschikbaar als one-click-deployments in onze marketplace, met Ubuntu 24.04 en Docker voorgeïnstalleerd en het dashboard al toegankelijk. Wil je de handmatige setup overslaan, dan zijn de marketplace-vermeldingen voor Coolify en Dokploy de snelste weg. Wil je liever vanaf een schoon OS starten en de officiële installer zelf draaien, dan publiceren beide projecten een one-line-script; kies wat past bij je provisioning-workflow.
Veelgestelde vragen
Is Dokploy nog steeds open source na de licentiewijziging van 2026?
Ja voor het kernplatform. Met ingang van January 21, 2026 is de kern van Dokploy standaard Apache 2.0. Een aparte Dokploy Source Available License beheert nu code in proprietary/ directory's, momenteel afgebakend tot toekomstige enterprise-features (SSO/SAML, fijnmazige RBAC, audit logs, white-labeling). Voor solo- en kleinteam-zelf-gehost gebruik is Dokploy functioneel open source.
Zijn de Coolify-beveiligingskwetsbaarheden van januari 2026 nog steeds een zorg?
De 11 bekendgemaakte CVE's zijn gepatcht in Coolify v4.0.0 (uitgebracht April 27, 2026). Als je v4.0.0 of nieuwer draait, zijn de bekendgemaakte kwetsbaarheden verholpen. Wat overblijft is blootstelling: houd Coolify bijgewerkt en stel het dashboard niet bloot aan het publieke internet. Bind het aan een privénetwerk of zet het achter een VPN.
