Coolify vs Dokploy: Důkladné porovnání pro self-hosted PaaS na VPS

Pokud jste již opustili spravované PaaS, váš VPS je zprovozněn, SSH klíč je přidán a kurzor v terminálu bliká na instalačním řádku. Jediná zbývající otázka: spustíte curl ... | bash pro Coolify, nebo pro Dokploy?

Oba nástroje se instalují jedním příkazem. Oba vám dávají nasazení přes Git push, automatické SSL, webové UI a reverzní proxy nad Dockerem. Zajímavé rozdíly jsou ty, které se projeví v produkci: jak každý z nich zachází se standardním docker-compose.yml, co se děje během nasazení a jak každý projekt reagoval na zprávy, které toto porovnání v roce 2026 přetvořily. Největší váhu zde nesou dvě zprávy: Zveřejnění CVE Coolify z ledna 2026 a také Restrukturalizace licence Dokploy ze stejného měsíce.

Tento příspěvek přiřazuje každý nástroj ke konkrétnímu případu použití, místo aby korunoval vítěze. Na konci snad budete vědět, který z nich se hodí k vašemu pracovnímu postupu.

Stručně řečeno

• Coolify je starší s větším ekosystémem (~55k hvězdiček na GitHubu, 300+ šablon služeb na jedno kliknutí), náročnější v nečinnosti, Apache 2.0 v celém rozsahu, bez placené úrovně na straně self-hosted.
• Dokploy je mladší (~34k hvězdiček), lehčí v nečinnosti, jádro Apache 2.0 plus samostatná Source Available License omezující budoucí placené funkce (SSO, RBAC, auditní logy, white-labeling).
• Coolify dnes nedokáže provádět nasazení bez výpadku přes Docker Compose; pouze přes Dockerfile, Nixpacks nebo nasazení jednoho image. Dokploy nabízí Docker Swarm jako prvotřídní režim; Swarm v Coolify je označen jako experimentální.
• CVE Coolify z ledna 2026 jsou opravena ve verzi v4.0.0 (April 27, 2026). Aktualizujte Coolify a nevystavujte dashboard veřejně.

Když ani jeden nástroj není správnou odpovědí

Coolify i Dokploy mají pro některá nastavení nesprávný tvar. Tři alternativy, o kterých stojí za to vědět, stručně:

• Kamal (od 37signals): pro týmy s jednou nebo dvěma aplikacemi, které nechtějí žádné UI; jen kamal deploy z vašeho notebooku. Výrazně jednodušší než Coolify nebo Dokploy a správná volba, když nechcete dashboard.
• Dokku: klasický model Git push, jeden server. Starší, menší rozsah, velmi stabilní. Originál „Heroku na jednom VPS".
• GitHub Actions + Docker Compose na holém VPS: nejmenší možný stack. Žádné orchestrační UI, ale zato žádná orchestrační režie. Dobré pro jednu aplikaci, kde je tok nasazení docker compose pull && docker compose up -d spouštěn z CI.

Pokud je váš tvar jedna aplikace na jednom serveru, Coolify i Dokploy jsou pravděpodobně příliš mnoho; nejprve vyzkoušejte jednu z výše uvedených. Pokud máte více aplikací, více databází nebo tým s netechnickými členy, kteří potřebují UI k obsluze věcí, je volba mezi Coolify a Dokploy tou správnou, kterou je třeba učinit. Pro širší přehled možností v této kategorii si přečtěte náš souhrn self-hosted cloudovými platformami s webovým rozhraním.

Coolify a Dokploy ve zkratce

Coolify v4.0.0 stable byl vydán April 27, 2026, po dlouhém cyklu beta. Dokploy je na verzi v0.29.4 k datu May 11, 2026. Oba jsou open-source self-hosted PaaS projekty v prostoru alternativ k Heroku/Render/Vercel, oba obalují Docker pomocí UI, reverzní proxy s HTTPS ve výchozím nastavení (Traefik) a nasazení založené na Gitu.

