Portainer-alternatívák: használati esetek szerinti útmutató a Dockge, Arcane, Dockhand és Komodo eszközökhöz

A Portainer 2026-ban is jó választás, ha ismerős Docker-kezelő felületet, széles futtatókörnyezet-támogatást és olyan eszközt szeretnél, amely az egyszerű, egygépes beállításnál többet is elbír. Ha a jelenlegi rendszeredhez csak alapvető konténerkezelés, Compose stackek, alap hozzáférés-szabályozás és több környezet átlátása kell, a Portainer CE-től nem kell sietve elszakadnod.

Ugyanakkor a Portainer megszűnik a legtisztább választás lenni, amint ingyenes OIDC/SSO, fájlközpontú Compose-kezelés, beépített sebezhetőségvizsgálat vagy Git-vezérelt, több szerverre kiterjedő munkafolyamat kell, anélkül hogy átlépnél a Portainer Business Editionre. Innentől kezdenek értelmet nyerni az ebben az útmutatóban szereplő alternatívák.

A rövid válasz tehát ez: ha a Portainer már illik a használati esetedhez, maradj nála. Ha pedig szeretnéd megspórolni a kézi beállítást, a Cloudzy egykattintásos Portainer alkalmazásával néhány kattintással elindíthatod a Portainert egy VPS-en, root hozzáféréssel, NVMe tárhellyel és Dockerre kész környezettel. Ha viszont beleütköztél a Portainer CE valamelyik korlátjába, a cikk hátralévő része a megfontolásra érdemes alternatívákról szól: Dockge, Arcane, Dockhand és Komodo.

Röviden

• Dockge ha egygépes homelabot üzemeltetsz, és azt szeretnéd, hogy a compose fájljaid egyszerű YAML-ként legyenek láthatók a lemezen.
• Arcane ha ingyenes OIDC/SSO és egyetlen binárisból álló telepítés kell egy kis csapatnak.
• Dockhand ha beépített sebezhetőségvizsgálatot és biztonságosabb image-letöltéseket szeretnél a Portainer BE megvásárlása nélkül, és együtt tudsz élni egy BSL licenccel.
• Komodo ha több VPS-példányon futtatsz Dockert, és a Gitet szeretnéd egyetlen igazságforrásként használni.
• Portainer CE ha a fentiek egyikére sincs szükséged.

Amit ez a cikk nem tárgyal

Néhány kategória szándékosan kimarad ebből az összehasonlításból. A Coolify és a Dokploy PaaS eszközök: saját üzemeltetésű Heroku akarnak lenni, nem Docker-felületek. Ez más probléma. A Rancher és az OpenShift Kubernetes-klaszterkezelők, ami rossz léptékű egy-két VPS-t használó közönségnek. A Lazydocker kiváló, de csak TUI, vagyis másik UX-kategória. Az UsulNet pedig, amely néhány másik összehasonlító cikkben felbukkan, 2026 februárjában az első nyilvános bétánál tart egyetlen fejlesztővel: túl korai ahhoz, hogy valódi kiadási ciklusokat maga mögött tudó eszközök mellett ajánljuk.

Miért hagyják ott az emberek a Portainert

Ami elsőként elüldözi az embereket a Portainertől, az nem hiba. Sok haladó csapat- és vállalati funkció a Business Edition oldalán található, köztük:

• OIDC
• részletes RBAC
• AD/LDAP
• GitOps
• Automatikus frissítések
• Auditnaplók
• Registry-kezelés
• Kubernetes-klaszterek kiépítése

Egyedül dolgozó homelab-felhasználóként talán hidegen hagy. Egy háromfős üzemeltetői csapatnál, amely SSO-t és auditnyomvonalat akar, azonnal számít.

A Portainer kínál három ingyenes Business Edition csomópontot. Ez pici rendszereknél tényleg hasznos. Három csomópont fölött már az „árajánlatért keressen minket” terepen jársz. Konkrét összeget nem írok ide, mert a nyilvános szám folyamatosan változik, és a helyes válasz az, hogy a vásárláskor nézd meg az áraikat tartalmazó oldalt.

