Recenze Arcane pro Docker: je připravený nahradit Portainer?

Arcane vydal plné řízení přístupu na základě rolí 7. června 2026, ve vydání v2.0.0. Také skenuje vaše image na známé zranitelnosti podle rozvrhu, který si nastavíte. Nic z toho neplatilo, když Brandon Lee 29. prosince 2025 zveřejnil své první dojmy z Arcane, něco přes pět měsíců před vydáním RBAC.

Tahle mezera je právě teď nepříjemná část každé recenze Arcane pro Docker. Nástroj je už na v2.10.2, vydané 5. září 2026, necelé dva týdny po v2.9.0. Vydání v2.10.0 opravilo únik klonů GitOps popsaný níže a přidalo experimentální postup Convert to Compose pro běžící kontejnery. Seznam funkcí napsaný byť jen o pár dní dřív popisuje jiný produkt.

Stručně

Arcane ve v2.10.2 je použitelná náhrada Portaineru pro správného provozovatele. Nabízí plné RBAC, jednotné přihlášení OIDC, skenování zranitelností Trivy a opětovné nasazení GitOps bez poplatků a bez stropu na počet uzlů. Portainer si tuhle hierarchii rolí nad tři uzly nechává v Business Edition. 4 z 5. Brzdí ho krátká historie, ne schopnosti.

• Přejděte, jakmile jste za třetím uzlem Portaineru a potřebujete role, které vymezují, kdo na co smí sáhnout. Dostanete šest vestavěných rolí, vlastní role, přiřazení podle prostředí a mapování skupinových claimů OIDC, bez placení a bez měření.
• Skenování zranitelností je součástí balení. Arcane spouští Trivy, open-source skener imagí, podle rozvrhu cron a ukládá výsledky pro každý image.
• Portainer Business Edition je zdarma až do tří uzlů, bez omezení funkcí. Pod touto hranicí už RBAC i SSO máte, takže argument Arcane o bezplatném přístupu je tam mnohem slabší.
• Přímý import stacků z Portaineru stále neexistuje. v2.10.0 umí experimentálně převést běžící kontejnery na projekty Compose, což ušetří část ruční práce, ale vygenerovaný YAML musíte stále zkontrolovat a naplánovat přepnutí, protože názvy a publikované porty mohou kolidovat, dokud originály běží. Nejdřív zálohujte svazky.
• Zabezpečte ENCRYPTION_KEY před produkcí a nastavte APP_URL správně. ENCRYPTION_KEY má stále vývojovou výchozí hodnotu a přihlášení přes passkey nebude fungovat, dokud APP_URL nebude ukazovat na HTTPS hostname, na který uživatelé skutečně chodí. JWT_SECRET se podle aktuální instalační dokumentace už nepoužívá.
• Chyba GitOps s vyčerpáním disku hlášená u v2.8.0 a v2.9.0 je opravená ve v2.10.0. Oprava maže zbylé dočasné adresáře klonů Gitu místo toho, aby je nechala hromadit na hostiteli manageru.
• LDAP stále chybí. Integrace identit je pouze přes OIDC.

Jak toto hodnocení vzniklo: jde o recenzi založenou na důkazech, ne o praktický test. Žádný sponzoring, žádná platba, žádný poskytnutý produkt, žádný kontakt se správcem projektu. Každé tvrzení o funkcích je ověřené proti aktuální dokumentaci a poznámkám k vydání Arcane a každé tvrzení o spolehlivosti vede k datovanému issue ve veřejném trackeru projektu nebo ke jmenovanému provozovateli, který píše o vlastním nasazení. Nikdo tu Arcane kvůli tomuto textu nespouštěl, takže tam, kde to omezuje závěry (jak působí rozhraní, jak drží pod trvalou zátěží), to článek říká místo hádání.

Co dává Arcane zdarma, co Portainer nedává?

Hlavně jednu věc: plné řízení přístupu na základě rolí. Portainer CE dává základní správu uživatelů; hierarchie rolí je v Business Edition. Arcane ji nabízí zdarma při libovolném počtu uzlů, spolu se skenováním Trivy, opětovným nasazením GitOps, podporou Swarmu, přihlášením přes passkey, vzdálenými agenty a zálohami do S3 přidanými ve v2.9.0.