Funkce	Coolify	Dokploy
Nejnovější stabilní vydání	v4.0.0 (April 27, 2026)	v0.29.4 (May 11, 2026)
Licence	Apache 2.0	Jádro Apache 2.0 + Source Available pro placené funkce
Technologický stack	PHP / Laravel	TypeScript / Node.js
Hvězdičky na GitHubu	~55,000	~34,000
Minimální RAM (oficiálně)	2 GB	2 GB
Minimální CPU (oficiálně)	2 jádra	neuvedeno
RAM v nečinnosti (hlášeno komunitou)	500 MB – 1.2 GB	300 – 400 MB
Docker Compose bez výpadku	Nepodporováno (pouze Dockerfile/Nixpacks)	Standardní zpracování Compose
Clustering více serverů	Docker Swarm (experimentální)	Docker Swarm (nativní)
Podpora ARM64	Ano (vč. Raspberry Pi OS)	V dokumentaci neinzerováno
Build systémy	Nixpacks, Dockerfile, Docker image	Nixpacks, Dockerfile, Docker image, Heroku Buildpacks, Paketo, Railpack
Reverzní proxy	Traefik	Traefik
Rozsah self-hosted monitoringu	Vestavěné metriky + prohlížeč logů	Základní metriky zdrojů + analýza logů/chyb buildu pomocí AI (v0.29.0+)

Náš názor: vyberte Dokploy, pokud chcete nižší režii v nečinnosti, nativní podporu více serverů a standardní zpracování Docker Compose bez úprav specifických pro platformu. Vyberte Coolify, pokud chcete větší knihovnu aplikací na jedno kliknutí, podporu ARM64/Raspberry Pi nebo čisté Apache 2.0 bez budoucí placené úrovně čekající ve skrytu.

Náročnost na zdroje a dimenzování VPS

Self-hosted PaaS vám může ušetřit náklady na Heroku. Pokud orchestrační vrstva sežere 1,5 GB z vašeho 2 GB VPS v nečinnosti, nezbude vám nic, na co byste mohli nasadit. První praktická otázka na malém serveru tedy zní: kolik vás každý nástroj stojí, než vůbec nasadíte jedinou aplikaci?

Využití RAM v nečinnosti u Coolify závisí na tom, jaký monitoring je povolen, se základní zátěží CPU 5–7 %, která vyskočí, když se spustí stahování metrik. Vlastní dokumentace Coolify používá reprezentativní produkční zátěž 8 GB RAM, 4 jádra a 150 GB úložiště provozující 3 aplikace Node.js, 4 statické weby a několik databází. To je rozumný referenční bod pro dimenzování, pokud váš stack vypadá podobně.

Dokploy naproti tomu běží mnohem lehčeji, výrazně pod 2 % CPU, když se nic nenasazuje.

A Produkční zpráva LogRocket provozující oba nástroje vedle sebe dospěla ke stejnému směrovému závěru: docker stop && docker start u aplikace Dokploy nespustí úplný rebuild, zatímco stejná operace u Coolify ano. To samo o sobě posouvá náklady v ustáleném stavu ve prospěch Dokploy, zejména na menších plánech VPS, kde bouře rebuildů sežerou váš rozpočet CPU.

Pro dimenzování zde uvádím nastavení VPS, které bych doporučil:

• Coolify, lehká zátěž: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
• Coolify, referenční produkční zátěž: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
• Dokploy, lehká zátěž: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
• Dokploy, produkční rezerva: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.

Pro tip: RAM v nečinnosti u Coolify škáluje s konfigurací monitoringu. Pokud máte málo paměti, snižte interval stahování metrik (nebo zcela zakažte vestavěný monitoring, pokud již provozujete Prometheus/Grafana jinde), než zprovozníte větší server.

Realita nasazení: Docker Compose, Dockerfile a nasazení bez výpadku

Většina týmů přichází k jednomu z těchto nástrojů s existujícím docker-compose.yml a s očekáváním: vložit soubor, kliknout na nasazení, vidět aplikaci běžet. Jak každá platforma zachází se standardním Compose a co se stane s požadavky během příštího nasazení, je tam, kde se objevuje praktický rozdíl.

Coolify podporuje Docker Compose, Dockerfile, Nixpacks (automatická detekce ze souborů projektu) a přímé nasazení Docker image. Existuje však háček, který stojí za to výslovně zmínit: nasazení bez výpadku (postupné aktualizace, blue/green) fungují v Coolify pouze přes Dockerfile, Nixpacks nebo nasazení jednoho image. Nefungují přes Docker Compose. Správce Coolify potvrdil v diskuzi na GitHubu , že „u nasazení založených na compose jsou všechny kontejnery zastaveny před spuštěním nových, momentálně neexistuje žádná postupná aktualizace pro nasazení založená na compose." Podpora postupných aktualizací pro Compose je na plánu pro v5; v4 ji nedostane. Řešení, které správce navrhuje, je rozdělit stack Compose na jednotlivé služby Coolify, což je netriviální migrace, pokud váš soubor Compose vyjadřuje skutečné vztahy mezi službami.

