Arcane Docker-teszt: készen áll a Portainer leváltására?

Az Arcane 2026. június 7-én, a v2.0.0 kiadásban szállította le a teljes szerepköralapú hozzáférés-vezérlést. Emellett az általad beállított ütemezés szerint átvizsgálja az image-eidet ismert sebezhetőségek után. Egyik sem volt igaz, amikor Brandon Lee 2025. december 29-én közzétette az Arcane-ról szóló első benyomásait, valamivel több mint öt hónappal az RBAC-kiadás előtt.

Ez a szakadék most minden Arcane Docker-teszt kínos része. Az eszköz már a v2.10.2-nél tart, amely 2026. szeptember 5-én jelent meg, kevesebb mint két héttel a v2.9.0 után. A v2.10.0 kiadás javította a lentebb tárgyalt GitOps klónszivárgást, és hozzáadott egy kísérleti Convert to Compose munkafolyamatot a futó konténerekhez. Egy akár néhány nappal korábban írt funkciólista már egy másik terméket ír le.

Röviden

Az Arcane v2.10.2 a megfelelő üzemeltetőnek működőképes Portainer-helyettesítő. Teljes RBAC-ot, OIDC egyszeri bejelentkezést, Trivy sebezhetőség-szkennelést és GitOps-újratelepítést ad költség és csomópontkorlát nélkül. A Portainer ezt a szerepkör-hierarchiát három csomópont felett a Business Editionben tartja. 5-ből 4. Ami visszatartja, az a rövid múlt, nem a képességek.

• Válts, ha túl vagy a Portainer harmadik csomópontján, és olyan szerepkörökre van szükséged, amelyek behatárolják, ki mihez nyúlhat. Hat beépített szerepkört, egyéni szerepköröket, környezetenkénti hozzárendelést és OIDC csoport-claim leképezést kapsz, fizetés és mérés nélkül.
• A sebezhetőség-szkennelés benne van a csomagban. Az Arcane cron ütemezés szerint futtatja a Trivyt, egy nyílt forráskódú image-szkennert, és image-enként tárolja az eredményeket.
• A Portainer Business Edition három csomópontig ingyenes, funkciókorlátozás nélkül. E vonal alatt már megvan az RBAC és az SSO, így az Arcane ingyenes hozzáférésről szóló érve ott jóval gyengébb.
• Továbbra sincs közvetlen Portainer-stack importálás. A v2.10.0 kísérleti jelleggel Compose-projektekké tudja alakítani a futó konténereket, ami lefarag a kézi munkából, de a generált YAML-t így is át kell nézned és át kell váltást tervezned, mert a nevek és a publikált portok ütközhetnek, amíg az eredetiek futnak. Előbb mentsd a köteteket.
• Erősítsd meg az ENCRYPTION_KEY beállítást élesítés előtt, és állítsd be az APP_URL értékét helyesen. ENCRYPTION_KEY még mindig fejlesztői alapértéket tartalmaz, a passkey-bejelentkezés pedig addig nem működik, amíg az APP_URL nem arra a HTTPS-hosztnévre mutat, amelyet a felhasználók ténylegesen megnyitnak. JWT_SECRET a jelenlegi telepítési dokumentáció szerint már nincs használatban.
• A v2.8.0 és v2.9.0 ellen jelentett, lemezt megtöltő GitOps-hiba a v2.10.0-ban javítva van. A javítás kitakarítja a hátramaradt ideiglenes Git-klónkönyvtárakat ahelyett, hogy hagyná felhalmozódni őket a manager hoszton.
• Az LDAP továbbra is hiányzik. Az identitásintegráció kizárólag OIDC.

Hogyan készült ez az értékelés: ez egy bizonyítékokon alapuló áttekintés, nem gyakorlati teszt. Nincs szponzoráció, nincs fizetség, nincs rendelkezésre bocsátott termék, nincs kapcsolat a karbantartóval. Minden képességre vonatkozó állítást az Arcane aktuális dokumentációjával és kiadási jegyzeteivel vetettünk össze, és minden megbízhatósági állítás egy dátumozott hibajegyre vezethető vissza a projekt nyilvános követőjében, vagy egy név szerint azonosított üzemeltetőre, aki a saját telepítéséről ír. Itt senki nem futtatta az Arcane-t a cikk megírásához, ezért ahol ez korlátozza az ítéletet (milyen a felület kezelése, hogyan bírja a tartós terhelést), a cikk ezt kimondja találgatás helyett.