A második ok architekturális. A Portainer webes szerkesztőjében létrehozott stackek a Portainer adatbázisában tárolódnak, míg a Git alapú telepítéseknél a repó marad a külső forrás. Ez addig rendben van, amíg kifejezetten nem azt akarod, hogy minden helyben kezelt Compose stack közönséges YAML fájlként látszódjon a gazdagépen. Az olyan eszközök, mint a Dockge, alapértelmezetté teszik ezt a fájlközpontú modellt: a Compose fájljaid a lemezen élnek, a felület pedig azt kezeli, ami már ott van. Hogy ez számít-e, attól függ, hogyan szeretnéd kezelni és menteni a stackjeidet.

A harmadik ok a felület súlya. A Portainert úgy építették, hogy elbírja a Dockert, a Swarmot, a Kubernetest, a több környezetre kiterjedő ügynökflottákat és a többit. Összetett környezetekre skálázódik, és épp ezért találhatja egy egygépes homelab-felhasználó nehézkesebbnek annál, mint amire szüksége van. Az XDA Developers cikke a Dockge-hoz való visszatérésről jól fogalmazza meg: a Portainernek akkor van értelme, amikor még az elején jársz, és kell a teljes funkciókészlet; ha a rendszered stabilizálódott, jobban illhet hozzá egy kisebb eszköz, amely tiszteletben tartja a stackjeid fájlalapú felépítését.

A négy eszköz, amely valóban versenyben van

Tucatnyi „Docker UI” kering a GitHubon. Sok közülük elhagyatott, még bétában van, vagy más problémát old meg. Az itt tárgyalt négy fedi le legvilágosabban azt, amit a Portainer ennek a közönségnek alapvetően nyújt: a Docker kezelését egy vagy több VPS gazdagépen, webes felületen keresztül, elegendő képességgel a napi használathoz.

Az alábbiakban végigveszem az egyes eszközöket, azzal kezdve, ami megkülönbözteti őket, és kitérek a korlátaikra is.

Dockge: fájlközpontú Compose-kezelés

A Dockge lényege egyetlen tervezési döntés: a compose stackjeid egyszerű YAML fájlként a lemezen élnek, nem adatbázisban. Ugyanúgy catelheted, vimmel szerkesztheted, git commitolhatod vagy rsyncelheted őket, mint bármelyik másik konfigurációt. A felület nézegető és szerkesztő ahhoz, ami már ott van.

A szerző Louis Lam, ugyanaz, aki az Uptime Kumát is karbantartja. Ez hasznos jelzés, mert az Uptime Kuma szilárd, drámamentes karbantartásáról ismert, és a Dockge ezt a stílust örökli. A legutóbbi kiadás a v1.5.0 (2025. március 30.), a Dockge GitHub releases oldala szerint szerint. A v1.4.0 hozta el az első többügynökös támogatást; a v1.5.0 egy törést okozó biztonsági változást szállít: a böngészőbeli konzol alapértelmezés szerint kikapcsolt, és a DOCKGE_ENABLE_CONSOLE=true beállítással kapcsolhatod vissza, ha szeretnéd. Ugyanebben a kiadásban a Compose 2.34.0-ra frissült.

Nincs OIDC, nincs RBAC, nincs beépített sebezhetőségvizsgálat, nincs auditnaplózás. A Dockge nem akar olcsó Portainer BE lenni. Azt akarja, hogy a legkisebb, legletisztultabb eszköz legyen a compose stackek kezelésére egyetlen gazdagépen (vagy néhányon, a többügynökös móddal).

Egy fenntartást érdemes kimondani: a Dockge nem feltétlenül takarékosabb a RAM-mal. Egy GitHub-vitaszál 2024 szeptemberétől 2025 decemberéig dokumentálja, hogy felhasználók 500MB+ fogyasztást jelentettek kis rendszereknél, és a vita lezáratlan, ezért teszteld a saját gazdagépeden, mielőtt erőforrás-megtakarítás miatt váltanál.

Profi tipp: Ne úgy válts Dockge-ra, hogy a Portainernél kisebb erőforrásigényre számítasz. A nyereség a compose fájlok lemezen való láthatósága és az egyszerűbb felület. Ha a RAM a fő korlátod, tesztelj, mielőtt elköteleződsz.

Kinek a legjobb: egyedül dolgozó homelab-üzemeltetőknek, akik néhány compose stacket futtatnak egyetlen gépen, fontos nekik, hogy lássák a YAML fájljaikat a lemezen, és nincs szükségük SSO-ra vagy vizsgálatra.

Arcane: könnyűsúlyú Go-alapú kezelő ingyenes OIDC-vel