Důsledek pro uživatele se projevuje ve vlákně na Hacker News o Coolify, kde to jeden operátor řekl natvrdo: „jakýkoli čekající požadavek při aktualizaci aplikace je prostě zabit." To je u nasazení Compose dnes přesné.

Vrstva Compose v Coolify také přidává to, co projekt nazývá „magickými proměnnými". To znamená automatické vkládání pomocných image, přepisování sítě a přepsání prostředí. Záměrem je být efektivnější; vedlejším účinkem je, že docker-compose.yml který běží čistě na vašem notebooku, někdy potřebuje úpravu, aby běžel čistě na Coolify. Totéž vlákno na Hacker News odhaluje reprezentativní případ: „Přidáno 8 proměnných do docker-compose, rozpoznáno je pouze 7." Pokud je váš stack Compose malý a standardní, na tyto problémy možná nenarazíte. Pokud je velký nebo neobvyklý, narazíte.

Postoj Dokploy je odlišný. Společnost LogRocket ve své praktické zprávě zjistila, že Dokploy „dokáže nasadit existující docker-compose.yml s malou nebo žádnou úpravou" a zůstává blízko nativnímu modelu směrování založeného na štítcích od Dockeru. Tatáž zpráva poznamenává, že zastavení/spuštění kontejneru v Dokploy nespustí úplný rebuild, zatímco stejná akce u Coolify ano. Jde spíše o směrový signál o chování za běhu než o formální „záruku nasazení bez výpadku" z dokumentace Dokploy, ale odpovídá to tomu, co self-hosteři hlásí na menších instancích VPS.

Dokploy také podporuje Heroku Buildpacks, Paketo Buildpacks a Railpack kromě Nixpacks a Dockerfile. Pro týmy přicházející z Heroku s heroku.yml nebo s pracovními postupy založenými na buildpacku je to cesta nejmenšího odporu.

Klíčové ponaučení z této části: pokud jsou vaše stávající služby skutečným stackem Docker Compose, Coolify vás přiměje buď restrukturalizovat strategii nasazení, nebo přijmout krátký výpadek při každém push. Dokploy ne.

Zabezpečení: Zveřejnění CVE Coolify z ledna 2026

Širší příběh čtu takto: Coolify je dnes bezpečné provozovat, pokud jej udržujete aktualizovaný a nevystavujete dashboard veřejnému internetu. Zveřejnění projekt nediskvalifikuje. Bylo dodrženo zodpovědné zveřejnění a opravy byly vydány. Co to odhaluje, je, že útočná plocha dostupná pro autentizovaného uživatele s nízkými oprávněními byla širší, než by měla být. To je lekce v návrhu pro projekt a provozní lekce pro operátora: utáhněte nyní model vystavení.

Pro tip: i po opravě zacházejte se svým dashboardem Coolify jako se SSH. Připojte jej k privátní síti, umístěte jej za VPN nebo jej postavte za Tailscale. Nevystavujte port 8000 veřejnému internetu jen proto, že to instalační skript usnadňuje.

Dokploy také není od tohoto druhu problému osvobozen. Poznámky k vydání verze v0.29.3 uznávají bezpečnostní zranitelnost identifikovanou v Dokploy a dodávají bezpečnostní opravný skript, který byste měli spustit spolu s upgradem. Menší plocha, kratší historie projektu, ale platí stejná provozní disciplína: aktualizujte v den, kdy opravy vyjdou, a nenechávejte dashboard na veřejném internetu.

Klíčové ponaučení z této části: příběh CVE je žlutou vlajkou pro provozní praxi Coolify, nikoli červenou vlajkou proti projektu, ale zvyšuje laťku v disciplíně aktualizací a v tom, jak vystavujete dashboard.

Licencování: Co je zdarma a co ne

Licence Dokploy byla restrukturalizována 21. ledna 2026. Zde je, co se změnilo a co to znamená pro self-hostery.

Dokploy je nyní standardní Apache 2.0 pro jádro, což nahrazuje dřívější nestandardní upravenou Apache 2.0, která uživatele matala ohledně toho, co je open source a co ne. Samostatná Dokploy Source Available License nyní řídí kód v proprietary/ adresářích: viditelný zdroj, placený pro produkční použití. Funkce, o kterých Dokploy říká, že budou žít za touto licencí:

