Ha már elhagyta a menedzselt PaaS-t, a VPS-e ki van építve, az SSH-kulcs hozzá van adva, és a terminálkurzora a telepítési soron villog. Az egyetlen hátralévő kérdés: melyiket futtatja, curl ... | bash a Coolify esetében, vagy a Dokploy esetében?
Mindkét eszköz egyetlen paranccsal telepíthető. Mindkettő Git-push telepítést, automatikus SSL-t, webes felületet és fordított proxyt biztosít a Docker tetején. Az érdekes különbségek azok, amelyek éles üzemben mutatkoznak meg: hogyan kezeli mindegyik egy standard docker-compose.yml, mi történik egy telepítés során, és hogyan reagált mindegyik projekt arra a hírre, amely 2026-ban átformálta ezt az összehasonlítást. Két hír viseli itt a legnagyobb súlyt: a Coolify CVE-közzétételei 2026 januárjában és a Dokploy licenc-átalakítás ugyanezen hónapban.
Ez a bejegyzés mindegyik eszközt egy konkrét felhasználási esethez illeszti, ahelyett, hogy győztest hirdetne. A végére remélhetőleg tudni fogja, melyik illik a munkafolyamatához.
Röviden
- Coolify idősebb, nagyobb ökoszisztémával (~55k GitHub-csillag, 300+ egykattintásos szolgáltatássablon), tétlen állapotban nehezebb, végig Apache 2.0, fizetős szint nélkül az önállóan üzemeltetett oldalon.
- Dokploy fiatalabb (~34k csillag), tétlen állapotban könnyebb, Apache 2.0 mag, plusz egy külön Source Available License, amely a jövőbeli fizetős funkciókat (SSO, RBAC, audit naplók, white-labeling) szabályozza.
- A Coolify ma nem tud zéró állásidős telepítéseket végezni Docker Compose-on keresztül; csak Dockerfile, Nixpacks vagy egyképes telepítések révén. A Dokploy a Docker Swarmot elsőosztályú módként szállítja; a Coolify Swarm-ja kísérleti jelzéssel van ellátva.
- A 2026 januári Coolify CVE-k a v4.0.0 (April 27, 2026) verzióban vannak javítva. Frissítse a Coolifyt, és ne tegye nyilvánosan elérhetővé a vezérlőpultot.
Amikor egyik eszköz sem a megfelelő válasz
A Coolify és a Dokploy is rossz formájú bizonyos beállításokhoz. Három alternatíva, amelyet érdemes ismerni, röviden:
- Kamal (a 37signals-tól): olyan csapatoknak, amelyek egy vagy két alkalmazással rendelkeznek, és semmilyen felületet nem akarnak; csak
kamal deploya laptopjáról. Jóval egyszerűbb, mint a Coolify vagy a Dokploy, és a helyes választás, ha nem akar vezérlőpultot. - Dokku: a klasszikus, Git-push, egyszerveres modell. Régebbi, kisebb hatókörű, nagyon stabil. Az eredeti „Heroku egy VPS-en".
- GitHub Actions + Docker Compose egy csupasz VPS-en: a lehető legkisebb stack. Nincs orchestrációs felület, de orchestrációs többletteher sincs. Jó egyetlen alkalmazáshoz, ahol a telepítési folyamat
docker compose pull && docker compose up -dCI-ből indítva.
Ha az Ön formája egy alkalmazás egy szerveren, a Coolify és a Dokploy is valószínűleg túlzás; próbálja ki előbb a fentiek valamelyikét. Ha több alkalmazása, több adatbázisa van, vagy olyan csapata, amelyben nem műszaki tagok is vannak, akiknek felületre van szükségük a dolgok kezeléséhez, akkor a Coolify-vs-Dokploy döntés a megfelelő. A kategória lehetőségeinek szélesebb áttekintéséért lásd az összeállításunkat: saját üzemeltetésű felhő platformok webes felülettel.
Coolify és Dokploy egy pillantásra
A Coolify v4.0.0 stabil April 27, 2026-án jelent meg, egy hosszú béta ciklus után. A Dokploy a v0.29.4 verziónál tart May 11, 2026 szerint. Mindkettő nyílt forráskódú, önállóan üzemeltetett PaaS-projekt a Heroku/Render/Vercel-alternatíva térben, mindkettő Docker-t csomagol egy felülettel, egy alapból HTTPS-es fordított proxyval (Traefik) és Git-alapú telepítésekkel.
| Funkció | Coolify | Dokploy |
|---|---|---|
| Legújabb stabil kiadás | v4.0.0 (April 27, 2026) | v0.29.4 (May 11, 2026) |
| Licenc | Apache 2.0 | Apache 2.0 mag + Source Available a fizetős funkciókhoz |
| Technológiai stack | PHP / Laravel | TypeScript / Node.js |
| GitHub-csillagok | ~55,000 | ~34,000 |
| Minimális RAM (hivatalos) | 2 GB | 2 GB |
| Minimális CPU (hivatalos) | 2 mag | nincs megadva |
| Tétlen RAM (közösség által jelentett) | 500 MB – 1.2 GB | 300 – 400 MB |
| Docker Compose zéró állásidő | Nem támogatott (csak Dockerfile/Nixpacks) | Standard Compose-kezelés |
| Több szerveres fürtözés | Docker Swarm (kísérleti) | Docker Swarm (natív) |
| ARM64-támogatás | Igen (beleértve a Raspberry Pi OS-t) | A dokumentációban nincs hirdetve |
| Build rendszerek | Nixpacks, Dockerfile, Docker image | Nixpacks, Dockerfile, Docker image, Heroku Buildpacks, Paketo, Railpack |
| Fordított proxy | Traefik | Traefik |
| Önállóan üzemeltetett monitorozás hatóköre | Beépített metrikák + naplónézegető | Alapvető erőforrás-metrikák + AI napló-/buildhiba-elemzés (v0.29.0+) |
A mi álláspontunk: válassza a Dokployt, ha alacsonyabb tétlen többletterhet, natív több szerveres támogatást és standard Docker Compose-kezelést szeretne platformspecifikus igazítgatás nélkül. Válassza a Coolifyt, ha a nagyobb egykattintásos alkalmazáskönyvtárat, ARM64/Raspberry Pi támogatást, vagy tiszta Apache 2.0-t szeretne anélkül, hogy a háttérben egy jövőbeli fizetős szint várakozna.
Erőforrás-lábnyom és VPS-méretezés
Egy önállóan üzemeltetett PaaS megspórolhatja Önnek a Heroku költségét. Ha az orchestrációs réteg 1.5 GB-ot felemészt a 2 GB-os VPS-éből tétlen állapotban, akkor semmi nem marad, amire telepíthetne. Tehát az első gyakorlati kérdés egy kis szerveren: mennyibe kerül mindegyik eszköz, mielőtt egyetlen alkalmazást is telepítene?
A Coolify tétlen RAM-használata attól függ, hogy milyen monitorozás van engedélyezve, 5–7% alap CPU-lábnyommal, amely megugrik, amikor a metrikák lekérdezése fut. A Coolify saját dokumentációja egy reprezentatív éles munkaterhelést használ, 8 GB RAM-mal, 4 maggal és 150 GB tárhellyel, amelyen 3 Node.js alkalmazás, 4 statikus webhely és néhány adatbázis fut. Ez egy ésszerű méretezési referencia, ha az Ön stackje hasonlóan néz ki.
A Dokploy ezzel szemben sokkal könnyebben fut, jóval 2% CPU alatt, amikor semmi sem telepít.
A LogRocket éles üzemi beszámoló amely mindkét eszközt egymás mellett futtatta, ugyanarra az irányadó következtetésre jutott: egy docker stop && docker start egy Dokploy alkalmazáson nem vált ki teljes újraépítést, míg ugyanaz a művelet a Coolify esetében igen. Ez önmagában a Dokploy javára tolja az állandósult állapotú költséget, különösen a kisebb VPS-csomagokon, ahol az újraépítési viharok felfalják a CPU-keretét.
A méretezéshez itt van a VPS-beállítás, amelyet ajánlanék:
- Coolify, könnyű munkaterhelés: 2 vCPU / 4 GB RAM / 120 GB NVMe is the practical starting point for Coolify plus a couple of small apps.
- Coolify, éles üzemi referencia-munkaterhelés: 4 vCPU / 8 GB RAM / 160 GB NVMe to match Coolify's own documented 3 Node.js + 4 static sites + databases example.
- Dokploy, könnyű munkaterhelés: 1 vCPU / 2 GB RAM / 60 GB NVMe is comfortable for a single small app.
- Dokploy, éles üzemi tartalék: 2 vCPU / 4 GB RAM / 120 GB NVMe gives you room for a small production stack.
Profi tipp: a Coolify tétlen RAM-ja a monitorozási konfigurációval skálázódik. Ha szűkösen áll a memóriával, csökkentse a metrikák lekérdezési intervallumát (vagy tiltsa le teljesen a beépített monitorozást, ha máshol már futtat Prometheus/Grafana-t), mielőtt nagyobb szervert építene ki.
A telepítés valósága: Docker Compose, Dockerfile és zéró állásidő
A legtöbb csapat egy meglévő docker-compose.yml és egy elvárás birtokában érkezik ezen eszközök egyikéhez: illessze be a fájlt, kattintson a telepítésre, lássa, ahogy az alkalmazás elindul. Az, hogy mindegyik platform hogyan kezeli a standard Compose-t, és mi történik a folyamatban lévő kérésekkel a következő telepítés során, ott mutatkozik meg a gyakorlati különbség.
A Coolify támogatja a Docker Compose-t, Dockerfile-t, Nixpacks-et (automatikus felismerés a projektfájlokból) és a közvetlen Docker image telepítéseket. Van azonban egy bökkenő, amelyet érdemes egyértelműen kimondani: a zéró állásidős telepítések (gördülő frissítések, blue/green) a Coolifyban csak Dockerfile, Nixpacks vagy egyképes telepítések révén működnek. Docker Compose-on keresztül nem működnek. Egy Coolify-karbantartó megerősítette egy GitHub-vitában hogy „a compose-alapú telepítéseknél minden konténer leáll az újak indítása előtt, jelenleg nincs gördülő frissítés a compose-alapú telepítésekhez". A Compose gördülő támogatása a v5 ütemtervén szerepel; a v4 nem fogja megkapni. A karbantartó által javasolt megkerülő megoldás az, hogy egy Compose-stacket egyedi Coolify-szolgáltatásokra bontson, ami nem triviális migráció, ha a Compose-fájlja valódi szolgáltatások közötti kapcsolatokat fejez ki.
A felhasználó által érzékelhető következmény egy Hacker News szálban a Coolifyról, ahol egy üzemeltető nyersen fogalmazott: „bármilyen függőben lévő kérés, amikor frissít egy alkalmazást, egyszerűen megszakad". Ez pontos a Compose-telepítésekre ma.
A Coolify Compose-rétege hozzáad még valamit, amit a projekt „varázsváltozóknak" nevez. Ez segédképek automatikus injektálását, hálózati átírásokat és környezeti felülbírálásokat jelent. A szándék az, hogy hatékonyabb legyen; a mellékhatás az, hogy egy docker-compose.yml amely tisztán fut a laptopján, néha igazításra szorul, hogy tisztán fusson a Coolifyon. Ugyanaz a Hacker News szál felszínre hoz egy reprezentatív esetet: „8 változót adtam hozzá a docker-compose-ban, csak 7 ismerődik fel". Ha a Compose-stackje kicsi és standard, lehet, hogy nem ütközik ezekbe. Ha nagy vagy szokatlan, akkor igen.
A Dokploy hozzáállása más. A LogRocket gyakorlati beszámolója azt találta, hogy a Dokploy „kevés vagy semmilyen módosítással tud telepíteni egy meglévő docker-compose.yml-t", és közel marad a Docker natív címkealapú útválasztási modelljéhez. Ugyanaz a beszámoló megjegyzi, hogy a konténer leállítása/indítása a Dokployban nem vált ki teljes újraépítést, míg ugyanaz a művelet a Coolify esetében igen. Ez inkább a futásidejű viselkedésről szóló irányadó jelzés, mintsem formális „zéró állásidő garancia" a Dokploy dokumentációból, de összhangban van azzal, amit az önálló üzemeltetők kisebb VPS-példányokon jelentenek.
A Dokploy a Nixpacks és Dockerfile mellett a Heroku Buildpacks, Paketo Buildpacks és Railpack megoldásokat is támogatja. A Herokuból érkező csapatok számára, akik heroku.yml vagy buildpack-alapú munkafolyamatokkal dolgoznak, ez a legkisebb ellenállás útja.
A szakasz fő tanulsága: ha a meglévő szolgáltatásai egy valódi Docker Compose-stack, a Coolify arra kényszeríti, hogy vagy átstrukturálja a telepítési stratégiáját, vagy elfogadjon rövid állásidőt minden push-nál. A Dokploy nem.
Biztonság: a 2026 januári Coolify CVE-közzétételek
Én így olvasom a tágabb történetet: a Coolify ma biztonságosan futtatható, ha frissen tartja, és nem teszi ki a vezérlőpultot a nyilvános internetnek. A közzététel nem zárja ki a projektet. A felelős közzétételt betartották, és a javítások kimentek. Amit valóban feltár, az az, hogy egy alacsony jogosultságú hitelesített felhasználó számára elérhető támadási felület szélesebb volt, mint kellett volna. Ez tervezési lecke a projektnek és üzemeltetési lecke az üzemeltetőnek: szigorítsa most a kitettségi modellt.
Profi tipp: még a javítás után is kezelje a Coolify vezérlőpultját úgy, mint az SSH-t. Kösse egy privát hálózathoz, helyezze egy VPN mögé, vagy tegye elé a következőt: Tailscale. Ne tegye ki a 8000-es portot a nyilvános internetnek csak azért, mert a telepítőszkript megkönnyíti.
A Dokploy sem mentes ettől a fajta problémától. A v0.29.3 kiadási megjegyzések elismernek egy a Dokployban azonosított biztonsági sebezhetőséget, és egy biztonsági javítószkriptet szállítanak, amelyet a frissítés mellett kell futtatnia. Kisebb felület, rövidebb projektmúlt, de ugyanaz az üzemeltetési fegyelem érvényes: frissítsen azon a napon, amikor a javítások megjelennek, ne hagyja a vezérlőpultot a nyilvános interneten.
A szakasz fő tanulsága: a CVE-történet sárga zászló a Coolify üzemeltetési gyakorlatára, nem piros zászló a projekt ellen, de magasabbra teszi a lécet a frissítési fegyelemben és abban, ahogyan a vezérlőpultot kiteszi.
Licencelés: mi ingyenes, mi nem
A Dokploy licence January 21, 2026-án átalakult. Íme, mi változott, és mit jelent ez az önálló üzemeltetőknek.
A Dokploy mostantól standard Apache 2.0 a mag esetében, felváltva a korábbi nem standard, módosított Apache 2.0-t, amely összezavarta a felhasználókat azzal kapcsolatban, hogy mi nyílt forráskódú, és mi nem. Egy külön Dokploy Source Available License mostantól a következő könyvtárakban lévő kódot szabályozza: proprietary/ könyvtárak: látható forrás, fizetős éles üzemi használatra. A funkciók, amelyekről a Dokploy azt mondja, hogy ezen licenc mögött lesznek:
- Single Sign-On (SSO/SAML) és fejlett hozzáférés-vezérlés
- Egyéni márkajelzés és white-labeling
- Magas rendelkezésre állás, automatikus skálázás és katasztrófa-helyreállítás
- Fejlett monitorozás, integrációk és megfelelőségi funkciók
A projekt kifejezetten elkötelezte magát amellett, hogy soha nem helyez át egy meglévő nyílt forráskódú funkciót a fizetős szintbe; a jövőbeli fizetős funkciókat azoknak a szervezeteknek szánják, amelyeknek nagyvállalati összekötő elemekre van szükségük. A 2FA ma már a Startup szint mögött ül a Dokploy árazási oldalán.
A Coolify helyzete egyértelmű. A projekt Apache 2.0 a GitHubon; az önállóan üzemeltetett verzió minden funkciója ingyenes. Van egy Coolify Cloud ajánlat azoknak a csapatoknak, akik azt akarják, hogy a karbantartó üzemeltesse, de az önállóan üzemeltetett verzió egy teljes termék, funkciókorlátok nélkül és anélkül, hogy egy fizetős szintre kellene frissíteni, amellyel ma nem rendelkezik.
Az én olvasatom: az önálló fejlesztők és kis csapatok számára, akik saját VPS-ükön üzemeltetnek, a Dokploy gyakorlatilag ingyenes, és az is marad. Egy olyan szervezet számára, amelynek végül SSO-ra, finomhangolt RBAC-ra, audit naplókra vagy white-labelingre van szüksége, a Dokploy végül egy fizetős szint felé fogja terelni. A Coolify nem, mert a Coolifynak nincs ilyen szintje az ütemtervén.
Egy forrásközi pontosítás, amelyet érdemes megtenni: a Dokploy önállóan üzemeltetett buildje tartalmaz alapvető erőforrás-metrikákat (CPU, memória, tárhely, hálózat), és a v0.29.0 hozzáadta az AI-alapú napló- és buildhiba-elemzést. A Dokploy monitorozási rendszere csak felhőben érhető el a fejlettebb monitorozási funkciókhoz. A monitorozás azonban továbbra is helyileg fut egy önállóan üzemeltetett telepítésen az alapvető, konténer előtti erőforrás-metrikákhoz.
Több szerveres üzemeltetés és fürtözés: valóság vs marketing
Előbb-utóbb egyetlen VPS nem lesz elég, és mindkét projekt feltűnően reklámozza a több szerveres támogatást a kezdőlapjain. A valóság a terepen nem ugyanaz.
A Coolify hivatalos skálázhatósági dokumentációja egyenes ebben: a Docker Swarm támogatása kísérleti jelzéssel van ellátva. A standard több szerveres minta SSH-n keresztül csatlakoztatott, validált távoli szervereket használ, közöttük megosztott Docker Registry-vel, és szerverenként futó Traefik-példányokkal. A Swarm mód minimum három szervert igényel ugyanabban az architektúrában (mind ARM, vagy mind AMD64). Kubernetes? „Csak tervezve van, de még nincs az ütemtervben, így nincs ETA." Ha elolvassa a Coolify saját oldalát erről, a rövid változat: a több szerveres üzemeltetés működik, a Swarm béta, és a Kubernetes egy vízió.
A Dokploy a Docker Swarmot elsőosztályú módként szállítja kísérleti jelző nélkül. A Traefik kezeli az útválasztást mind az egyszerveres, mind a Swarm beállításokban. A v0.29.0 kiadás hozzáadta a nem root több szerveres támogatást, ami egy valódi hiányosságot zár be (nincs többé csak root SSH a távoli csomópontok hozzáadásához).
Ha a több csomópontos fürtözésre a következő hat hónapban szüksége lesz, nem pedig „egyszer egy diavetítésen", a Dokploy ma az alacsonyabb kockázatú választás.
A szakasz fő tanulsága: ha a fürtözés a közeli ütemtervén szerepel, a Swarm-különbség a Dokploy felé fordítja az ajánlást a többi tengelytől függetlenül.
Build rendszerek és nyelvi támogatás
A Herokuból érkező csapatokat leginkább az érdekli, hogy melyik buildpack-ökoszisztémát támogatja mindegyik eszköz, mert ez dönti el, mennyit kell átírni a projektjén az első telepítése előtt.
A Coolify build útvonala a Nixpacks (alapértelmezett, automatikusan felismerve a projektfájljaiból), Dockerfile vagy egy előre elkészített Docker image. A Nixpacks szilárd az általános esetekhez (Node, Python, PHP, Go, Rust), de az automatikus felismerésnek vannak érdes peremei. Érdemes ellenőrizni a stackjéhez: egy 2026 januári Nixpacks-probléma, amely a Laravel-projekteket érintette, mindkettővel composer.json és package.json duplikált Nginx location-blokkokat eredményezett, ami a telepítések egy osztályát megtörte, amíg az upstream ki nem javította.
A Dokploy támogatja a Nixpacks-et, Dockerfile-t és Docker image-et, és ezen felül hozzáadja a Heroku Buildpacks, Paketo Buildpacks és Railpack megoldásokat. Ha a projektje már tisztán épül a következővel: heroku.yml vagy egy buildpack-kel, a Dokploy lehetővé teszi, hogy megtartsa azt a munkafolyamatot. A Coolify átalakításra fogja kérni.
A felszínen mindkét eszköz egyformának tűnik: Git-push telepítések a GitHubról, GitLabról, Bitbucketről, automatikus Let's Encrypt SSL, webes felület a környezeti változókhoz és az adatbázis-kezeléshez. A build-rendszer szélessége egyike azon kevés helyeknek, ahol a Dokploy egyértelműen tovább nyúlik.
Egykattintásos alkalmazáskatalógusok
A nem műszaki üzemeltetők számára, akik ismert nyílt forráskódú szolgáltatásokat (n8n, Plausible, Supabase, Ghost, Listmonk, a szokásos önállóan üzemeltetett klasszikusok) szeretnének telepíteni, az egykattintásos sablonkönyvtár mérete valódi megkülönböztető tényező. Egyes felhasználók számára ez fontosabb, mint más területek, mint a teljesítmény vagy a könnyűsúly.
A Coolify 300+ egykattintásos szolgáltatást kínál nagyjából 40 kategóriában: AI, analitika, automatizálás, adatbázisok, biztonság, tárolás és a többi. Ez a nagyobb könyvtár jelentős mértékben, és a gyakorlati válasz a nem fejlesztők számára, akik egy szolgáltatást szeretnének telepíteni Compose-fájl írása nélkül.
A Dokploy sablonkönyvtára kisebb. A jelenlegi Dokploy dokumentáció nem tesz közzé tiszta számot, így nem fogok számot adni Önnek.
A gyakorlati válasz: ha a munkafolyamata „telepíts n8n-t, Supabase-t és Plausible-t két-két kattintással", a Coolify tisztán nyeri ezt a tengelyt. Ha saját alkalmazásokat ír, és csak telepíteni szeretné őket, a katalógus mérete nem számít, a többi tengely viszont igen.
Hogyan válasszunk: felhasználási eset szerinti ajánlások
Itt nincs egyetlen győztes. Vannak egyezések egy eszköz és egy telepítési forma között:
- Nem műszaki csapat, amely szolgáltatáskönyvtárat szeretne: Coolify. A 300+ sablonkatalógus jelentős előny.
- Docker-natív fejlesztő, aki könnyűsúlyt + standard Compose-kezelést szeretne: Dokploy.
- ARM64 hardver (Raspberry Pi, ARM-alapú VPS): Coolify. A Dokploy nem hirdet ARM64-támogatást a jelenlegi dokumentációban; ha ARM-en van, alapértelmezzen a Coolifyra, amíg az ellenkezőjét meg nem erősítette.
- Több csomópontos fürtözés, amelyet ebben a negyedévben fog használni: Dokploy. A natív Swarm vs. kísérleti Swarm a döntő tényező.
- Tiszta Apache 2.0, semmilyen lehetséges jövőbeli fizetős szint: Coolify.
- Herokuból migrál, és meg akarja tartani a Heroku Buildpacks-et: Dokploy.
- Aggódik a 2026 januári CVE-k miatt: egy frissített Coolify (v4.0.0+) rendben van. Az igazi kérdés a kitettségi modellje. Ha nem tudja a vezérlőpultot egy privát hálózathoz vagy VPN-hez kötni, a Dokploy a kevésbé stresszes választás: kisebb felület és a magas súlyosságú közzétételek rövidebb története.
Megjegyzés mindkét eszköz telepítéséről
Miután választott, maga a telepítés egyetlen parancs mindkét projektnél, de van egy parancsikon, amelyet érdemes ismerni. A Coolify és a Dokploy is elérhető egykattintásos telepítésként a következőben: a marketplace-unk, Ubuntu 24.04-gyel és előtelepített Dockerrel, a vezérlőpult pedig már elérhető. Ha ki akarja hagyni a manuális beállítást, a marketplace-listák a következőhöz: Coolify és Dokploy a leggyorsabb út. Ha inkább egy tiszta operációs rendszerről indulna, és maga futtatná a hivatalos telepítőt, mindkét projekt közzétesz egy egysoros szkriptet; válassza azt, amelyik illik a kiépítési munkafolyamatához.
Gyakran ismételt kérdések
A Dokploy még mindig nyílt forráskódú a 2026-os licencváltozás után?
Igen, a mag platform esetében. January 21, 2026-tól hatályosan a Dokploy magja standard Apache 2.0. Egy külön Dokploy Source Available License mostantól a következő könyvtárakban lévő kódot szabályozza: proprietary/ könyvtárak, jelenleg a jövőbeli nagyvállalati funkciókra (SSO/SAML, finomhangolt RBAC, audit naplók, white-labeling) korlátozva. Az önálló és kis csapatos, önállóan üzemeltetett használathoz a Dokploy gyakorlatilag nyílt forráskódú.
A 2026 januári Coolify biztonsági sebezhetőségek továbbra is aggályosak?
A 11 közzétett CVE a Coolify v4.0.0 (April 27, 2026-án kiadva) verzióban van javítva. Ha v4.0.0 vagy újabb verziót futtat, a közzétett sebezhetőségek kezelve vannak. Ami marad, az a kitettség: tartsa frissen a Coolifyt, és ne tegye ki a vezérlőpultot a nyilvános internetnek. Kösse egy privát hálózathoz, vagy helyezze egy VPN mögé.