Az Arcane egyetlen lefordított Go binárisként érkezik, az ingyenes csomagban is tartalmaz OIDC/SSO-t, és GitOpsot kínál automatikus újratelepítéssel. Ez a három dolog együtt a megkülönböztető erő.

A legfrissebb kiadás a v2.4.0 (2026. július 11.) az Arcane GitHub-kiadásai szerint. Az Arcane jelentős számú kiadáson és közreműködőn van túl, ami hasznos érettségi jelzés. A licenc BSD-3-Clause; a GitHub-csillagok száma 2026 júliusában 6500 körül jár.

Amit dobozból kapsz: ingyenes OIDC/SSO (amit a Portainer fizetőfal mögé tesz), GitOps automatikus újratelepítéssel, amikor a repód változik, egy REST API, egy CLI eszköz azoknak, akik nem szeretnek kattintgatni, távoli gazdagép-kezelés, és egy SBOM, amelyet a csapat az átláthatóság kedvéért közzétesz.

Amit nem kapsz, az a Dockhand-féle, a telepítési folyamatba épített sebezhetőségvizsgálat, és az Arcane frissítési munkafolyamata sem azonos a Dockhand biztonságos letöltési megközelítésével. Ha a döntő követelményed az, hogy ugyanabból a felületből vizsgálhasd az image-eket és blokkolhasd a kockázatos letöltéseket, a Dockhand marad az egyértelműbb választás.

Kinek a legjobb: kis csapatoknak vagy egyedül dolgozóknak, akiknek ingyenes SSO és letisztult, egybinárisos telepítés kell. Ha valaha azért állítottál fel Portainert, hogy két csapattársadnak külön belépést adj, majd rájöttél, hogy az OIDC csak BE-ben van, az Arcane a kézenfekvő következő lépés.

Dockhand: biztonságközpontú kezelő beépített vizsgálattal

A Dockhand fő funkciója a telepítési folyamatba sütött sebezhetőségvizsgálat. A Grype és a Trivy egyaránt teljes jogú polgárként fut, plusz van egy „biztonságos letöltés” mód, amely visszatartja az image-frissítéseket, ha a vizsgálat megjelöli őket. Az OIDC/SSO szintén ingyenes. Ez a kombináció sehol máshol nem létezik ezen a listán.

Egyben ez a legfiatalabb eszköz itt. A szerző, Jarek Krochmalski 2025 decemberében adta ki az első verziót. A Dockhand GitHub-repója a v1.0.37-et (2026. július 11.) sorolja fel legfrissebb kiadásként. Ezt így olvasd: a biztonsági funkciókészlet valódi, és a fejlesztés gyorsan halad, de a projekt éles környezetben szerzett múltja még mindig rövidebb, mint az itt szereplő régebbi eszközöké.

A licencre érdemes odafigyelni. A Dockhand Business Source License 1.1 alatt jelenik meg: ingyenes személyes használatra, belső céges használatra, nonprofit szervezeteknek, oktatásra és kiértékelésre. Nem OSI által jóváhagyott nyílt forráskód. A repó megerősíti, hogy a licenc 2029. január 1-jén Apache 2.0-ra vált. Addig a kereskedelmi továbbterjesztés és a SaaS-viszonteladás szóba sem jöhet. A fizetős kkv- és vállalati feltételek változhatnak, ezért nézd meg dockhand.pro ha kereskedelmi licencre van szükséged.

Amit kapsz: sebezhetőségvizsgálat Grype és Trivy segítségével, biztonságos letöltési védelem, ingyenes OIDC/SSO, automatikus frissítések visszaállítási lehetőséggel, a nem használt image-ek és kötetek ütemezett takarítása, több csomópont kezelése a Hawser nevű kis ügynökön keresztül, webes terminál, fájlböngésző, tevékenységnaplózás. Alatta a stack Bun + SvelteKit, alapértelmezetten SQLite, opcionálisan PostgreSQL, az image pedig Wolfi-alapú a kisebb támadási felület érdekében. Az XDA Developers Dockhand-cikke részletesen bemutatja a felületet, ha telepítés előtt bele akarsz nézni.

Két dolgot érdemes tudni: az RBAC és az LDAP/AD fizetőfal mögött van még az egyébként nagyvonalú ingyenes csomagban is. A Dockhand mostantól támogatja a Podman-környezeteket, a sebezhetőségvizsgálatokkal együtt, de a Docker maradt az elsődleges és érettebb útvonala, ezért migrálás előtt teszteld a saját Podman-munkafolyamatodat.