RBAC je část, na kterou se vyplatí podívat zblízka, protože „má RBAC“ zahrnuje hodně různých věcí. Dokumentace Arcane k řízení přístupu popisuje šest neměnných vestavěných rolí: Admin, Editor, No-Shell Editor, Deployer, Monitor a Viewer. Kteroukoli z nich můžete naklonovat do vlastní role a odškrtat jednotlivá oprávnění, která mají <resource>:<action> tvar jako containers:start. Přiřazení jsou globální nebo podle prostředí a uživatel jich může mít několik najednou. Dokumentace uvádí příklad přímo: Editor na prod, Viewer na stagingu.

Pro nasazení SSO je podstatné, že přiřazování rolí může řídit sám poskytovatel identity: „Při každém přihlášení Arcane přečte skupinový claim uživatele a znovu synchronizuje jeho přiřazení pocházející z OIDC“, a uživatel ve více namapovaných skupinách dostane jejich sjednocení. To je model oprávnění, který Portainer CE nikdy neměl.

Skenování zranitelností je druhý dílek. Dokumentace Arcane ke skenování uvádí, že „skeny jsou volitelné, běží podle rozvrhu cron a výsledky se ukládají pro každý image“, přičemž výsledky se zobrazují v rozhraní. Výchozí je denně o půlnoci, trivyIgnoreUnfixed zúží výsledky na zranitelnosti se známou opravou a Trivy se dodává v image s nástroji s připnutou verzí, takže aktualizace skeneru nejsou vaše starost.

A teď protiváha, a je pořádná. Vlastní stránka Portaineru srovnávající CE a BE říká, že Business Edition „je navždy zdarma až pro 3 uzly. Bez zkušební doby. Bez platební karty. Bez omezení funkcí.“ To je kompletní sada BE: RBAC s vlastní hierarchií rolí, OIDC, auditní logy s exportem do Syslogu, pokročilý GitOps. Podmínky programu Take 3 vydávají roční licenci obnovovanou každý rok zdarma, dokud zůstanete na třech uzlech nebo méně.

Matematika bezplatné úrovně tedy začíná hrát ve prospěch Arcane až od čtvrtého uzlu. Pod ní žádná placená bariéra není. Arcane i při jednom nebo dvou uzlech něco nabízí: žádný licenční klíč, žádné obnovení, na které je třeba myslet, projekt, který si můžete forknout. Ale to není stejný argument jako „RBAC stojí peníze“.

Arcane je jeden ze čtyř nástrojů, které se vážně ucházejí o místo Portaineru, a ostatní se dělí podle jiných linií.

ČTĚTE

Alternativy k Portaineru: praktický průvodce nástroji Dockge, Arcane, Dockhand a Komodo

Jak spolehlivý je Arcane právě teď?

Lépe, než to vypadalo u v2.9.0, ale stále mladý. Historie chyb Arcane se čte jako historie aktivního projektu, který věci opravuje, a závažná chyba GitOps s vyčerpáním disku hlášená u v2.8.0 a v2.9.0 byla opravena ve v2.10.0 dne 31. srpna 2026.

Jeden provozovatel 26. srpna 2026 nahlásil, že synchronizace GitOps nechává za sebou adresář klonu: "gitops-<N> adresáře klonů se hromadí rychlostí zhruba 1 000 denně (~9 GB/den) a nikdy se neuklízejí, až nakonec zaplní disk." Šest dní v tomto režimu dalo zhruba 6 467 adresářů a 40 GB. Jakmile se disk zaplnil, manager nemohl zapisovat do své databáze SQLite a spadl do restartovací smyčky, dosáhl 389 restartů a strhl s sebou spojení edge agentů i volání API. Issue je nyní uzavřené a v2.10.0 obsahuje opravu, která zbylé dočasné adresáře klonů Gitu uklízí.