• Single Sign-On (SSO/SAML) a pokročilé řízení přístupu
• Vlastní branding a white-labeling
• Vysoká dostupnost, automatické škálování a zotavení po havárii
• Pokročilý monitoring, integrace a funkce pro shodu s předpisy

Projekt se výslovně zavázal, že nikdy nepřesune stávající open-source funkci do placené úrovně; budoucí placená funkčnost je zaměřena na organizace, které potřebují podnikové lepidlo. 2FA již dnes sedí za úrovní Startup na cenové stránce Dokploy.

Situace u Coolify je přímočará. Projekt je Apache 2.0 na GitHubu; každá funkce v self-hosted verzi je zdarma. Existuje nabídka Coolify Cloud pro týmy, které chtějí, aby jej hostoval správce, ale self-hosted verze je kompletní produkt bez omezení funkcí a bez cesty k upgradu na placenou úroveň, kterou dnes nemáte.

Můj názor: pro samostatné vývojáře a malé týmy provozující self-hosting na vlastním VPS je Dokploy funkčně zdarma a tak to zůstane. Pro organizaci, která nakonec potřebuje SSO, jemně odstupňované RBAC, auditní logy nebo white-labeling, vás Dokploy nakonec posune k placené úrovni. Coolify ne, protože Coolify takovou úroveň na plánu nemá.

Vyjasnění napříč zdroji, které stojí za to udělat: self-hosted build Dokploy zahrnuje základní metriky zdrojů (CPU, paměť, úložiště, síť) a v0.29.0 přidala analýzu logů a chyb buildu pomocí AI. Monitorovací systém Dokploy je pro pokročilejší funkce monitoringu pouze cloudový. Monitoring však u self-hosted instalace stále běží lokálně pro základní metriky zdrojů před kontejnerem.

Více serverů a clustering: Realita vs marketing

Dříve nebo později jeden VPS nestačí a oba projekty na svých vstupních stránkách prominentně inzerují podporu více serverů. Realita v praxi není stejná.

Oficiální dokumentace o škálovatelnosti od Coolify je v tom přímá: podpora Docker Swarm je označena jako experimentální. Standardní vzor pro více serverů používá ověřené vzdálené servery připojené přes SSH se sdíleným Docker Registry mezi nimi a instancemi Traefik běžícími na každém serveru. Režim Swarm vyžaduje minimálně tři servery ve stejné architektuře (vše ARM, nebo vše AMD64). Kubernetes? „Jen plánováno, ale ne na plánu, takže žádné ETA." Pokud si přečtete vlastní stránku Coolify o tomto, krátká verze zní: více serverů funguje, Swarm je beta a Kubernetes je vize.

Dokploy nabízí Docker Swarm jako prvotřídní režim bez experimentálního příznaku. Traefik zajišťuje směrování v nastaveních s jedním serverem i Swarm. Vydání v0.29.0 přidalo podporu více serverů bez root oprávnění, což zaceluje skutečnou mezeru (žádné SSH pouze pro root při přidávání vzdálených uzlů).

Pokud je clustering více uzlů něco, co budete potřebovat v příštích šesti měsících, nikoli „někdy na prezentaci", je Dokploy dnes volbou s nižším rizikem.

Klíčové ponaučení z této části: pokud je clustering na vašem blízkém plánu, rozdíl ve Swarm překlápí doporučení směrem k Dokploy bez ohledu na ostatní osy.

Build systémy a podpora jazyků

Týmy přicházející z Heroku se budou nejvíce zajímat o to, které ekosystémy buildpacků každý nástroj podporuje, protože to rozhoduje o tom, kolik přepisování váš projekt potřebuje před prvním nasazením.

Cesta buildu u Coolify je Nixpacks (výchozí, automaticky detekováno ze souborů projektu), Dockerfile nebo předem připravený Docker image. Nixpacks je solidní pro běžné případy (Node, Python, PHP, Go, Rust), ale automatická detekce má hrubé hrany. Stojí za to ověřit pro váš stack: problém s Nixpacks z ledna 2026 ovlivňující projekty Laravel s oběma composer.json a package.json produkoval duplicitní bloky location v Nginx, což rozbilo třídu nasazení, dokud to upstream neopravil.

Dokploy podporuje Nixpacks, Dockerfile a Docker image a navíc přidává Heroku Buildpacks, Paketo Buildpacks a Railpack. Pokud se váš projekt již čistě sestavuje s heroku.yml nebo s buildpackem, Dokploy vám umožní zachovat tento pracovní postup. Coolify vás požádá o převod.

