Jeśli już opuściłeś zarządzane PaaS, Twój VPS jest udostępniony, klucz SSH dodany, a kursor w terminalu miga na linii instalacji. Pozostaje jedno pytanie: uruchamiasz curl ... | bash dla Coolify, czy dla Dokploy?
Oba narzędzia instalują się jedną komendą. Oba dają Ci wdrożenia Git-push, automatyczny SSL, interfejs webowy i reverse proxy na bazie Dockera. Ciekawe różnice to te, które ujawniają się na produkcji: jak każde obsługuje standardowy docker-compose.yml, co dzieje się podczas wdrożenia i jak każdy projekt zareagował na wiadomości, które zmieniły kształt tego porównania w 2026 roku. Dwie wiadomości niosą tu najwięcej znaczenia: Ujawnienie CVE Coolify ze stycznia 2026 i Zmiana struktury licencji Dokploy tego samego miesiąca.
Ten wpis dopasowuje każde narzędzie do konkretnego przypadku użycia, zamiast koronować zwycięzcę. Na końcu, mam nadzieję, będziesz wiedzieć, które pasuje do Twojego przepływu pracy.
W skrócie
- Coolify jest starszy, z większym ekosystemem (~55k gwiazdek na GitHub, 300+ szablonów usług typu jeden klik), cięższy w stanie bezczynności, w całości Apache 2.0, bez płatnego planu po stronie samodzielnego hostingu.
- Dokploy jest młodszy (~34k gwiazdek), lżejszy w stanie bezczynności, rdzeń Apache 2.0 plus osobna Source Available License obejmująca przyszłe płatne funkcje (SSO, RBAC, dzienniki audytu, white-labeling).
- Coolify nie potrafi dziś wykonywać wdrożeń zero-downtime przez Docker Compose; tylko przez Dockerfile, Nixpacks lub wdrożenia pojedynczego obrazu. Dokploy dostarcza Docker Swarm jako tryb pierwszej klasy; Swarm w Coolify jest oznaczony jako eksperymentalny.
- CVE Coolify ze stycznia 2026 są załatane w v4.0.0 (April 27, 2026). Zaktualizuj Coolify i nie wystawiaj panelu publicznie.
Gdy żadne z narzędzi nie jest właściwą odpowiedzią
Zarówno Coolify, jak i Dokploy mają niewłaściwy kształt dla niektórych konfiguracji. Trzy alternatywy warte poznania, w skrócie:
- Kamal (od 37signals): dla zespołów z jedną lub dwiema aplikacjami, które chcą zero UI; po prostu
kamal deployz Twojego laptopa. Znacznie prostszy niż Coolify czy Dokploy i właściwy wybór, gdy nie chcesz panelu. - Dokku: klasyk, model Git-push, jednoserwerowy. Starszy, węższy zakres, bardzo stabilny. Oryginalny „Heroku na jednym VPS-ie".
- GitHub Actions + Docker Compose na czystym VPS: najmniejszy możliwy stos. Brak interfejsu orkiestracji, ale też brak narzutu orkiestracji. Dobry dla pojedynczej aplikacji, gdzie przepływ wdrożenia jest
docker compose pull && docker compose up -dwyzwalany z CI.
Jeśli Twój kształt to jedna aplikacja na jednym serwerze, zarówno Coolify, jak i Dokploy są prawdopodobnie przesadą; spróbuj najpierw jednego z powyższych. Jeśli masz wiele aplikacji, wiele baz danych lub zespół z osobami nietechnicznymi, które potrzebują UI do obsługi spraw, wybór Coolify kontra Dokploy jest tym właściwym. Aby uzyskać szerszy przegląd opcji w tej kategorii, zobacz nasze zestawienie self-hosted platformach chmurowych z internetowym interfejsem.
Coolify i Dokploy w skrócie
Coolify v4.0.0 stable ukazał się April 27, 2026, po długim cyklu beta. Dokploy jest na v0.29.4 na dzień May 11, 2026. Oba to otwartoźródłowe, samodzielnie hostowane projekty PaaS w przestrzeni alternatyw dla Heroku/Render/Vercel, oba opakowują Docker w UI, reverse proxy z HTTPS-by-default (Traefik) i wdrożenia oparte na Git.
| Funkcja | Coolify | Dokploy |
|---|---|---|
| Najnowsze stabilne wydanie | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| Licencja | Apache 2.0 | Rdzeń Apache 2.0 + Source Available dla płatnych funkcji |
| Stos technologiczny | PHP / Laravel | TypeScript / Node.js |
| Gwiazdki na GitHub | ~55,000 | ~34,000 |
| Minimalny RAM (oficjalnie) | 2 GB | 2 GB |
| Minimalny CPU (oficjalnie) | 2 rdzenie | nie określono |
| RAM w bezczynności (zgłaszany przez społeczność) | 500 MB – 1.2 GB | 300 – 400 MB |
| Zero-downtime dla Docker Compose | Nieobsługiwane (tylko Dockerfile/Nixpacks) | Standardowa obsługa Compose |
| Klastrowanie wieloserwerowe | Docker Swarm (eksperymentalny) | Docker Swarm (natywny) |
| Wsparcie ARM64 | Tak (w tym Raspberry Pi OS) | Nieuwzględnione w dokumentacji |
| Systemy budowania | Nixpacks, Dockerfile, obraz Docker | Nixpacks, Dockerfile, obraz Docker, Heroku Buildpacks, Paketo, Railpack |
| Odwrotny proxy | Traefik | Traefik |
| Zakres samodzielnie hostowanego monitoringu | Wbudowane metryki + przeglądarka logów | Podstawowe metryki zasobów + analiza logów/błędów budowania przez AI (v0.29.0+) |
Nasze zdanie: wybierz Dokploy, jeśli chcesz niższego narzutu w bezczynności, natywnego wsparcia wieloserwerowego i standardowej obsługi Docker Compose bez dostosowań specyficznych dla platformy. Wybierz Coolify, jeśli chcesz większej biblioteki aplikacji typu jeden klik, wsparcia ARM64/Raspberry Pi lub czystego Apache 2.0 bez przyszłego płatnego planu czającego się za rogiem.
Zużycie zasobów i dobór rozmiaru VPS
Samodzielnie hostowane PaaS może zaoszczędzić Ci kosztu Heroku. Jeśli warstwa orkiestracji zjada 1,5 GB z Twojego 2 GB VPS w bezczynności, nie zostaje Ci nic, na czym mógłbyś wdrażać. Więc pierwsze praktyczne pytanie na małym serwerze brzmi: ile każde narzędzie kosztuje Cię, zanim wdrożysz choćby jedną aplikację?
Zużycie RAM w bezczynności przez Coolify zależy od tego, jaki monitoring jest włączony, z bazowym śladem CPU na poziomie 5–7%, który skacze, gdy uruchamia się zbieranie metryk. Własna dokumentacja Coolify używa reprezentatywnego obciążenia produkcyjnego 8 GB RAM, 4 rdzenie i 150 GB pamięci masowej uruchamiającego 3 aplikacje Node.js, 4 statyczne witryny i kilka baz danych. To rozsądny punkt odniesienia dla doboru rozmiaru, jeśli Twój stos wygląda podobnie.
Dokploy natomiast działa znacznie lżej, znacznie poniżej 2% CPU, gdy nic się nie wdraża.
A Produkcyjne opracowanie LogRocket uruchamiające oba narzędzia obok siebie doszło do tego samego kierunkowego wniosku: docker stop && docker start na aplikacji Dokploy nie wyzwala pełnej przebudowy, podczas gdy ta sama operacja na Coolify owszem. To samo w sobie przesuwa koszt w stanie ustalonym na korzyść Dokploy, zwłaszcza na mniejszych planach VPS, gdzie burze przebudów zjadają Twój budżet CPU.
Co do doboru rozmiaru, oto konfiguracja VPS, którą bym polecił:
- Coolify, lekkie obciążenie: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, referencyjne obciążenie produkcyjne: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, lekkie obciążenie: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, zapas produkcyjny: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
Wskazówka pro: RAM w bezczynności Coolify skaluje się z konfiguracją monitoringu. Jeśli masz mało pamięci, zmniejsz interwał zbierania metryk (lub całkowicie wyłącz wbudowany monitoring, jeśli już uruchamiasz Prometheus/Grafana gdzie indziej), zanim udostępnisz większy serwer.
Realia wdrożeń: Docker Compose, Dockerfile i zero-downtime
Większość zespołów trafia do jednego z tych narzędzi z istniejącym docker-compose.yml , i z oczekiwaniem: wklej plik, kliknij wdróż, zobacz, jak aplikacja wstaje. To, jak każda platforma obsługuje standardowy Compose i co dzieje się z trwającymi żądaniami podczas kolejnego wdrożenia, jest miejscem, gdzie pojawia się praktyczna różnica.
Coolify obsługuje Docker Compose, Dockerfile, Nixpacks (autodetekcja z plików projektu) i bezpośrednie wdrożenia obrazu Docker. Jest jednak haczyk, o którym warto powiedzieć wprost: wdrożenia zero-downtime (rolling updates, blue/green) działają w Coolify tylko przez Dockerfile, Nixpacks lub wdrożenia pojedynczego obrazu. Nie działają przez Docker Compose. Opiekun Coolify potwierdził w dyskusji na GitHub , że „dla wdrożeń opartych na compose wszystkie kontenery są zatrzymywane przed uruchomieniem nowych, obecnie nie ma rolling update dla wdrożeń opartych na compose". Wsparcie rolling dla Compose jest w planach na v5; v4 go nie dostanie. Obejście sugerowane przez opiekuna to podzielenie stosu Compose na poszczególne usługi Coolify, co jest nietrywialną migracją, jeśli Twój plik Compose wyraża rzeczywiste relacje między usługami.
Konsekwencja widoczna dla użytkownika pojawia się w wątku na Hacker News o Coolify, gdzie jeden z operatorów ujął to dosadnie: „każde oczekujące żądanie, gdy aktualizujesz aplikację, jest po prostu zabijane". To jest dokładne dla dzisiejszych wdrożeń Compose.
Warstwa Compose w Coolify dodaje też to, co projekt nazywa „magicznymi zmiennymi". Oznacza to automatyczne wstrzykiwanie obrazów pomocniczych, przepisywanie sieci i nadpisania środowiska. Intencją jest większa wydajność; efektem ubocznym jest to, że docker-compose.yml który działa czysto na Twoim laptopie, czasem wymaga dostosowania, aby działać czysto na Coolify. Ten sam wątek na Hacker News ujawnia reprezentatywny przypadek: „Dodano 8 zmiennych w docker-compose, rozpoznawanych jest tylko 7". Jeśli Twój stos Compose jest mały i standardowy, możesz na to nie trafić. Jeśli jest duży lub nietypowy, trafisz.
Postawa Dokploy jest inna. Praktyczne opracowanie LogRocket praktyczne opracowanie wykazało, że Dokploy „potrafi wdrożyć istniejący docker-compose.yml z niewielkimi modyfikacjami lub bez nich" i trzyma się blisko natywnego modelu routingu Dockera opartego na etykietach. To samo opracowanie zauważa, że zatrzymanie/uruchomienie kontenera w Dokploy nie wyzwala pełnej przebudowy, podczas gdy ta sama akcja na Coolify owszem. To kierunkowy sygnał o zachowaniu w czasie wykonania, a nie formalna „gwarancja zero-downtime" z dokumentacji Dokploy, ale pokrywa się z tym, co zgłaszają osoby samodzielnie hostujące na mniejszych instancjach VPS.
Dokploy obsługuje też Heroku Buildpacks, Paketo Buildpacks i Railpack oprócz Nixpacks i Dockerfile. Dla zespołów przychodzących z Heroku z heroku.yml lub przepływami opartymi na buildpackach to ścieżka najmniejszego oporu.
Kluczowy wniosek z sekcji: jeśli Twoje istniejące usługi to prawdziwy stos Docker Compose, Coolify wymaga, byś albo zrestrukturyzował strategię wdrożenia, albo zaakceptował krótki przestój przy każdym pushu. Dokploy nie.
Bezpieczeństwo: ujawnienie CVE Coolify ze stycznia 2026
Szerszą historię odczytuję tak: Coolify jest dziś bezpieczny w użyciu, jeśli utrzymujesz go zaktualizowanym i nie wystawiasz panelu do publicznego internetu. Ujawnienie nie dyskwalifikuje projektu. Odpowiedzialne ujawnienie zostało zachowane, a łatki wyszły. Tym, co ujawnia, jest to, że powierzchnia ataku dostępna dla uwierzytelnionego użytkownika o niskich uprawnieniach była szersza, niż powinna. To lekcja projektowa dla projektu i lekcja operacyjna dla operatora: zaciśnij teraz model ekspozycji.
Wskazówka pro: nawet po załataniu traktuj swój panel Coolify jak SSH. Przypnij go do sieci prywatnej, posadź za VPN lub postaw przed nim Tailscale. Nie wystawiaj portu 8000 do publicznego internetu tylko dlatego, że skrypt instalacyjny to ułatwia.
Dokploy też nie jest wolny od tego rodzaju problemów. notatki o wydaniu v0.29.3 potwierdzają lukę w zabezpieczeniach zidentyfikowaną w Dokploy i dostarczają skrypt łatki bezpieczeństwa, który należy uruchomić wraz z aktualizacją. Mniejsza powierzchnia, krótsza historia projektu, ale obowiązuje ta sama dyscyplina operacyjna: aktualizuj w dniu, w którym wychodzą łatki, nie zostawiaj panelu w publicznym internecie.
Kluczowy wniosek z sekcji: historia CVE to żółta flaga dla praktyki operacyjnej Coolify, nie czerwona flaga przeciwko projektowi, ale podnosi poprzeczkę dla dyscypliny aktualizacji i tego, jak wystawiasz panel.
Licencjonowanie: co jest darmowe, a co nie
Licencja Dokploy została zrestrukturyzowana January 21, 2026. Oto co się zmieniło i co to oznacza dla osób samodzielnie hostujących.
Dokploy jest teraz standardowym Apache 2.0 dla rdzenia, zastępując wcześniejszy niestandardowy, dostosowany Apache 2.0, który mylił użytkowników co do tego, co było otwartoźródłowe, a co nie. Osobna Dokploy Source Available License rządzi teraz kodem w proprietary/ katalogach: widoczny kod źródłowy, płatny do użytku produkcyjnego. Funkcje, które według Dokploy znajdą się za tą licencją:
- Single Sign-On (SSO/SAML) i zaawansowana kontrola dostępu
- Niestandardowy branding i white-labeling
- Wysoka dostępność, auto-skalowanie i odzyskiwanie po awarii
- Zaawansowany monitoring, integracje i funkcje zgodności
Projekt wyraźnie zobowiązał się, że nigdy nie przeniesie istniejącej otwartoźródłowej funkcji do płatnego planu; przyszła płatna funkcjonalność jest skierowana do organizacji potrzebujących spoiwa klasy enterprise. 2FA już dziś znajduje się za planem Startup na stronie cenowej Dokploy.
Sytuacja Coolify jest prosta. Projekt jest Apache 2.0 na GitHub; każda funkcja w wersji samodzielnie hostowanej jest darmowa. Istnieje oferta Coolify Cloud dla zespołów, które chcą, by hostował to opiekun, ale wersja samodzielnie hostowana to kompletny produkt bez bramek funkcji i bez ścieżki aktualizacji do płatnego planu, którego dziś nie masz.
Mój odczyt: dla pojedynczych developerów i małych zespołów samodzielnie hostujących na własnym VPS Dokploy jest funkcjonalnie darmowy i taki pozostanie. Dla organizacji, która ostatecznie potrzebuje SSO, drobnoziarnistego RBAC, dzienników audytu lub white-labelingu, Dokploy w końcu popchnie Cię w stronę płatnego planu. Coolify nie, bo Coolify nie ma takiego planu w planach.
Wyjaśnienie warte zrobienia w oparciu o różne źródła: samodzielnie hostowana wersja Dokploy zawiera podstawowe metryki zasobów (CPU, pamięć, pamięć masowa, sieć), a v0.29.0 dodało analizę logów i błędów budowania wspomaganą przez AI. System monitoringu Dokploy jest dostępny tylko w chmurze dla bardziej zaawansowanych funkcji monitoringu. Monitoring jednak nadal działa lokalnie w instalacji samodzielnie hostowanej dla podstawowych metryk zasobów sprzed kontenera.
Wiele serwerów i klastrowanie: realia kontra marketing
Prędzej czy później jeden VPS to za mało, a oba projekty wyraźnie reklamują wsparcie wieloserwerowe na swoich stronach docelowych. Rzeczywistość w praktyce nie jest taka sama.
Coolify Oficjalna dokumentacja skalowalności Coolify jest co do tego bezpośrednia: wsparcie Docker Swarm jest oznaczone jako eksperymentalne. Standardowy wzorzec wieloserwerowy używa zweryfikowanych zdalnych serwerów połączonych przez SSH ze współdzielonym między nimi Docker Registry i instancjami Traefik działającymi na serwer. Tryb Swarm wymaga minimum trzech serwerów w tej samej architekturze (wszystkie ARM lub wszystkie AMD64). Kubernetes? „Tylko zaplanowane, ale jeszcze nie w planach, więc bez ETA". Jeśli przeczytasz własną stronę Coolify o tym, krótka wersja brzmi: wieloserwerowość działa, Swarm jest w fazie beta, a Kubernetes to wizja.
Dokploy dostarcza Docker Swarm jako tryb pierwszej klasy bez eksperymentalnej flagi. Traefik obsługuje routing zarówno w konfiguracjach jednoserwerowych, jak i Swarm. Wydanie v0.29.0 dodało wsparcie wieloserwerowe bez roota, co zamyka realną lukę (koniec z SSH tylko-jako-root przy dodawaniu zdalnych węzłów).
Jeśli klastrowanie wielowęzłowe to coś, czego będziesz potrzebować w ciągu najbliższych sześciu miesięcy, a nie „kiedyś na slajdzie", Dokploy jest dziś wyborem o niższym ryzyku.
Kluczowy wniosek z sekcji: jeśli klastrowanie jest w Twoich planach na bliską przyszłość, różnica w Swarm przechyla rekomendację w stronę Dokploy niezależnie od pozostałych osi.
Systemy budowania i wsparcie języków
Zespoły przychodzące z Heroku najbardziej zatroszczą się o to, które ekosystemy buildpacków obsługuje każde narzędzie, bo to decyduje, ile przepisywania potrzebuje Twój projekt przed pierwszym wdrożeniem.
Ścieżka budowania Coolify to Nixpacks (domyślna, autowykrywana z plików projektu), Dockerfile lub gotowy obraz Docker. Nixpacks jest solidny w typowych przypadkach (Node, Python, PHP, Go, Rust), ale autodetekcja ma chropowate krawędzie. Warto zweryfikować dla Twojego stosu: problem z Nixpacks ze stycznia 2026 dotyczący projektów Laravel z oboma composer.json oraz package.json wytwarzał zduplikowane bloki location Nginx, co psuło pewną klasę wdrożeń, dopóki upstream tego nie naprawił.
Dokploy obsługuje Nixpacks, Dockerfile i obraz Docker, a dodaje Heroku Buildpacks, Paketo Buildpacks i Railpack na wierzchu. Jeśli Twój projekt już buduje się czysto z heroku.yml lub buildpackiem, Dokploy pozwala Ci zachować ten przepływ pracy. Coolify poprosi Cię o konwersję.
Na powierzchni oba narzędzia wyglądają tak samo: wdrożenia Git-push z GitHub, GitLab, Bitbucket, automatyczny SSL Let's Encrypt, interfejs webowy do zmiennych środowiskowych i zarządzania bazami danych. Szerokość systemów budowania to jedno z nielicznych miejsc, gdzie Dokploy wyraźnie sięga dalej.
Katalogi aplikacji typu jeden klik
Dla operatorów nietechnicznych, którzy chcą wdrażać znane usługi otwartoźródłowe (n8n, Plausible, Supabase, Ghost, Listmonk, zwykła stajnia samohostingu), rozmiar biblioteki szablonów typu jeden klik jest realnym wyróżnikiem. Dla niektórych użytkowników jest to ważniejsze niż inne obszary, jak wydajność czy lekkość.
Coolify oferuje 300+ usług typu jeden klik w około 40 kategoriach: AI, analityka, automatyzacja, bazy danych, bezpieczeństwo, pamięć masowa i reszta. To zdecydowanie większa biblioteka i praktyczna odpowiedź dla niedeweloperów, którzy chcą wdrożyć usługę bez pisania pliku Compose.
Biblioteka szablonów Dokploy jest mniejsza. Obecna dokumentacja Dokploy nie publikuje czystej liczby, więc nie podam Ci liczby.
Praktyczna odpowiedź: jeśli Twój przepływ pracy to „wdróż n8n, Supabase i Plausible po dwa kliknięcia każde", Coolify wygrywa tę oś czysto. Jeśli piszesz własne aplikacje i po prostu chcesz je wdrożyć, rozmiar katalogu nie ma znaczenia, a pozostałe osie tak.
Jak wybrać: rekomendacje według przypadków użycia
Nie ma tu jednego zwycięzcy. Są dopasowania między narzędziem a kształtem wdrożenia:
- Zespół nietechniczny, który chce biblioteki usług: Coolify. Katalog 300+ szablonów to znacząca przewaga.
- Developer natywny dla Dockera, który chce lekkości + standardowej obsługi Compose: Dokploy.
- Sprzęt ARM64 (Raspberry Pi, VPS oparty na ARM): Coolify. Dokploy nie reklamuje wsparcia ARM64 w obecnej dokumentacji; jeśli jesteś na ARM, domyślnie wybierz Coolify, dopóki nie potwierdzisz inaczej.
- Klastrowanie wielowęzłowe, które wykorzystasz w tym kwartale: Dokploy. Natywny Swarm kontra eksperymentalny Swarm to czynnik przesądzający.
- Czysty Apache 2.0, bez możliwego przyszłego płatnego planu: Coolify.
- Migracja z Heroku i chęć zachowania Heroku Buildpacks: Dokploy.
- Zaniepokojony CVE ze stycznia 2026: zaktualizowany Coolify (v4.0.0+) jest w porządku. Prawdziwe pytanie to Twój model ekspozycji. Jeśli nie możesz przypiąć panelu do sieci prywatnej lub VPN, Dokploy jest wyborem mniej stresującym: mniejsza powierzchnia i krótsza historia ujawnień o wysokim stopniu zagrożenia.
Uwaga o wdrażaniu obu narzędzi
Gdy już wybierzesz, sama instalacja to jedna komenda w obu projektach, ale jest skrót warty poznania. Zarówno Coolify, jak i Dokploy są dostępne jako wdrożenia typu jeden klik w nasz marketplace, z preinstalowanym Ubuntu 24.04 i Dockerem oraz już dostępnym panelem. Jeśli chcesz pominąć ręczną konfigurację, oferty z marketplace dla Coolify oraz Dokploy są najszybszą ścieżką. Jeśli wolisz zacząć od czystego systemu i samodzielnie uruchomić oficjalny instalator, oba projekty publikują jednolinijkowy skrypt; wybierz ten, który pasuje do Twojego przepływu udostępniania.
Często zadawane pytania
Czy Dokploy jest nadal otwartoźródłowy po zmianie licencji w 2026?
Tak, dla rdzennej platformy. Z dniem January 21, 2026 rdzeń Dokploy to standardowy Apache 2.0. Osobna Dokploy Source Available License rządzi teraz kodem w proprietary/ katalogach, obecnie obejmując przyszłe funkcje enterprise (SSO/SAML, drobnoziarnisty RBAC, dzienniki audytu, white-labeling). Dla samodzielnego hostowania przez pojedyncze osoby i małe zespoły Dokploy jest funkcjonalnie otwartoźródłowy.
Czy luki w zabezpieczeniach Coolify ze stycznia 2026 są nadal powodem do niepokoju?
11 ujawnionych CVE jest załatanych w Coolify v4.0.0 (wydanym April 27, 2026). Jeśli używasz v4.0.0 lub nowszego, ujawnione luki są usunięte. Pozostaje ekspozycja: utrzymuj Coolify zaktualizowany i nie wystawiaj panelu do publicznego internetu. Przypnij go do sieci prywatnej lub posadź za VPN.
