Recenzja Arcane dla Dockera: czy jest gotowe zastąpić Portainera?

Arcane dostarczyło pełną kontrolę dostępu opartą na rolach 7 czerwca 2026 r., w wydaniu v2.0.0. Skanuje też Twoje obrazy pod kątem znanych podatności według ustalonego przez Ciebie harmonogramu. Żadna z tych rzeczy nie była prawdą, gdy Brandon Lee opublikował swoje pierwsze wrażenia z Arcane 29 grudnia 2025 r., nieco ponad pięć miesięcy przed wydaniem RBAC.

Ta luka to obecnie niewygodna część każdej recenzji Arcane dla Dockera. Narzędzie jest już w wersji v2.10.2, wydanej 5 września 2026 r., niecałe dwa tygodnie po v2.9.0. Wydanie v2.10.0 naprawiło omawiany niżej wyciek klonów GitOps i dodało eksperymentalny przepływ Convert to Compose dla działających kontenerów. Lista funkcji napisana nawet kilka dni wcześniej opisuje inny produkt.

TL;DR

Arcane w wersji v2.10.2 to sensowny zamiennik Portainera dla odpowiedniego operatora. Dostarcza pełne RBAC, logowanie jednokrotne OIDC, skanowanie podatności Trivy i ponowne wdrażanie GitOps bez kosztów i bez limitu węzłów. Portainer trzyma tę hierarchię ról w Business Edition powyżej trzech węzłów. 4 na 5. Hamuje je krótki staż, nie możliwości.

• Przesiądź się, gdy przekroczysz trzeci węzeł Portainera i potrzebujesz ról, które określają, kto może dotykać czego. Dostajesz sześć wbudowanych ról, role własne, przypisania per środowisko i mapowanie claimów grup OIDC, bez opłat i bez liczników.
• Skanowanie podatności jest w zestawie. Arcane uruchamia Trivy, otwartoźródłowy skaner obrazów, według harmonogramu cron i przechowuje wyniki per obraz.
• Portainer Business Edition jest darmowy do trzech węzłów, bez ograniczeń funkcji. Poniżej tej granicy masz już RBAC i SSO, więc argument Arcane o darmowym dostępie jest znacznie słabszy.
• Nadal nie ma bezpośredniego importu stacków Portainera. v2.10.0 potrafi eksperymentalnie przekształcić działające kontenery w projekty Compose, co ogranicza część ręcznej pracy, ale nadal musisz przejrzeć wygenerowany YAML i zaplanować przełączenie, bo nazwy i opublikowane porty mogą kolidować, dopóki oryginały działają. Najpierw zrób kopię zapasową wolumenów.
• Zabezpiecz ENCRYPTION_KEY przed produkcją i ustaw APP_URL poprawnie. ENCRYPTION_KEY nadal ma domyślną wartość deweloperską, a logowanie kluczem passkey nie zadziała, dopóki APP_URL nie wskaże nazwy hosta HTTPS, pod którą użytkownicy naprawdę wchodzą. JWT_SECRET nie jest już używany, zgodnie z aktualną dokumentacją instalacji.
• Błąd GitOps z wyczerpaniem dysku zgłoszony dla v2.8.0 i v2.9.0 został naprawiony w v2.10.0. Poprawka usuwa pozostałe tymczasowe katalogi klonów Git zamiast pozwalać im narastać na hoście managera.
• LDAP nadal nie ma. Integracja tożsamości to wyłącznie OIDC.

Jak powstała ta ocena: to recenzja oparta na dowodach, a nie test praktyczny. Bez sponsoringu, bez zapłaty, bez udostępnionego produktu, bez kontaktu z opiekunem projektu. Każde twierdzenie o funkcjach sprawdzono z aktualną dokumentacją i notami wydania Arcane, a każde twierdzenie o niezawodności prowadzi do datowanego zgłoszenia w publicznym trackerze projektu lub do wskazanego z nazwiska operatora piszącego o własnym wdrożeniu. Nikt tutaj nie uruchamiał Arcane, żeby to napisać, więc tam, gdzie ogranicza to ocenę (jak działa interfejs, jak znosi długotrwałe obciążenie), tekst mówi to wprost zamiast zgadywać.

Co Arcane daje za darmo, czego nie daje Portainer?