Na povrchu vypadají oba nástroje stejně: nasazení přes Git push z GitHubu, GitLabu, Bitbucketu, automatické SSL Let's Encrypt, webové UI pro proměnné prostředí a správu databází. Šíře build systémů je jedním z mála míst, kde Dokploy jasně sahá dál.

Katalogy aplikací na jedno kliknutí

Pro netechnické operátory, kteří chtějí nasadit známé open-source služby (n8n, Plausible, Supabase, Ghost, Listmonk, obvyklou self-hosted stáj), je velikost knihovny šablon na jedno kliknutí skutečným rozlišovacím faktorem. Pro některé uživatele je to důležitější než jiné oblasti, jako je výkon nebo lehkost.

Coolify nabízí 300+ služeb na jedno kliknutí napříč zhruba 40 kategoriemi: AI, analytika, automatizace, databáze, zabezpečení, úložiště a další. Je to s velkým náskokem větší knihovna a praktická odpověď pro nevývojáře, kteří chtějí nasadit službu bez psaní souboru Compose.

Knihovna šablon Dokploy je menší. Aktuální dokumentace Dokploy nepublikuje přesný počet, takže vám číslo neuvedu.

Praktická odpověď: pokud je váš pracovní postup „nasaď n8n, Supabase a Plausible každý dvěma kliknutími", Coolify tuto osu vyhrává jednoznačně. Pokud píšete vlastní aplikace a chcete je jen nasadit, na velikosti katalogu nezáleží a záleží na ostatních osách.

Jak si vybrat: Doporučení podle případu použití

Není zde jediný vítěz. Existují shody mezi nástrojem a tvarem nasazení:

• Netechnický tým, který chce knihovnu služeb: Coolify. Katalog 300+ šablon je smysluplnou výhodou.
• Vývojář nativní v Dockeru, který chce lehkost + standardní zpracování Compose: Dokploy.
• Hardware ARM64 (Raspberry Pi, VPS založené na ARM): Coolify. Dokploy v aktuální dokumentaci neinzeruje podporu ARM64; pokud jste na ARM, výchozí volbou je Coolify, dokud si neověříte opak.
• Clustering více uzlů, který využijete tento kvartál: Dokploy. Nativní Swarm vs. experimentální Swarm je rozhodujícím faktorem.
• Čisté Apache 2.0, bez možné budoucí placené úrovně: Coolify.
• Migrace z Heroku se zachováním Heroku Buildpacks: Dokploy.
• Obavy z CVE z ledna 2026: aktualizovaný Coolify (v4.0.0+) je v pořádku. Skutečná otázka je váš model vystavení. Pokud nemůžete připojit dashboard k privátní síti nebo VPN, je Dokploy volbou s menším stresem: menší plocha a kratší historie zveřejnění s vysokou závažností.

Poznámka k nasazení obou nástrojů

Jakmile si vyberete, samotná instalace je jeden příkaz u kteréhokoli projektu, ale stojí za to znát zkratku. Coolify i Dokploy jsou k dispozici jako nasazení na jedno kliknutí v náš obchods předinstalovaným Ubuntu 24.04 a Dockerem a s již přístupným dashboardem. Pokud chcete přeskočit ruční nastavení, nejrychlejší cestou jsou nabídky na marketplace pro Coolify a Dokploy Pokud raději začnete z čistého OS a spustíte oficiální instalátor sami, oba projekty publikují jednořádkový skript; vyberte ten, který se hodí k vašemu pracovnímu postupu zprovoznění.

Časté dotazy

Je Dokploy po změně licence z roku 2026 stále open source?

Ano pro jádro platformy. Od 21. ledna 2026 je jádro Dokploy standardní Apache 2.0. Samostatná Dokploy Source Available License nyní řídí kód v proprietary/ adresářích, aktuálně omezený na budoucí podnikové funkce (SSO/SAML, jemně odstupňované RBAC, auditní logy, white-labeling). Pro samostatné a malé týmy v self-hosted použití je Dokploy funkčně open source.

Jsou bezpečnostní zranitelnosti Coolify z ledna 2026 stále důvodem k obavám?

11 zveřejněných CVE je opraveno v Coolify v4.0.0 (vydáno April 27, 2026). Pokud provozujete v4.0.0 nebo novější, jsou zveřejněné zranitelnosti vyřešeny. Co zbývá, je vystavení: udržujte Coolify aktualizovaný a nevystavujte dashboard veřejnému internetu. Připojte jej k privátní síti nebo jej umístěte za VPN.