Hvis du allerede har forladt den managed PaaS, er din VPS provisioneret, SSH-nøglen er tilføjet, og din terminalmarkør blinker på installationslinjen. Det eneste spørgsmål tilbage: kører du curl ... | bash for Coolify, eller for Dokploy?
Begge værktøjer installeres med én kommando. Begge giver dig Git-push-udrulninger, automatisk SSL, en web-UI og en reverse proxy oven på Docker. De interessante forskelle er dem, der dukker op i produktion: hvordan hver af dem håndterer en standard docker-compose.yml, hvad der sker under en udrulning, og hvordan hvert projekt reagerede på den nyhed, der omformede denne sammenligning i 2026. To nyheder bærer det meste af vægten her: Coolifys CVE-offentliggørelser fra januar 2026 og Dokploys licensomstrukturering i den samme måned.
Dette indlæg matcher hvert værktøj til en specifik anvendelse i stedet for at kåre en vinder. Til sidst ved du forhåbentlig, hvilket der passer til dit workflow.
Kort sagt
- Coolify er ældre med det større økosystem (~55k GitHub-stjerner, 300+ one-click-service-skabeloner), tungere i tomgang, Apache 2.0 hele vejen igennem, uden noget betalt niveau på den selvhostede side.
- Dokploy er yngre (~34k stjerner), lettere i tomgang, Apache 2.0-kerne plus en separat Source Available License, der spærrer fremtidige betalte funktioner (SSO, RBAC, audit-logs, white-labeling).
- Coolify kan ikke lave nul-nedetids-udrulninger via Docker Compose i dag; kun via Dockerfile, Nixpacks eller single-image-udrulninger. Dokploy leverer Docker Swarm som en førsteklasses tilstand; Coolifys Swarm er mærket eksperimentel.
- Coolify-CVE'erne fra januar 2026 er rettet i v4.0.0 (April 27, 2026). Opdater Coolify, og eksponer ikke dashboardet offentligt.
Når ingen af værktøjerne er det rigtige svar
Både Coolify og Dokploy har den forkerte form til nogle opsætninger. Tre alternativer, der er værd at kende, kort:
- Kamal (fra 37signals): til teams med en eller to apps, der ønsker nul UI; bare
kamal deployfra din laptop. Enklere end Coolify eller Dokploy med en bred margin og det rigtige valg, når du ikke vil have et dashboard. - Dokku: klassikeren, Git-push, single-server-modellen. Ældre, mindre omfang, meget stabil. Den oprindelige "Heroku på én VPS".
- GitHub Actions + Docker Compose på en bare VPS: den mindst mulige stak. Ingen orkestrerings-UI, men heller ingen orkestrerings-overhead. God til en enkelt app, hvor udrulningsflowet er
docker compose pull && docker compose up -dudløst fra CI.
Hvis din form er én app på én server, er både Coolify og Dokploy nok overkill; prøv en af ovenstående først. Hvis du har flere apps, flere databaser eller et team med ikke-tekniske medlemmer, der har brug for en UI til at betjene tingene, er Coolify-vs-Dokploy-valget det rigtige at træffe. For en bredere oversigt over muligheder i denne kategori, se vores oversigt over self-hosted cloud-platforme med web-UI.
Coolify og Dokploy med et hurtigt overblik
Coolify v4.0.0 stable blev udgivet den April 27, 2026, efter en lang beta-cyklus. Dokploy er på v0.29.4 fra og med May 11, 2026. Begge er open source selvhostede PaaS-projekter i Heroku/Render/Vercel-alternativ-rummet, begge pakker Docker ind med en UI, en HTTPS-by-default reverse proxy (Traefik) og Git-baserede udrulninger.
| Funktion | Coolify | Dokploy |
|---|---|---|
| Seneste stabile udgivelse | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| Licens | Apache 2.0 | Apache 2.0-kerne + Source Available til betalte funktioner |
| Teknologistak | PHP / Laravel | TypeScript / Node.js |
| GitHub-stjerner | ~55,000 | ~34,000 |
| Minimum RAM (officielt) | 2 GB | 2 GB |
| Minimum CPU (officielt) | 2 kerner | ikke specificeret |
| Tomgangs-RAM (community-rapporteret) | 500 MB – 1.2 GB | 300 – 400 MB |
| Docker Compose nul-nedetid | Ikke understøttet (kun Dockerfile/Nixpacks) | Standard Compose-håndtering |
| Multi-server-clustering | Docker Swarm (eksperimentel) | Docker Swarm (native) |
| ARM64-understøttelse | Ja (inkl. Raspberry Pi OS) | Ikke annonceret i dokumentationen |
| Build-systemer | Nixpacks, Dockerfile, Docker-image | Nixpacks, Dockerfile, Docker-image, Heroku Buildpacks, Paketo, Railpack |
| Omvendt proxy | Traefik | Traefik |
| Selvhostet overvågningsomfang | Indbyggede metrics + log-viewer | Grundlæggende ressource-metrics + AI-analyse af log/build-fejl (v0.29.0+) |
Vores anbefaling: vælg Dokploy, hvis du ønsker lavere tomgangs-overhead, native multi-server-understøttelse og standard Docker Compose-håndtering uden platformsspecifik tilpasning. Vælg Coolify, hvis du ønsker det større one-click-app-bibliotek, ARM64/Raspberry Pi-understøttelse eller ren Apache 2.0 uden et fremtidigt betalt niveau, der venter i kulissen.
Ressourceforbrug og VPS-dimensionering
En selvhostet PaaS kan spare dig for omkostningerne ved Heroku. Hvis orkestreringslaget æder 1,5 GB af din 2 GB VPS i tomgang, har du intet tilbage at udrulle på. Så det første praktiske spørgsmål på en lille server er: hvor meget koster hvert værktøj dig, før du har udrullet en eneste app?
Coolifys tomgangs-RAM-forbrug afhænger af, hvilken overvågning der er aktiveret, med et 5–7% baseline-CPU-fodaftryk, der stiger, når metrics-scrapet kører. Coolifys egen dokumentation bruger en repræsentativ produktionsbelastning på 8 GB RAM, 4 kerner og 150 GB lagring, der kører 3 Node.js-apps, 4 statiske websteder og et par databaser. Det er en rimelig dimensioneringsreference, hvis din stak ligner.
Dokploy kører til gengæld meget lettere, et godt stykke under 2% CPU, når intet udrulles.
A LogRockets produktionsgennemgang der kører begge værktøjer side om side, nåede den samme retningsbestemte konklusion: et docker stop && docker start på en Dokploy-app udløser ikke en fuld genopbygning, mens den samme operation på Coolify gør. Det alene flytter steady-state-omkostningerne til Dokploys fordel, især på mindre VPS-planer, hvor genopbygningsstorme æder dit CPU-budget.
Til dimensionering er her den VPS-opsætning, jeg vil anbefale:
- Coolify, let belastning: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, produktionsreference-belastning: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, let belastning: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, produktions-headroom: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
Pro-tip: Coolifys tomgangs-RAM skalerer med overvågningskonfigurationen. Hvis du har lidt hukommelse, så skru ned for metrics-scrape-intervallet (eller deaktiver den indbyggede overvågning helt, hvis du allerede kører Prometheus/Grafana et andet sted), før du provisionerer en større server.
Udrulningsvirkeligheden: Docker Compose, Dockerfile og nul-nedetid
De fleste teams ankommer til et af disse værktøjer med en eksisterende docker-compose.yml og en forventning: indsæt filen, klik på udrul, se appen komme op. Hvordan hver platform håndterer standard Compose, og hvad der sker med igangværende forespørgsler under den næste udrulning, er der, hvor den praktiske forskel viser sig.
Coolify understøtter Docker Compose, Dockerfile, Nixpacks (auto-detektion fra projektfiler) og direkte Docker-image-udrulninger. Der er dog en hage, som er værd at være eksplicit omkring: nul-nedetids-udrulninger (rullende opdateringer, blue/green) virker i Coolify kun via Dockerfile, Nixpacks eller single-image-udrulninger. De virker ikke via Docker Compose. En Coolify-vedligeholder bekræftede i en GitHub-diskussion at "for compose-baserede udrulninger stoppes alle containere, før de nye startes, der er ingen rullende opdatering for compose-baserede udrulninger i øjeblikket." Rullende understøttelse af Compose er på roadmappet for v5; v4 får den ikke. Den workaround, vedligeholderen foreslår, er at opdele en Compose-stak i individuelle Coolify-tjenester, hvilket er en ikke-triviel migrering, hvis din Compose-fil udtrykker reelle relationer mellem tjenester.
Den brugervendte konsekvens dukker op i en Hacker News-tråd om Coolify, hvor en operatør formulerede det direkte: "enhver ventende forespørgsel, når du opdaterer en app, bliver simpelthen dræbt." Det er korrekt for Compose-udrulninger i dag.
Coolifys Compose-lag tilføjer også det, projektet kalder "magic variables." Det betyder automatisk injektion af hjælpe-images, netværksomskrivninger og miljøtilsidesættelser. Hensigten er at være mere effektiv; bivirkningen er, at en docker-compose.yml der kører rent på din laptop, nogle gange har brug for justering for at køre rent på Coolify. Den samme Hacker News-tråd fremhæver et repræsentativt tilfælde: "Tilføjede 8 variabler inde i docker-compose, kun 7 bliver genkendt." Hvis din Compose-stak er lille og standard, rammer du måske ikke disse. Hvis den er stor eller usædvanlig, gør du.
Dokploys holdning er anderledes. LogRockets praktiske gennemgang fandt, at Dokploy "kan udrulle en eksisterende docker-compose.yml med lidt til ingen modifikation" og holder sig tæt på Dockers native label-baserede routing-model. Den samme gennemgang bemærker, at container-stop/start i Dokploy ikke udløser en fuld genopbygning, hvorimod den samme handling på Coolify gør. Dette er et retningsbestemt signal om runtime-adfærd snarere end en formel "nul-nedetids-garanti" fra Dokploy-dokumentationen, men det stemmer overens med, hvad selvhostere rapporterer på mindre VPS-instanser.
Dokploy understøtter også Heroku Buildpacks, Paketo Buildpacks og Railpack ud over Nixpacks og Dockerfile. For teams, der ankommer fra Heroku med heroku.yml eller buildpack-baserede workflows, er det vejen med mindst modstand.
Sektionens hovedpointe: hvis dine eksisterende tjenester er en reel Docker Compose-stak, vil Coolify kræve, at du enten omstrukturerer din udrulningsstrategi eller accepterer kort nedetid per push. Dokploy vil ikke.
Sikkerhed: Coolify-CVE-offentliggørelserne fra januar 2026
Jeg læser den bredere historie sådan her: Coolify er sikker at køre i dag, hvis du holder den opdateret, og du ikke eksponerer dashboardet mod det offentlige internet. Offentliggørelsen diskvalificerer ikke projektet. Ansvarlig offentliggørelse blev fulgt, og patches blev udsendt. Hvad den afslører, er, at den angrebsflade, der var tilgængelig for en lavt-privilegeret autentificeret bruger, var bredere, end den burde have været. Det er en designlektion for projektet og en operationel lektion for operatøren: stram eksponeringsmodellen nu.
Pro-tip: selv efter patching, behandl dit Coolify-dashboard som SSH. Bind det til et privat netværk, sæt det bag en VPN, eller stil en Tailscale. Eksponer ikke port 8000 mod det offentlige internet, bare fordi installationsscriptet gør det nemt.
Dokploy er heller ikke fritaget for denne slags problemer. v0.29.3-udgivelsesnoterne anerkender en sikkerhedssårbarhed identificeret i Dokploy og leverer et sikkerhedspatch-script, du forventes at køre sammen med opgraderingen. Mindre overflade, kortere projekthistorik, men den samme operationelle disciplin gælder: opdater på den dag, patches udkommer, lad ikke dashboardet stå på det offentlige internet.
Sektionens hovedpointe: CVE-historien er et gult flag for Coolifys operationelle praksis, ikke et rødt flag mod projektet, men den hæver barren for opdateringsdisciplin og for, hvordan du eksponerer dashboardet.
Licensering: Hvad er gratis, hvad er ikke
Dokploys licens blev omstruktureret den January 21, 2026. Her er, hvad der ændrede sig, og hvad det betyder for selvhostere.
Dokploy er nu standard Apache 2.0 for kernen, der erstatter den tidligere ikke-standard tilpassede Apache 2.0, som forvirrede brugere om, hvad der var open source, og hvad der ikke var. En separat Dokploy Source Available License styrer nu koden i proprietary/ -mapper: synlig kildekode, betalt for produktionsbrug. De funktioner, Dokploy siger vil leve bag den licens:
- Single Sign-On (SSO/SAML) og avancerede adgangskontroller
- Tilpasset branding og white-labeling
- Høj tilgængelighed, auto-skalering og disaster recovery
- Avanceret overvågning, integrationer og compliance-funktioner
Projektet har eksplicit forpligtet sig til aldrig at flytte en eksisterende open source-funktion ind i det betalte niveau; fremtidig betalt funktionalitet er rettet mod organisationer, der har brug for enterprise-lim. 2FA sidder allerede i dag bag Startup-niveauet på Dokploys prisside.
Coolifys situation er ligetil. Projektet er Apache 2.0 på GitHub; hver funktion i den selvhostede version er gratis. Der er et Coolify Cloud-tilbud for teams, der ønsker, at vedligeholderen skal hoste det, men den selvhostede version er et komplet produkt uden funktionsspærringer og uden en opgraderingssti til et betalt niveau, du ikke har i dag.
Min vurdering: for solo-udviklere og små teams, der selvhoster på deres egen VPS, er Dokploy funktionelt gratis og vil forblive det. For en organisation, der til sidst har brug for SSO, fingranuleret RBAC, audit-logs eller white-labeling, vil Dokploy til sidst skubbe dig mod et betalt niveau. Coolify vil ikke, fordi Coolify ikke har det niveau på roadmappet.
En afklaring på tværs af kilder, der er værd at gøre: Dokploys selvhostede build inkluderer grundlæggende ressource-metrics (CPU, hukommelse, lagring, netværk), og v0.29.0 tilføjede AI-drevet analyse af log- og build-fejl. Dokploys overvågningssystem er kun cloud for de mere avancerede overvågningsfunktioner. Overvågningen kører dog stadig lokalt på en selvhostet installation for grundlæggende pre-container ressource-metrics.
Multi-server og clustering: virkelighed vs marketing
Før eller siden er en enkelt VPS ikke nok, og begge projekter markedsfører multi-server-understøttelse fremtrædende på deres landingssider. Virkeligheden i praksis er ikke den samme.
Coolifys officielle skalerbarhedsdokumentation er direkte omkring det: Docker Swarm-understøttelse er mærket eksperimentel. Standard multi-server-mønstret bruger validerede fjern-servere forbundet over SSH med et Docker Registry delt mellem dem og Traefik-instanser, der kører per server. Swarm-tilstand kræver et minimum af tre servere i den samme arkitektur (alle ARM eller alle AMD64). Kubernetes? "Bare planlagt, men endnu ikke på roadmappet, så ingen ETA." Hvis du læser Coolifys egen side om dette, er den korte version: multi-server virker, Swarm er en beta, og Kubernetes er en vision.
Dokploy leverer Docker Swarm som en førsteklasses tilstand uden et eksperimentelt flag. Traefik håndterer routing i både single-server- og Swarm-opsætninger. v0.29.0-udgivelsen tilføjede non-root multi-server-understøttelse, hvilket lukker et reelt hul (ikke længere root-only SSH for at tilføje fjern-noder).
Hvis multi-node-clustering er noget, du får brug for inden for de næste seks måneder, ikke "en dag på et slide-deck," er Dokploy det laveste-risiko-valg i dag.
Sektionens hovedpointe: hvis clustering er på dit nære roadmap, vipper Swarm-forskellen anbefalingen mod Dokploy uanset de øvrige akser.
Build-systemer og sprogunderstøttelse
Teams, der ankommer fra Heroku, vil bekymre sig mest om, hvilke buildpack-økosystemer hvert værktøj understøtter, fordi det afgør, hvor meget omskrivning dit projekt har brug for før sin første udrulning.
Coolifys build-sti er Nixpacks (standard, auto-detekteret fra dine projektfiler), Dockerfile eller et færdigbygget Docker-image. Nixpacks er solid til de almindelige tilfælde (Node, Python, PHP, Go, Rust), men auto-detektionen har skarpe kanter. Værd at verificere for din stak: et Nixpacks-problem fra januar 2026, der påvirkede Laravel-projekter med begge composer.json og package.json producerede dublerede Nginx-location-blokke, hvilket brød en klasse af udrulninger, indtil upstream rettede det.
Dokploy understøtter Nixpacks, Dockerfile og Docker-image og tilføjer Heroku Buildpacks, Paketo Buildpacks og Railpack oven i. Hvis dit projekt allerede bygger rent med heroku.yml eller en buildpack, lader Dokploy dig beholde det workflow. Coolify vil bede dig om at konvertere.
På overfladen ser begge værktøjer ens ud: Git-push-udrulninger fra GitHub, GitLab, Bitbucket, automatisk Let's Encrypt SSL, en web-UI til miljøvariabler og databasestyring. Build-systemets bredde er et af de få steder, hvor Dokploy tydeligt strækker sig længere.
One-click-app-kataloger
For ikke-tekniske operatører, der ønsker at udrulle kendte open source-tjenester (n8n, Plausible, Supabase, Ghost, Listmonk, den sædvanlige selvhostede stald), er størrelsen af one-click-skabelonbiblioteket en reel differentiator. For nogle brugere er det vigtigere end andre områder som ydeevne eller at være letvægts.
Coolify tilbyder 300+ one-click-tjenester på tværs af cirka 40 kategorier: AI, analytics, automatisering, databaser, sikkerhed, lagring og resten. Det er det større bibliotek med en bred margin og det praktiske svar for ikke-udviklere, der ønsker en tjeneste udrullet uden at skrive en Compose-fil.
Dokploys skabelonbibliotek er mindre. Den aktuelle Dokploy-dokumentation offentliggør ikke et rent antal, så jeg vil ikke give dig et tal.
Det praktiske svar: hvis dit workflow er "udrul n8n, Supabase og Plausible med to klik hver," vinder Coolify denne akse rent. Hvis du skriver dine egne apps og bare vil have dem udrullet, betyder katalogstørrelsen ikke noget, og de andre akser gør.
Sådan vælger du: anbefalinger efter anvendelse
Der er ingen enkelt vinder her. Der er matches mellem et værktøj og en udrulningsform:
- Ikke-teknisk team, der ønsker et tjenestebibliotek: Coolify. 300+ skabelon-kataloget er en meningsfuld fordel.
- Docker-native udvikler, der ønsker letvægts + standard Compose-håndtering: Dokploy.
- ARM64-hardware (Raspberry Pi, ARM-baseret VPS): Coolify. Dokploy annoncerer ikke ARM64-understøttelse i den aktuelle dokumentation; hvis du er på ARM, vælg som standard Coolify, indtil du har bekræftet andet.
- Multi-node-clustering, du vil bruge dette kvartal: Dokploy. Native Swarm vs. eksperimentel Swarm er den afgørende faktor.
- Ren Apache 2.0, intet muligt fremtidigt betalt niveau: Coolify.
- Migrerer fra Heroku og vil beholde Heroku Buildpacks: Dokploy.
- Bekymret for CVE'erne fra januar 2026: en opdateret Coolify (v4.0.0+) er fin. Det reelle spørgsmål er din eksponeringsmodel. Hvis du ikke kan binde dashboardet til et privat netværk eller VPN, er Dokploy det mindre stressende valg: mindre overflade og en kortere historik med højalvorlige offentliggørelser.
En note om at udrulle begge værktøjer
Når du har valgt, er installationen i sig selv én kommando på begge projekter, men der er en genvej værd at kende. Både Coolify og Dokploy er tilgængelige som one-click-udrulninger i vores markedsplads, med Ubuntu 24.04 og Docker forudinstalleret og dashboardet allerede tilgængeligt. Hvis du vil springe den manuelle opsætning over, er marketplace-listerne for Coolify og Dokploy den hurtigste vej. Hvis du hellere vil starte fra et rent OS og køre den officielle installer selv, offentliggør begge projekter et script på én linje; vælg det, der passer til dit provisioneringsworkflow.
Ofte stillede spørgsmål
Er Dokploy stadig open source efter licensændringen i 2026?
Ja for kerneplatformen. Med virkning fra January 21, 2026, er Dokploys kerne standard Apache 2.0. En separat Dokploy Source Available License styrer nu koden i proprietary/ -mapper, i øjeblikket afgrænset til fremtidige enterprise-funktioner (SSO/SAML, fingranuleret RBAC, audit-logs, white-labeling). Til solo- og små-team-selvhostet brug er Dokploy funktionelt open source.
Er Coolify-sikkerhedssårbarhederne fra januar 2026 stadig en bekymring?
De 11 offentliggjorte CVE'er er rettet i Coolify v4.0.0 (udgivet April 27, 2026). Hvis du kører v4.0.0 eller nyere, er de offentliggjorte sårbarheder adresseret. Hvad der er tilbage, er eksponering: hold Coolify opdateret, og eksponer ikke dashboardet mod det offentlige internet. Bind det til et privat netværk, eller sæt det bag en VPN.