Głównie jedno: pełną kontrolę dostępu opartą na rolach. Portainer CE daje podstawowe zarządzanie użytkownikami; hierarchia ról jest w Business Edition. Arcane dostarcza ją za darmo przy dowolnej liczbie węzłów, obok skanowania Trivy, ponownego wdrażania GitOps, obsługi Swarm, logowania passkey, zdalnych agentów i kopii zapasowych S3 dodanych w v2.9.0.

RBAC to część warta dokładnego przyjrzenia się, bo „ma RBAC” oznacza bardzo różne rzeczy. Dokumentacja kontroli dostępu Arcane opisuje sześć niezmiennych wbudowanych ról: Admin, Editor, No-Shell Editor, Deployer, Monitor i Viewer. Każdą z nich można sklonować do roli własnej i zaznaczyć pojedyncze uprawnienia, które mają <resource>:<action> postać taką jak containers:start. Przypisania są globalne lub per środowisko, a użytkownik może mieć kilka naraz. Dokumentacja podaje przykład wprost: Editor na prod, Viewer na stagingu.

Dla wdrożenia SSO liczy się to, że przypisywaniem ról może sterować sam dostawca tożsamości: „Przy każdym logowaniu Arcane odczytuje claim grupy użytkownika i ponownie synchronizuje jego przypisania pochodzące z OIDC”, a użytkownik w kilku zmapowanych grupach dostaje ich sumę. To model uprawnień, którego Portainer CE nigdy nie miał.

Skanowanie podatności to drugi element. Dokumentacja skanowania Arcane stwierdza, że „skany są opcjonalne, działają według harmonogramu cron, a wyniki są przechowywane per obraz”, przy czym wyniki są pokazywane w interfejsie. Domyślnie uruchamiają się codziennie o północy, trivyIgnoreUnfixed zawęża wyniki do podatności ze znaną poprawką, a Trivy jest dostarczane w obrazie narzędzi z przypiętą wersją, więc aktualizacje skanera nie są Twoim zmartwieniem.

Teraz przeciwwaga, i to spora. Własna strona Portainera porównująca CE i BE mówi, że Business Edition „jest darmowa na zawsze do 3 węzłów. Bez okresu próbnego. Bez karty kredytowej. Bez ograniczeń funkcji”. To pełny zestaw BE: RBAC z własną hierarchią ról, OIDC, logi audytu z eksportem do Syslog, zaawansowany GitOps. Warunki oferty Take 3 wydają roczną licencję odnawianą co roku bezpłatnie, dopóki pozostajesz przy trzech węzłach lub mniej.

Rachunek darmowego poziomu zaczyna więc działać na korzyść Arcane dopiero od czwartego węzła. Poniżej nie ma żadnej bariery płatności. Arcane nadal oferuje coś przy jednym lub dwóch węzłach: brak klucza licencyjnego, brak odnowienia do pamiętania, projekt, który można sforkować. Ale to nie ten sam argument co „RBAC kosztuje”.

Arcane to jedno z czterech narzędzi poważnie ubiegających się o miejsce Portainera, a pozostałe dzielą się według innych kryteriów.

CZYTAJ

Alternatywy dla Portainera: przewodnik po Dockge, Arcane, Dockhand i Komodo według zastosowań

Jak niezawodne jest Arcane w tej chwili?

Lepiej, niż wyglądało to przy v2.9.0, ale wciąż młodo. Historia błędów Arcane czyta się jak historia aktywnego projektu, który naprawia rzeczy, a poważny błąd GitOps z wyczerpaniem dysku zgłoszony dla v2.8.0 i v2.9.0 został naprawiony w v2.10.0 31 sierpnia 2026 r.

Operator zgłosił 26 sierpnia 2026 r., że synchronizacja GitOps zostawia po sobie katalog klonu: "gitops-<N> katalogi klonów narastają w tempie około 1000 dziennie (~9 GB/dzień) i nigdy nie są sprzątane, aż w końcu zapełniają dysk." Sześć dni w tym tempie dało około 6467 katalogów i 40 GB. Gdy dysk się zapełnił, manager nie mógł już zapisywać do swojej bazy SQLite i wpadł w pętlę restartów, dochodząc do 389 restartów i zrywając przy tym połączenia agentów edge oraz wywołania API. Zgłoszenie jest już zamknięte, a v2.10.0 zawiera poprawkę sprzątającą pozostałe tymczasowe katalogi klonów Git.

Jeśli nadal jesteś na v2.8.0 lub v2.9.0: zaktualizuj, zanim zaczniesz polegać na częstej synchronizacji GitOps. Poprawka wycieku klonów trafia do v2.10.0.