Kinek a legjobb: biztonságtudatos homelab-felhasználóknak és kis csapatoknak, akik dobozból akarnak sebezhetőségvizsgálatot a Portainer BE megvásárlása nélkül, és nincs bajuk azzal, hogy egy fiatal projektet futtassanak nem OSI licenc alatt.

Komodo: Git-vezérelt, több szerverre kiterjedő telepítés

A Komodo lényege, hogy a Git az igazságforrás, és tiszta a szétválasztás a vezérlősík és a kezelt gazdagépek között. A Komodo Core-t (webes felület, API, ütemező) egyetlen gépen futtatod, minden kezelni kívánt gazdagépre felteszed a Periphery nevű kis, állapotmentes ügynököt, a stackjeidet, buildjeidet és telepítéseidet pedig kódként definiálod egy Git-repóban.

A legfrissebb kiadás a v2.2.0 (2026. május 7.) a Komodo GitHub-kiadásai szerint. A backend Rust nyelven íródott, amire a Komodo dokumentációja a komodo_client Rust crate révén utal.

Amiben jó: buildpipeline-ok Gitből, automatikus verziózással, olyan stackek telepítése, amelyek automatikusan újratelepülnek, amikor a beállított ágra pusholsz, erőforrásonként részletes jogosultságok, OAuth GitHubon vagy Google-ön keresztül, REST + WebSocket API, erőforrás-figyelés, és nincs szerverszám-korlát. A konténermotor-támogatás lefedi a Dockert, és (a dokumentáció szerint) a Podmant egy podman–docker aliason keresztül, a Docker Swarm támogatása pedig a v2-ben került be.

The setup overhead is real. Komodo needs a database (MongoDB, FerretDB, or PostgreSQL). You also have to think about networking between Core and your Periphery agents. None of this is hard if you've done it before, but it's not "docker run and go" the way Dockge is. The reward for that setup work is a deployment workflow that scales across however many VPS instances you want to run.

Kinek a legjobb: DevOps-szakembereknek vagy csapatoknak, akik több VPS gazdagépen futtatnak Dockert, és a Gitet akarják igazságforrásként használni, erőforrásonként részletes jogosultságokkal és olyan több szerveres munkafolyamattal, amely nem függ a Kubernetestől.

Melyik illik a te használati esetedhez?

Íme a rövid válasz. Mind a négyet teszteltem, és az alábbiakat ajánlanám, ha egy Slack-üzenetben leírnád a rendszeredet.

• Egyszemélyes homelab, egyetlen gazdagép, compose stackek, amelyeket YAML-ként szeretnél látni a lemezen: Dockge. A szerző az Uptime Kumát is karbantartja, a fájlközpontú felépítés tökéletesen illik egy stabil homelabhoz, és a felület is tetszeni fog.
• Kis csapat, amelynek kifejezetten ingyenes OIDC/SSO kell: Arcane. Egybinárisos telepítés, érett kódbázis, BSD licenc, beépített GitOps. Ez a legegyszerűbb váltás a Portainer CE-ről valami jobbra, ha a hitelesítésnél ütköztél falba.
• Biztonságtudatos felhasználó, aki sebezhetőségvizsgálatot szeretne a Portainer BE megfizetése nélkül: Dockhand. Csak nyitott szemmel menj bele a BSL licenc és a projekt fiatalsága miatt.
• Több szerveres Docker több VPS gazdagépen, Git-vezérelt munkafolyamattal: Komodo. Igen, az adatbázis-követelmény valódi beállítási munka. És igen, megéri, ha kettőnél több gazdagéped van.
• Nincs szükséged SSO-ra, a csapatod kicsi, és a Portainer felülete megfelel: Maradj a Portainer CE-nél.

Egy őszinte szó a szoros esetekről: az Arcane és a Dockhand közötti választás egy biztonságtudatos, egyedül dolgozó felhasználó számára tényleg szoros. Az Arcane oldalán az érettség és a nyílt forráskódú licenc áll; a Dockhand oldalán a vizsgálati funkciók. Szerintem egyikkel sem nyúlhatsz mellé. Válaszd azt a szempontot, amelyik jobban számít neked.