Pokud jste stále na v2.8.0 nebo v2.9.0: aktualizujte, než se začnete spoléhat na častou synchronizaci GitOps. Oprava úniku klonů přichází ve v2.10.0.

Starší historie je povzbudivější. Jedno zaseknutí po aktualizaci mezi 2.0 a 2.0.1 bylo vyřešeno. Chyba, kdy „Update Projects“ zasáhl každý kontejner na hostiteli místo jen kontejnerů vybraného projektu, byla uzavřena sloučeným opravným PR #2289. Dotazování na image, které se tiše nespouštělo ve v1.13.2, bylo opraveno ve v1.14.0. Tři chyby, tři opravy.

Holý počet otevřených issues sám o sobě říká velmi málo o projektu, který vydává tímto tempem. Projekty, na které nikdo issues nezakládá, tím spolehlivější nejsou.

Můj závěr je stále ten, že jde o problém stáří, ne schopností. Rychlé vydávání je důvod, proč se mezery v RBAC a skenování vůbec zavřely, a zároveň důvod, proč v2.10.0 musela opravit závažnou vadu GitOps necelý týden po v2.9.0. Riziko sedí v novém kódu a jeho přijetí je volba.

Kolik ve skutečnosti stojí přechod z Portaineru?

Zhruba okno výpadku a trocha ručního úklidu. Arcane stále nemá přímý import stacků z Portaineru, ale v2.10.0 přidává experimentální akci Convert to Compose pro běžící kontejnery. Ta vygeneruje soubor Compose, zatímco originály dál běží, což odstraní část práce s rekonstrukcí YAML. Stále musíte zkontrolovat bind mounty, sítě, hodnoty prostředí a samotné přepnutí; názvy a publikované porty mohou kolidovat, dokud se originály nezastaví, takže to není tlačítko migrace bez výpadku.

Před v2.10.0 odrážela vlastní diskuze projektu zcela ruční cestu. Provozovatel s více než 80 kontejnery na pěti serverech se ptal, zda je možná živá migrace bez předchozího vypnutí služeb směřujících na web. Odpověď někoho, kdo to už měl za sebou: „nebudete mít jinou možnost než stávající kontejnery (a tedy stacky Portaineru) smazat a vytvořit je v Arcane od nuly.“ Jeho postup: čistě vypnout, zálohovat, smazat, překopírovat data, znovu vytvořit a znovu nasadit.

Prakticky: zálohy svazků, než na cokoli sáhnete, a okno údržby nastavené podle toho, kolik stacků provozujete i kolik dat se musí přesunout. Opětovné vytvoření kontejnerů je obvykle ta rychlá část; kopírování velkých svazků a nahození závislých služeb ve správném pořadí může okno protáhnout. Terminologická poznámka pro plánování: čemu Portainer říká stack, tomu Arcane říká projekt.

Časové náklady se projeví i v měřítku homelabu. Moises Aguirre, který 28. února 2026 psal o stěhování homelabu pryč z Portaineru, to nazval „pořádným víkendem práce (a čelením vlastním démonům)“, a těmi démony byl jeho vlastní nepořádek: musel zauditovat každý kontejner, který provozoval, a napsat YAML pro služby, které dřív „prostě naklikal“. Je to jeho zkušenost, ne pravidlo, ale ten vzorec se opakuje.

Jednu věc si pohlídejte, než přenesete soubory Compose. Poznámky k vydání v2.7.0 zúžily řešení proměnných na čtyři zdroje: vaše globální proměnné v .env.global, vlastní soubor .env projektu, výchozí hodnoty zapsané přímo v souboru compose a časové pásmo a locale z prostředí Arcane. Deklarovaný efekt je, že projekt nasazený přes Arcane řeší proměnné stejně jako docker compose up v adresáři projektu. To je správnější chování. Znamená to ale také, že cokoli, co tiše dědilo hodnotu z prostředí kontejneru samotného manageru, se teď vyhodnotí na něco jiného, nebo na nic, a udělá to bez jediného varování.

Nic z toho není vada produktu. Je to jednorázový náklad, dost předvídatelný na to, aby se dal naplánovat, což je to hlavní, co od migrace chcete.