Mit ad az Arcane ingyen, amit a Portainer nem?

Főként egy dolgot: a teljes szerepköralapú hozzáférés-vezérlést. A Portainer CE alapszintű felhasználókezelést ad; a szerepkör-hierarchia a Business Edition része. Az Arcane bármilyen csomópontszám mellett ingyen adja, a Trivy-szkennelés, a GitOps-újratelepítés, a Swarm-támogatás, a passkey-bejelentkezés, a távoli agentek és a v2.9.0-ban hozzáadott S3-mentések mellett.

Az RBAC az a rész, amelyet érdemes közelről megnézni, mert a „van RBAC” nagyon különböző dolgokat takarhat. Az Arcane hozzáférés-vezérlési dokumentációja hat változtathatatlan beépített szerepkört ír le: Admin, Editor, No-Shell Editor, Deployer, Monitor és Viewer. Bármelyiket klónozhatod egyéni szerepkörré, és egyenként pipálhatod ki a jogosultságokat, amelyek a <resource>:<action> mintát követik, például containers:start. A hozzárendelések globálisak vagy környezetenkéntiek, és egy felhasználónak több is lehet egyszerre. A dokumentáció közvetlenül hozza a példát: Editor a prod, Viewer a staging környezetben.

Egy SSO-bevezetésnél az számít, hogy a szerepkör-hozzárendelést maga az identitásszolgáltató vezérelheti: „Minden bejelentkezéskor az Arcane beolvassa a felhasználó csoport-claimjét, és újraszinkronizálja az OIDC-ből származó hozzárendeléseit”, és a több leképezett csoportban lévő felhasználó ezek unióját kapja. Ez az a jogosultsági modell, amely a Portainer CE-ben sosem volt meg.

A sebezhetőség-szkennelés a második elem. Az Arcane szkennelési dokumentációja kimondja, hogy „a szkennelés opcionális, cron ütemezés szerint fut, az eredmények pedig image-enként tárolódnak”, az eredményeket pedig a felület mutatja. Alapértelmezés szerint naponta éjfélkor fut, trivyIgnoreUnfixed az ismert javítással rendelkező sebezhetőségekre szűkíti az eredményeket, a Trivy pedig rögzített verziójú eszköz-image-ben érkezik, így a szkenner frissítései nem a te dolgod.

Most az ellensúly, és az nagy. A Portainer saját CE kontra BE oldala azt írja, hogy a Business Edition „örökre ingyenes legfeljebb 3 csomópontig. Nincs próbaidőszak. Nincs bankkártya. Nincs funkciókorlátozás.” Ez a teljes BE-készlet: RBAC saját szerepkör-hierarchiával, OIDC, auditnaplók Syslog-exporttal, fejlett GitOps. A Take 3 feltételei egyéves licencet adnak, amelyet évente költség nélkül megújítanak, amíg három vagy kevesebb csomópontnál maradsz.

Az ingyenes szint matekja tehát csak a negyedik csomóponttól billen az Arcane javára. Az alatt nincs fizetőfal. Az Arcane egy-két csomópontnál is ad valamit: nincs licenckulcs, nincs észben tartandó megújítás, és a projektet forkolhatod. De ez nem ugyanaz az érv, mint hogy „az RBAC pénzbe kerül”.

Az Arcane egyike annak a négy eszköznek, amely komolyan pályázik a Portainer helyére, a többi pedig más vonalak mentén oszlik meg.

OLVASD

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

Mennyire megbízható most az Arcane?

Jobb, mint amilyennek a v2.9.0-nál látszott, de még fiatal. Az Arcane hibatörténete egy aktív, javítgató projekt képét mutatja, a v2.8.0 és v2.9.0 ellen jelentett súlyos, lemezt megtöltő GitOps-hibát pedig 2026. augusztus 31-én javították a v2.10.0-ban.