Starsza historia jest bardziej budująca. Pewne zawieszenie po aktualizacji między 2.0 a 2.0.1 zostało rozwiązane. Błąd, w którym „Update Projects” obejmował każdy kontener na hoście zamiast tylko wybranego projektu, został zamknięty scalonym PR-em z poprawką #2289. Odpytywanie obrazów, które po cichu się nie uruchamiało w v1.13.2, zostało naprawione w v1.14.0. Trzy błędy, trzy poprawki.

Sama liczba otwartych zgłoszeń mówi bardzo niewiele przy projekcie wydającym w takim tempie. Projekty, do których nikt nie zgłasza błędów, nie są przez to bardziej niezawodne.

Moja ocena wciąż brzmi: to problem stażu, a nie możliwości. Szybkie wydawanie to powód, dla którego luki w RBAC i skanowaniu w ogóle się domknęły, i zarazem powód, dla którego v2.10.0 musiało naprawić poważną wadę GitOps niecały tydzień po v2.9.0. Ryzyko siedzi w nowym kodzie, a jego przyjęcie to wybór.

Ile naprawdę kosztuje przejście z Portainera?

Z grubsza: okno przestoju i trochę ręcznego sprzątania. Arcane nadal nie ma bezpośredniego importu stacków Portainera, ale v2.10.0 dodaje eksperymentalną akcję Convert to Compose dla działających kontenerów. Generuje ona plik Compose, podczas gdy oryginały dalej działają, co zdejmuje część pracy przy odtwarzaniu YAML-a. Nadal musisz przejrzeć montowania bind, sieci, wartości środowiskowe i samo przełączenie; nazwy i opublikowane porty mogą kolidować, dopóki oryginały nie zostaną zatrzymane, więc to nie jest przycisk migracji bez przestoju.

Przed v2.10.0 własne forum projektu odzwierciedlało w pełni ręczną ścieżkę. Operator z ponad 80 kontenerami na pięciu serwerach zapytał, czy możliwa jest migracja na żywo bez wcześniejszego wyłączania usług wystawionych do sieci. Odpowiedź kogoś, kto już to zrobił: „nie będziesz mieć wyjścia, tylko usunąć istniejące kontenery (a więc stacki Portainera) i odtworzyć je od zera w Arcane”. Jego kolejność: czyste wyłączenie, kopia zapasowa, usunięcie, skopiowanie danych, odtworzenie i ponowne wdrożenie.

W praktyce: kopie zapasowe wolumenów, zanim czegokolwiek dotkniesz, i okno serwisowe dobrane zarówno do liczby uruchomionych stacków, jak i do ilości danych do przeniesienia. Odtworzenie kontenerów to zwykle szybka część; kopiowanie dużych wolumenów i podnoszenie zależnych usług we właściwej kolejności może wydłużyć okno. Uwaga terminologiczna na czas planowania: to, co Portainer nazywa stackiem, Arcane nazywa projektem.

Koszt czasowy pojawia się nawet w skali homelabu. Moises Aguirre, pisząc 28 lutego 2026 r. o przenoszeniu homelabu z Portainera, nazwał to „solidnym weekendem pracy (i mierzeniem się z własnymi demonami)”, a demonami był jego własny bałagan: musiał zaudytować każdy uruchomiony kontener i napisać YAML dla usług, które wcześniej „po prostu wyklikał”. To jego doświadczenie, a nie reguła, ale schemat się powtarza.

Jedna rzecz do wyłapania, zanim przeniesiesz pliki Compose. Noty wydania v2.7.0 zawęziły rozwiązywanie zmiennych do czterech źródeł: Twoich zmiennych globalnych w .env.global, własnego pliku .env projektu, wartości domyślnych zapisanych w samym pliku compose oraz strefy czasowej i ustawień regionalnych ze środowiska Arcane. Deklarowany efekt jest taki, że projekt wdrożony przez Arcane rozwiązuje zmienne tak samo jak docker compose up w katalogu projektu. To bardziej poprawne zachowanie. Oznacza też, że wszystko, co po cichu dziedziczyło wartość ze środowiska kontenera managera, teraz rozwiąże się do czegoś innego albo do niczego, i zrobi to bez żadnego ostrzeżenia.