Stavte na Linux VPS s root přístupem, NVMe a výkonem AMD EPYC.

Zobrazit Linux plány

Co musíte zabezpečit před produkcí?

Jeden šifrovací klíč, veřejnou URL a TLS. Arcane při prvním spuštění vytvoří výchozí účet správce a při prvním přihlášení vynutí změnu hesla, což je rozumné výchozí chování. Dvě nastavení musí být před produkcí správně. První je ENCRYPTION_KEY; druhé je APP_URL.

Přehled proměnných prostředí stále uvádí ENCRYPTION_KEY s výchozí hodnotou arcane-dev-key-32-characters!!!, zatímco instalační dokumentace vám říká, ať dodáte jedinečnou 32bajtovou hodnotu. Změňte ji před produkcí. Změnilo se ještě něco: instalační dokumentace nyní uvádí, že JWT_SECRET se už nepoužívá. Arcane si klíč pro podepisování relací generuje sám; ponechání JWT_SECRET v konfiguraci vyvolá jen varování při startu, takže ho z prostředí odstraňte. Instalační dokumentace stanoví, že ENCRYPTION_KEY „musí mít délku 32 bajtů (raw, base64 nebo hex).“

Na ten seznam patří i hygiena verzí. Arcane v roce 2026 zveřejnil několik bezpečnostních upozornění; jedno s vysokou závažností, zveřejněné 29. července 2026, uvádí jako postižené verze před v2.5.0 a popisuje, jak delegované oprávnění users:update umožňovalo resetovat heslo správce. Jako opravené vydání uvádí v2.6.0, takže v2.10.0 postižená není, ale je to konkrétní důvod, proč nenechávat produkční nasazení na starém tagu.

APP_URL má výchozí hodnotu http://localhost:3552, a tohle má funkční důsledek nad rámec hygieny. Přihlášení přes passkey i MFA přes passkey běží na WebAuthn a dokumentace Arcane k passkey je jednoznačná: „Prohlížeče zpřístupňují API WebAuthn jen v zabezpečeném kontextu, takže passkey potřebují HTTPS (nebo localhost).“ ID relying party se odvozuje z APP_URL, passkey jsou vázané na tento hostname, a pokud APP_URL neobsahuje hostname, služba passkey se neinicializuje. Na holém HTTP Arcane ovládací prvky passkey úplně skryje. Nasaďte na holou IP s portem a hlavní autentizační funkce v2 tam prostě není. Dokumentace to říká jasně: „Nastavte APP_URL na URL, na kterou vaši uživatelé skutečně chodí, přes HTTPS, dřív než si kdokoli zaregistruje passkey.“

Vzdálení agenti rozhodují o tom, co musíte otevřít. Dokumentace Arcane k prostředím říká, že v přímém režimu „se Manager připojuje k Agentovi přes TCP 3553“, takže tento port musí být na vzdáleném hostiteli dosažitelný příchozím směrem. V režimu edge „se Agent připojuje odchozím směrem k Manageru“ a žádný příchozí port nepotřebuje.

Za tím raději ukážu, než abych předstíral. Arcane zveřejňuje návod na nastavení socket proxy , jehož premisa je, že přímé připojení socketu „dává Arcane plný přístup k Dockeru“ a proxy ho zúží jen na potřebná volání API. Stejná expozice, kvůli které se vyplatí izolovat socket Dockeru kdekoli, a stojí to za to i tady. Tuhle dokumentaci čtu tak, jak ji čte ten, kdo nasazuje, ne jako audit schématu tokenů.

Co Arcane stále neumí?

Dvě mezery proti aktuální dokumentaci Arcane stále platí: žádný LDAP a žádný obecný prohlížeč souborového systému samotného kontejneru. Několik dalších mezer z doby před v2 se od té doby zavřelo.