Egy üzemeltető 2026. augusztus 26-án jelentette, hogy a GitOps-szinkronizálás klónkönyvtárat szivárogtat: "gitops-<N> a klónkönyvtárak naponta nagyjából 1000-rel (~9 GB/nap) gyűlnek, és soha nem takarítódnak ki, végül megtöltik a lemezt." Hat nap ebből nagyjából 6467 könyvtárat és 40 GB-ot jelentett. Amint a lemez megtelt, a manager nem tudott többé az SQLite-adatbázisába írni, újraindítási hurokba került, elérte a 389-es újraindítási számot, és magával rántotta az edge-agent kapcsolatokat és az API-hívásokat. A hibajegy már lezárult, a v2.10.0 pedig tartalmazza a hátramaradt ideiglenes Git-klónkönyvtárak takarítási javítását.

Ha még a v2.8.0-n vagy a v2.9.0-n vagy: frissíts, mielőtt gyakori GitOps-szinkronizálásra támaszkodnál. A klónszivárgás javítása a v2.10.0-ban érkezik.

A régebbi előzmények biztatóbbak. Egy frissítés utáni lefagyás a 2.0 és a 2.0.1 között megoldódott. Egy hiba, amelynél az „Update Projects” minden konténert érintett a hoszton a kiválasztott projekt konténerei helyett, a beolvasztott #2289 javító PR-ral zárult le. Az image-lekérdezés, amely csendben nem indult el a v1.13.2-ben, a v1.14.0-ban javítva lett. Három hiba, három javítás.

A nyitott hibajegyek nyers száma önmagában nagyon keveset mond egy ilyen tempóban kiadó projektről. Azok a projektek, amelyekre senki nem nyit hibajegyet, ettől nem lesznek megbízhatóbbak.

Az én olvasatom továbbra is az, hogy ez a múlt hosszának problémája, nem a képességeké. A gyors kiadás az oka, hogy az RBAC és a szkennelés hiányai egyáltalán bezárultak, és annak is, hogy a v2.10.0-nak kevesebb mint egy héttel a v2.9.0 után súlyos GitOps-hibát kellett javítania. A kockázat az új kódban lakik, és annak átvétele döntés.

Mibe kerül valójában az átállás a Portainerről?

Nagyjából egy leállási ablakba és némi kézi takarításba. Az Arcane-nak továbbra sincs közvetlen Portainer-stack importja, de a v2.10.0 hozzáad egy kísérleti Convert to Compose műveletet a futó konténerekhez. Ez Compose-fájlt generál, miközben az eredetiek tovább futnak, ami leveszi a YAML-újraépítés egy részét. A bind mountokat, hálózatokat, környezeti értékeket és magát az átváltást így is át kell nézned; a nevek és a publikált portok ütközhetnek, amíg az eredetieket le nem állítod, tehát ez nem leállásmentes migrációs gomb.

A v2.10.0 előtt a projekt saját fóruma teljesen kézi utat tükrözött. Egy üzemeltető, aki öt szerveren több mint 80 konténert futtatott, megkérdezte, lehetséges-e élő migráció anélkül, hogy előbb leállítaná a webre néző szolgáltatásokat. Valakinek a válasza, aki már túl volt rajta: „nem lesz más választásod, mint törölni a meglévő konténereket (és így a Portainer-stackeket), és a nulláról újra létrehozni őket az Arcane-ban.” Az ő sorrendje: tiszta leállítás, mentés, törlés, adatok átmásolása, újralétrehozás és újratelepítés.

A gyakorlatban: kötetmentések, mielőtt bármihez nyúlnál, és olyan karbantartási ablak, amelyet a futtatott stackek száma és a mozgatandó adatmennyiség együtt határoz meg. A konténerek újralétrehozása általában a gyors rész; a nagy kötetek másolása és a függő szolgáltatások helyes sorrendű visszahozása megnyújthatja az ablakot. Egy terminológiai megjegyzés a tervezéshez: amit a Portainer stacknek hív, azt az Arcane projektnek nevezi.

Az időköltség még homelab-méretben is jelentkezik. Moises Aguirre, aki 2026. február 28-án írt egy homelab Portainerről való átköltöztetéséről, „egy jó hétvégényi munkának (és a démonaimmal való szembenézésnek)” nevezte, a démonok pedig a saját rendetlensége voltak: minden futtatott konténerét át kellett vizsgálnia, és YAML-t kellett írnia olyan szolgáltatásokhoz, amelyeket korábban „egyszerűen összekattintott”. Ez az ő tapasztalata, nem szabály, de a minta ismerős.