Nic z tego nie jest wadą produktu. To jednorazowy koszt, na tyle przewidywalny, że da się go zaplanować, a to najważniejsze, czego oczekuje się od migracji.

Twórz na VPS Linux z dostępem root, NVMe i mocą AMD EPYC.

Zobacz plany Linux

Co trzeba zabezpieczyć przed produkcją?

Jeden klucz szyfrowania, publiczny URL i TLS. Arcane tworzy domyślne konto administratora przy pierwszym uruchomieniu i wymusza zmianę hasła przy pierwszym logowaniu, co jest rozsądnym ustawieniem domyślnym. Dwa ustawienia muszą być poprawne przed produkcją. Pierwsze to ENCRYPTION_KEY; drugie to APP_URL.

Opis zmiennych środowiskowych nadal wymienia ENCRYPTION_KEY z wartością domyślną arcane-dev-key-32-characters!!!, podczas gdy dokumentacja instalacji każe podać unikalną wartość 32-bajtową. Zmień ją przed produkcją. Zmieniło się jeszcze coś: dokumentacja instalacji mówi teraz, że JWT_SECRET nie jest już używany. Arcane samo generuje klucz podpisywania sesji; pozostawienie JWT_SECRET w konfiguracji daje tylko ostrzeżenie przy starcie, więc usuń go ze środowiska. Dokumentacja instalacji określa, że ENCRYPTION_KEY „musi mieć długość 32 bajtów (surowo, base64 lub hex)”.

Higiena wersji też należy do tej listy. Arcane opublikowało w 2026 r. kilka biuletynów bezpieczeństwa; jeden o wysokiej wadze, opublikowany 29 lipca 2026 r., wymienia jako podatne wersje starsze niż v2.5.0 i opisuje, jak delegowane uprawnienie users:update pozwalało zresetować hasło administratora. Jako wydanie z poprawką wskazuje v2.6.0, więc v2.10.0 nie jest podatne, ale to konkretny powód, by nie zostawiać wdrożenia produkcyjnego na starym tagu.

APP_URL ma domyślną wartość http://localhost:3552, a to ma konsekwencję funkcjonalną wykraczającą poza higienę. Logowanie passkey i MFA passkey działają na WebAuthn, a dokumentacja passkey Arcane mówi wprost: „Przeglądarki udostępniają API WebAuthn tylko w bezpiecznym kontekście, więc passkeys wymagają HTTPS (lub localhost)”. Identyfikator relying party jest wyprowadzany z APP_URL, passkeys są powiązane z tą nazwą hosta, a jeśli APP_URL nie zawiera nazwy hosta, usługa passkey się nie inicjalizuje. Na zwykłym HTTP Arcane całkowicie ukrywa elementy passkey. Wdróż na gołym IP z portem, a flagowa funkcja uwierzytelniania v2 po prostu się nie pojawi. Dokumentacja mówi to jasno: „Ustaw APP_URL na URL, pod który Twoi użytkownicy naprawdę wchodzą, przez HTTPS, zanim ktokolwiek zarejestruje passkey”.

Zdalni agenci decydują, co musisz otworzyć. Dokumentacja środowisk Arcane mówi, że w trybie bezpośrednim „Manager łączy się z Agentem po TCP 3553”, więc ten port musi być osiągalny przychodząco na zdalnym hoście. W trybie edge „Agent łączy się wychodząco z Managerem” i nie potrzebuje żadnego portu przychodzącego.

Poza tym wolę wskazać niż udawać. Arcane publikuje poradnik konfiguracji proxy dla socketu , którego założeniem jest, że bezpośrednie zamontowanie socketu „daje Arcane pełny dostęp do Dockera”, a proxy zawęża to do potrzebnych wywołań API. To ta sama ekspozycja, przez którą izolowanie socketu Dockera opłaca się wszędzie, i tutaj też. Czytam tę dokumentację tak, jak czyta ją ktoś wdrażający, bez audytu schematu tokenów.

Czego Arcane nadal nie robi?

Dwie luki wciąż utrzymują się wobec aktualnej dokumentacji Arcane: brak LDAP i brak ogólnej przeglądarki systemu plików samego kontenera. Kilka innych luk sprzed v2 od tego czasu się domknęło.