LDAP chybí. Dokumentace Arcane k jednotnému přihlášení pokrývá OIDC a jen OIDC a ani ona, ani stránka o řízení přístupu nikde nezmiňuje LDAP ani Active Directory. Business Edition Portaineruse naproti tomu integruje s „Active Directory, LDAP a poskytovateli identity kompatibilními s OIDC“. Pokud se vaše organizace ověřuje proti adresáři bez předřazené vrstvy OIDC, je to tvrdá stopka, ne něco k obejití.

Žádný obecný prohlížeč souborů uvnitř kontejnerů. Pohled na kontejner v Arcane ukazuje konfiguraci, mounty, logy a zdroj Compose, ale ne prohlížeč souborového systému samotného kontejneru. Nyní ale má Volume Workspace, který umí procházet a upravovat soubory uvnitř svazků Dockeru, takže zbývající mezera je užší než starý popis „bez prohlížeče souborů“.

Tyhle opravy stojí za to říct naplno, protože popis Arcane jako „bez RBAC, bez skenování zranitelností“ už neplatí. RBAC dorazil s v2.0.0 dne 7. června 2026a skenování Trivy je zdokumentované a běží podle rozvrhu. Posunulo se i logování aktivity: dokumentace Arcane k aktivitě popisuje Activity Center pokrývající pully, buildy, akce životního cyklu, skeny a čištění, vedle protokolu událostí se závažností, typem, časovým razítkem a uživatelem, který každou akci vyvolal, pokud ho Arcane dokáže přiřadit. Zda exportuje do Syslogu tak jako úroveň Business u Portaineru, dokumentace neřeší.

Co rychlost vydávání nespraví, je stáří. Repozitář Arcane vznikl v dubnu 2025. Portainer má za sebou roky nastřádaných odpovědí na Stack Overflow, návodů třetích stran a integrací, a když v 11 večer narazíte na něco divného, právě ten rozdíl pocítíte.

Kdo by měl přejít na Arcane a kdo ne?

Přejděte na Arcane, pokud jste v Portaineru za třemi uzly a chcete vymezený víceuživatelský přístup s Compose verzovaným v gitu, bez debaty o licencích. Zůstaňte, kde jste, pokud máte tři uzly nebo méně. Spočítat hostitele vyřeší většinu téhle otázky rychleji než jakýkoli seznam funkcí.

Tři profily, pro které je Arcane jasné ano:

• Provozovatelé za stropem tří uzlů Portaineru, kteří potřebují vymezený přístup. Nad tři uzly tyhle schopnosti u Portaineru něco stojí a u Arcane nic, a role jsou dost jemné na to, aby někdo dostal Deployer v jednom prostředí a Viewer všude jinde.
• Provozovatelé, kteří chtějí soubory Compose jako zdroj pravdy. Pokud přechod pohání to, že definice stacků žijí v databázi místo v repozitáři, je to strukturální shoda, ne preference. Migrační víkend se z větší části stráví sepisováním toho, co už provozujete, což je práce, kterou jste stejně dlužili.
• Provozovatelé konsolidující více hostitelů, včetně těch za NATem. Agenti v režimu edge nepotřebují na vzdálené straně žádný příchozí port, clustery Swarm se spravují z uzlu manageru a vzdálená prostředí nestojí nic.

Dva profily, pro které to neplatí:

• Kdokoli se třemi uzly nebo méně. Business Edition je v této velikosti zdarma s plnou sadou funkcí, takže přechod utratí okno výpadku a víkend za schopnosti, které už máte. Jako alternativa Portaineru je Arcane schopný; důvod k přechodu to ale stále není.
• Kdokoli, kdo potřebuje LDAP nebo nemůže stacky odstavit. Adresářové ověřování není k dispozici a migrace stále vyžaduje plánované přepnutí. Ani jedno nemá chytré obejití.

K tomu verdiktu patří jedna podmínka. Pokud je opětovné nasazení GitOps přesně to, kvůli čemu přecházíte, použijte v2.10.0 nebo novější. Chyba s vyčerpáním disku hlášená u v2.8.0 a v2.9.0 je tam opravená.

ČTĚTE

Jak získat Docker na VPS: Komplexní návod k použití VPS pro kontejnerizaci 🗂️

Časté dotazy