Egy dolgot érdemes elkapni, mielőtt átviszed a Compose-fájlokat. A v2.7.0 kiadási jegyzetei négy forrásra szűkítették a változófeloldást: a globális változóidra a .env.globalfájlban, a projekt saját .env fájljára, a magába a compose-fájlba írt alapértékekre, valamint az Arcane környezetéből származó időzónára és területi beállításra. A kimondott hatás az, hogy egy Arcane-on át telepített projekt ugyanúgy oldja fel a változóit, mint a docker compose up a projektkönyvtárban. Ez helyesebb viselkedés. Azt is jelenti viszont, hogy minden, ami csendben a manager saját konténerkörnyezetéből örökölt egy értéket, most valami másra fog feloldódni, vagy semmire, és mindezt panasz nélkül teszi.

Ebből semmi nem a termék hibája. Egyszeri költség, elég kiszámítható ahhoz, hogy tervezni lehessen vele, és egy migrációtól főleg ezt várja az ember.

Mit kell megerősítened élesítés előtt?

Egy titkosítási kulcsot, a nyilvános URL-t és a TLS-t. Az Arcane az első indításkor alapértelmezett adminfiókot hoz létre, és az első bejelentkezéskor jelszócserét kényszerít ki, ami ésszerű alapbeállítás. Két beállításnak kell helyesnek lennie élesítés előtt. Az első az ENCRYPTION_KEY; a második az APP_URL.

A környezeti változók referenciája még mindig ENCRYPTION_KEY alapértékkel sorolja fel az arcane-dev-key-32-characters!!!változót, miközben a telepítési dokumentáció egyedi, 32 bájtos értéket kér tőled. Cseréld le élesítés előtt. Még valami változott: a telepítési dokumentáció most azt mondja, hogy a JWT_SECRET már nincs használatban. Az Arcane maga generálja a munkamenet-aláíró kulcsot; ha a JWT_SECRET beállítva marad, az csak indítási figyelmeztetést ad, ezért távolítsd el a környezetből. A telepítési dokumentáció azt írja elő, hogy az ENCRYPTION_KEY „32 bájt hosszú kell legyen (nyers, base64 vagy hex).”

A verzióhigiénia is erre a listára tartozik. Az Arcane 2026-ban több biztonsági közleményt adott ki; egy magas súlyosságú, 2026. július 29-én közzétett közlemény a v2.5.0 előtti kiadásokat sorolja érintettként, és leírja, hogy egy delegált users:update jogosultsággal vissza lehetett állítani egy adminisztrátor jelszavát. Javított kiadásként a v2.6.0-t nevezi meg, így a v2.10.0 nem érintett, de ez konkrét ok arra, hogy éles telepítést ne hagyj régi tagen.

APP_URL alapértéke http://localhost:3552, és ennek a higiénián túl működési következménye is van. A passkey-bejelentkezés és a passkey-MFA is WebAuthn-on fut, és az Arcane passkey-dokumentációja egyértelmű: „A böngészők csak biztonságos környezetben teszik elérhetővé a WebAuthn API-t, ezért a passkey-ekhez HTTPS kell (vagy localhost).” A relying party azonosítója az APP_URLértékéből származik, a passkey-ek ahhoz a hosztnévhez kötődnek, és ha az APP_URL nem tartalmaz hosztnevet, a passkey-szolgáltatás nem inicializálódik. Sima HTTP-n az Arcane teljesen elrejti a passkey-vezérlőket. Telepítsd csupasz IP-re és portra, és a v2 fő hitelesítési funkciója egyszerűen nincs ott. A dokumentáció világosan fogalmaz: „Állítsd az APP_URL értékét arra az URL-re, amelyet a felhasználóid ténylegesen megnyitnak, HTTPS-en, mielőtt bárki passkey-t regisztrálna.”

A távoli agentek döntik el, mit kell megnyitnod. Az Arcane környezetekről szóló dokumentációja azt írja, hogy közvetlen módban „a Manager a TCP 3553porton csatlakozik az Agenthez”, tehát annak a portnak bejövő irányban elérhetőnek kell lennie a távoli hoszton. Edge módban „az Agent kimenő irányban csatlakozik a Managerhez”, és egyáltalán nincs szüksége bejövő portra.