Ha már döntöttél, és szeretnéd megspórolni a kézi telepítést, ezek közül négy eszköz (Dockge, Arcane, Komodo és maga a Portainer) egykattintásos telepítéssel elérhető a A Cloudzy piactere, és mindegyik fut bármelyik Linux VPS csomagokat. Egy 2 GB / 1 vCPU VPS észszerű kiindulópont a menedzsment-UI és egy kisebb konténeres terhelés futtatásához; több stacket használó felállásokhoz, vagy ha a Komodo adatbázisát a Core mellett futtatod, számolj 4 GB-tal vagy többel. A Dockhand még nem érhető el a marketplace-en, de ugyanilyen típusú Linux VPS-re telepíthető. A Portainer és Cosmos Cloud összehasonlítása a Cloudzy blogján részletesebben mutat be egy másik marketplace-lehetőséget.

Összegzés

Nincs egyetlen univerzális Portainer-helyettesítő. A Dockge illik legtisztábban a fájlközpontú, egygépes Compose-kezeléshez, az Arcane a legerősebb kézenfekvő választás ingyenes SSO-hoz, a Dockhand az integrált sebezhetőségvizsgálattal tűnik ki, a Komodót pedig több szerverre kiterjedő, Git-vezérelt telepítésekre építették. Ha a Portainer CE már lefedi az igényeidet, továbbra is ésszerű döntés maradni nála.

Ahhoz a korláthoz válaszd az eszközt, amelyet ténylegesen fel kell számolnod, majd teszteld a stackjeid egy másolatával, mielőtt éles terheléseket migrálnál. Ha a szerver nulláról való felépítése nélkül szeretnél telepíteni, a Cloudzy marketplace-e és Linux VPS csomagjai gyakorlatias kiindulópontot adnak a Portainerhez, Dockge-hoz, Arcane-hoz vagy Komodóhoz.

Gyakran ismételt kérdések

Mi a különbség a Portainer CE és a Business Edition között?

A Portainer CE ingyenes, és lefedi az alapvető konténerkezelést, beleértve a Docker-környezeteket, a Compose stackeket és a több környezet ügynökökön keresztüli kezelését. A Business Edition olyan képességekkel egészíti ki, mint az OAuth/SSO, a részletes RBAC, az AD/LDAP, az auditnaplózás és további vállalati vezérlők. A Portainer jelenleg három Business Edition csomópontot kínál ingyen; azon túl az ár a választott csomagtól és a csomópontok számától függ.

Teljesen kiváltja a Dockge a Portainert?

Egyetlen, compose stackeket futtató Docker gazdagépen, SSO- és részletes RBAC-igény nélkül igen, a Dockge tisztán elvégzi a napi feladatokat. Nem váltja ki viszont a Portainer Kubernetes-támogatását, részletes RBAC-ját vagy registry-kezelő funkcióit. A v1.4-ben hozzáadott többügynökös támogatás lefedi az alapvető több szerveres helyzeteket, de nem teljes értékű Portainer-ügynök helyettesítő.

Használhatom a Dockge-ot több szerveres Docker-kezelésre?

Igen, a v1.4 óta (a v1.5-ben finomítva) a Dockge támogatja több Dockge-példány egyetlen felületről történő kezelését. Könnyebb, mint a Portainer ügynökmodellje, de nem éri utol a Komodo Git-vezérelt, szerverek közötti munkafolyamatát. Két-három gazdagéphez megfelelő; valódi több szerveres flottához a Komodo a jobb eszköz.

Mely Portainer-alternatívák kínálnak ingyenes OIDC/SSO-t?

Az Arcane és a Dockhand egyaránt tartalmaz OIDC/SSO-t az ingyenes csomagjában. A Komodo támogatja az OIDC-t, valamint a szolgáltatóalapú bejelentkezési lehetőségeket. A Dockge nem támogatja az OIDC-t. A Portainer külső hitelesítési és SSO-lehetőségei a Business Edition részei.

Megéri még a Portainer CE 2026-ban?

Igen. A Portainer CE-t továbbra is aktívan karbantartják, és az LTS ágon továbbra is szállít CVE-javításokat. Ha a rendszerednek nincs szüksége SSO-ra, részletes RBAC-ra vagy GitOps automatikus frissítésekre, nincs sürgős ok a migrálásra. A cikkben szereplő alternatívák azoknak szólnak, akik egy konkrét CE-korlátba ütköztek, nem azoknak, akiknek a jelenlegi rendszere jól működik.