LDAP nie ma. Dokumentacja logowania jednokrotnego Arcane obejmuje OIDC i tylko OIDC, a ani ona, ani strona kontroli dostępu nigdzie nie wspominają o LDAP czy Active Directory. Business Edition Portaineradla odmiany integruje się z „Active Directory, LDAP i dostawcami tożsamości zgodnymi z OIDC”. Jeśli Twoja organizacja uwierzytelnia się wobec katalogu bez warstwy OIDC z przodu, to twarda blokada, a nie coś do obejścia.

Brak ogólnej przeglądarki plików wewnątrz kontenerów. Widok kontenera w Arcane pokazuje konfigurację, montowania, logi i źródło Compose, ale nie przeglądarkę systemu plików samego kontenera. Jest za to Volume Workspace, który pozwala przeglądać i edytować pliki wewnątrz wolumenów Dockera, więc pozostała luka jest węższa niż stary opis „brak przeglądarki plików”.

Te sprostowania warto powiedzieć wprost, bo opis Arcane jako „bez RBAC, bez skanowania podatności” już nie jest aktualny. RBAC pojawiło się wraz z v2.0.0 7 czerwca 2026 r., a skanowanie Trivy jest udokumentowane i działa według harmonogramu. Rejestrowanie aktywności też się zmieniło: dokumentacja aktywności Arcane opisuje Activity Center obejmujące pobrania, budowania, akcje cyklu życia, skany i czyszczenia, obok dziennika zdarzeń z wagą, typem, znacznikiem czasu i użytkownikiem, który wywołał daną akcję, o ile Arcane potrafi ją przypisać. Czy eksportuje do Syslog tak jak poziom Business Portainera, dokumentacja nie rozstrzyga.

Czego tempo wydań nie naprawi, to wiek. Repozytorium Arcane powstało w kwietniu 2025 r. Portainer ma za sobą lata nagromadzonych odpowiedzi na Stack Overflow, poradników zewnętrznych i integracji, i gdy o 23:00 trafisz na coś dziwnego, właśnie tę różnicę czujesz.

Kto powinien przejść na Arcane, a kto nie?

Przejdź na Arcane, jeśli masz w Portainerze więcej niż trzy węzły i chcesz wielodostępu z ograniczonym zakresem oraz Compose śledzonego w gicie, bez rozmów o licencjach. Zostań, jeśli masz trzy węzły lub mniej. Policzenie hostów rozstrzyga większość tej kwestii szybciej niż jakakolwiek lista funkcji.

Trzy profile, dla których Arcane to jednoznaczne tak:

• Operatorzy powyżej limitu trzech węzłów Portainera, którzy potrzebują dostępu o ograniczonym zakresie. Powyżej trzech węzłów te możliwości kosztują w Portainerze, a w Arcane nie, a role są na tyle szczegółowe, by dać komuś Deployer w jednym środowisku i Viewer wszędzie indziej.
• Operatorzy, którzy chcą plików Compose jako źródła prawdy. Jeśli motorem zmiany jest to, że definicje stacków żyją w bazie danych zamiast w repozytorium, to dopasowanie strukturalne, a nie preferencja. Weekend migracji schodzi głównie na spisaniu tego, co i tak już uruchamiasz, a tę pracę i tak byłeś winien.
• Operatorzy konsolidujący wiele hostów, w tym te za NAT-em. Agenci w trybie edge nie potrzebują portu przychodzącego po stronie zdalnej, klastry Swarm są zarządzane z węzła managera, a zdalne środowiska nic nie kosztują.

Dwa profile, dla których tak nie jest:

• Każdy z trzema węzłami lub mniej. Business Edition jest w tej skali darmowa z pełnym zestawem funkcji, więc przesiadka kosztuje okno przestoju i weekend, by uzyskać możliwości, które już masz. Jako alternatywa dla Portainera Arcane jest zdolne; to nadal nie jest powód, by się przenosić.
• Każdy, kto potrzebuje LDAP albo nie może wyłączyć stacków. Uwierzytelnianie katalogowe nie jest dostępne, a migracja nadal wymaga zaplanowanego przełączenia. Żadne z nich nie ma sprytnego obejścia.

Do tego werdyktu dochodzi jeden warunek. Jeśli ponowne wdrażanie GitOps jest właśnie tym, dla czego się przenosisz, użyj v2.10.0 lub nowszej. Błąd z wyczerpaniem dysku zgłoszony dla v2.8.0 i v2.9.0 jest tam naprawiony.

CZYTAJ

Jak uruchomić Docker na VPS: kompleksowy przewodnik po wykorzystaniu VPS do konteneryzacji 🗂️

Często zadawane pytania