Ezen túl inkább rámutatok, mint hogy úgy tegyek. Az Arcane közzétesz egy socket-proxy beállítási útmutatót , amelynek kiindulópontja, hogy a közvetlen socket-csatolás „teljes hozzáférést ad az Arcane-nak a Dockerhez”, a proxy pedig a szükséges API-hívásokra szűkíti ezt. Ugyanaz a kitettség, amely miatt a Docker socket elszigetelése bárhol megéri, és itt is érdemes. Ezeket a dokumentumokat úgy olvasom, ahogy egy telepítő olvassa őket, nem a tokenséma auditjaként.

Mit nem tud még mindig az Arcane?

Az Arcane jelenlegi dokumentációja alapján két hiányosság még áll: nincs LDAP, és nincs általános böngésző a konténer saját fájlrendszeréhez. Több más, v2 előtti hiányosság azóta bezárult.

Az LDAP hiányzik. Az Arcane egyszeri bejelentkezésről szóló dokumentációja az OIDC-t és csak az OIDC-t tárgyalja, és sem az, sem a hozzáférés-vezérlési oldal sehol nem említi az LDAP-ot vagy az Active Directoryt. A Portainer Business Editionezzel szemben integrálódik az „Active Directoryval, LDAP-pal és OIDC-kompatibilis identitásszolgáltatókkal”. Ha a szervezeted olyan címtárral hitelesít, amely előtt nincs OIDC-réteg, ez kemény stop, nem megkerülhető akadály.

Nincs általános fájlböngésző a konténereken belül. Az Arcane konténernézete megmutatja a konfigurációt, a csatolásokat, a naplókat és a Compose-forrást, de nem ad böngészőt a konténer saját fájlrendszeréhez. Van viszont már Volume Workspace, amely a Docker-köteteken belüli fájlokat tudja böngészni és szerkeszteni, így a megmaradt hiány szűkebb, mint a régi „nincs fájlböngésző” leírás.

Ezeket a helyesbítéseket érdemes kimondani, mert az Arcane „nincs RBAC, nincs sebezhetőség-szkennelés” leírása már nem állja meg a helyét. Az RBAC a v2.0.0-val érkezett 2026. június 7-én, a Trivy-szkennelés pedig dokumentált és ütemezetten fut. A tevékenységnaplózás is továbblépett: az Arcane tevékenységekről szóló dokumentációja egy Activity Centert ír le, amely lefedi a pullokat, buildeket, életciklus-műveleteket, szkenneléseket és tisztításokat, mellette egy eseménynaplóval, amely súlyosságot, típust, időbélyeget és az egyes műveleteket kiváltó felhasználót tartalmazza, ahol az Arcane hozzá tudja rendelni. Hogy exportál-e Syslogba úgy, ahogy a Portainer Business szintje, azt a dokumentáció nem dönti el.

Amit a kiadási tempó nem orvosol, az az életkor. Az Arcane tárolója 2025 áprilisában jött létre. A Portainer mögött évek alatt felhalmozott Stack Overflow-válaszok, külső útmutatók és integrációk állnak, és amikor este 11-kor valami furcsába ütközöl, ezt a különbséget érzed meg.

Kinek érdemes az Arcane-ra váltania, és kinek nem?

Válts az Arcane-ra, ha a Portaineren túl vagy három csomóponton, és behatárolt többfelhasználós hozzáférést szeretnél gitben követett Compose-zal, licencbeszélgetés nélkül. Maradj, ahol vagy, ha három vagy kevesebb csomópontod van. A hosztok megszámolása a kérdés nagy részét gyorsabban eldönti, mint bármilyen funkciólista.

Három profil, ahol az Arcane egyértelmű igen:

• A Portainer háromcsomópontos plafonján túli üzemeltetők, akiknek behatárolt hozzáférés kell. Három csomópont felett ezek a képességek a Portainernél pénzbe kerülnek, az Arcane-nál nem, a szerepkörök pedig elég finomak ahhoz, hogy valaki Deployer legyen egy környezetben és Viewer mindenhol máshol.
• Üzemeltetők, akik a Compose-fájlokat akarják az igazság forrásának. Ha a váltást az hajtja, hogy a stack-definíciók adatbázisban élnek repó helyett, az szerkezeti illeszkedés, nem preferencia. A migrációs hétvége nagyrészt azzal telik, hogy leírod, amit már futtatsz, és ezzel a munkával amúgy is tartoztál.
• Üzemeltetők, akik több hosztot vonnak össze, NAT mögöttieket is. Az edge módú agenteknek nincs szükségük bejövő portra a távoli oldalon, a Swarm-fürtöket a manager csomópontról kezeled, a távoli környezetek pedig semmibe sem kerülnek.

Két profil, ahol nem az:

• Bárki, akinek három vagy kevesebb csomópontja van. A Business Edition ebben a méretben ingyenes a teljes funkciókészlettel, így a váltás egy leállási ablakot és egy hétvégét költ olyan képességekre, amelyek már megvannak. Portainer-alternatívaként az Arcane képes eszköz; ez így sem ok a költözésre.
• Bárki, akinek LDAP kell, vagy aki nem állíthatja le a stackeket. Címtáras hitelesítés nincs, a migrációhoz pedig továbbra is tervezett átváltás kell. Egyikre sincs ügyes kerülőút.

Ehhez az ítélethez egy feltétel is tartozik. Ha kifejezetten a GitOps-újratelepítés miatt költözöl, használd a v2.10.0-t vagy újabbat. A v2.8.0 és v2.9.0 ellen jelentett lemezmegtöltési hiba ott javítva van.

OLVASD

Hogyan szerezz Dockert VPS-re: átfogó útmutató a VPS konténerizációhoz való használatához🗂️

Gyakran ismételt kérdések

Ingyenes az Arcane?

Igen. Az Arcane ingyenes és BSD-3-Clause licencű, fizetős szint, enterprise kiadás és csomópontszám szerinti funkciózárolás nélkül. A szerepköralapú hozzáférés-vezérlés, az OIDC egyszeri bejelentkezés, a sebezhetőség-szkennelés, a távoli környezetek és a GitOps-újratelepítés mind benne van. Az egyetlen költség a gép, amelyen futtatod.

Mennyi RAM kell az Arcane-nak?

A projekt nem tesz közzé minimumot. Az Arcane telepítési dokumentációja nem ad RAM- vagy CPU-alsó határt, a támogatott hardver pedig az x86-os szerverektől a Raspberry Pi-osztályú lapokig terjed. Egy üzemeltető, aki a saját migrációját dokumentálta , arról számolt be, hogy a felügyeleti konténere „~150MB RAM-ról (Portainer) nagyjából ~67MB-ra (Arcane)” csökkent. A méretezést az általad kezelt konténerek határozzák meg, nem az Arcane.

Támogat az Arcane több hosztot?

Igen, távoli környezeti agenteken keresztül. Edge módban az agent kimenő irányban tárcsázza a managert, így nem kell bejövő port, és lefedi a NAT vagy tűzfal mögötti hosztokat; közvetlen módban ehelyett a manager tárcsáz be. A Docker Swarm támogatott teljes vezérléssel a manager csomópontokon és csak olvasható nézetekkel a workereken.

Biztonságos az Arcane-t élesben futtatni?

Attól függ, mit kapcsolsz be. Cseréld le az alapértelmezett adminjelszót az első bejelentkezéskor, cseréld le az ENCRYPTION_KEYalapértékét, és tedd az Arcane-t TLS mögé helyes APP_URLértékkel, amely a passkey-ek működéséhez szükséges. A JWT_SECRET már nincs használatban, a v2.8.0 és v2.9.0 ellen jelentett GitOps klónszivárgás pedig ott javítva van, így az éles telepítéseket a v2.10.0-val vagy újabbal érdemes kezdeni.

Hogyan viszonyul az Arcane a Dockge-hoz vagy a Dockhandhez?

A Dockge kisebb és csak Compose-ra épül, ami jobb választás, ha csak egy stack-szerkesztőre van szükséged. A Dockhand erősebben épít az image-ek biztonsági szkennelésére. Az Arcane a három közül a legszélesebb eszköz, és az egyetlen ingyenes RBAC-kal; a Dockhandé Enterprise-szintű.