Arcane Docker-anmeldelse: Er den klar til at erstatte Portainer?

Arcane leverede fuld rollebaseret adgangskontrol den 7. juni 2026 i udgivelsen v2.0.0. Den scanner også dine images for kendte sårbarheder efter en tidsplan, du selv sætter. Ingen af delene var sande, da Brandon Lee udgav sit førstehåndsindtryk af Arcane den 29. december 2025, lidt over fem måneder før RBAC-udgivelsen.

Den kløft er den akavede del af enhver Arcane Docker-anmeldelse lige nu. Værktøjet er allerede på v2.10.2, udgivet den 5. september 2026, under to uger efter v2.9.0. Udgivelsen v2.10.0 rettede den GitOps-klonlækage, der beskrives nedenfor, og tilføjede et eksperimentelt Convert to Compose-flow til kørende containere. En funktionsliste skrevet bare et par dage tidligere beskriver et andet produkt.

TL;DR

Arcane på v2.10.2 er en brugbar erstatning for Portainer for den rette driftsansvarlige. Den leverer fuld RBAC, OIDC single sign-on, Trivy-sårbarhedsscanning og GitOps-genudrulning uden omkostninger og uden loft over antal noder. Portainer holder det rollehierarki i Business Edition ud over tre noder. 4 ud af 5. Det, der holder den tilbage, er den korte historik, ikke evnerne.

• Skift, når du er forbi Portainers tredje node og har brug for roller, der afgrænser, hvem der må røre hvad. Du får seks indbyggede roller, brugerdefinerede roller, tildeling pr. miljø og mapping af OIDC-gruppeclaims, uden betaling og uden måling.
• Sårbarhedsscanning er med i pakken. Arcane kører Trivy, en open source-imagescanner, efter en cron-tidsplan og gemmer resultaterne pr. image.
• Portainer Business Edition er gratis op til tre noder, uden funktionsbegrænsninger. Under den grænse har du allerede RBAC og SSO, så Arcanes argument om gratis adgang er meget svagere der.
• Der er stadig ingen direkte import af Portainer-stacks. v2.10.0 kan eksperimentelt konvertere kørende containere til Compose-projekter, hvilket sparer noget manuelt arbejde, men du skal stadig gennemgå den genererede YAML og planlægge en omlægning, fordi navne og publicerede porte kan kollidere, mens originalerne kører. Tag backup af volumes først.
• Hærd ENCRYPTION_KEY før produktion, og sæt APP_URL korrekt. ENCRYPTION_KEY har stadig en udviklingsstandardværdi, og passkey-login virker ikke, før APP_URL peger på det HTTPS-værtsnavn, brugerne faktisk besøger. JWT_SECRET bruges ikke længere ifølge den aktuelle installationsdokumentation.
• GitOps-fejlen med opbrugt diskplads, der blev rapporteret mod v2.8.0 og v2.9.0, er rettet i v2.10.0. Rettelsen rydder efterladte midlertidige Git-klonmapper op i stedet for at lade dem hobe sig op på manager-værten.
• LDAP mangler stadig. Identitetsintegration er kun OIDC.

Sådan blev denne vurdering lavet: dette er en evidensbaseret gennemgang, ikke en hands-on-test. Ingen sponsorering, ingen betaling, intet leveret produkt, ingen kontakt med vedligeholderen. Hver påstand om funktioner er tjekket mod Arcanes aktuelle dokumentation og udgivelsesnoter, og hver påstand om pålidelighed kan spores til en dateret sag i projektets offentlige tracker eller til en navngiven driftsansvarlig, der skriver om sin egen installation. Ingen her kørte Arcane for at skrive den, så hvor det begrænser vurderingen (hvordan grænsefladen føles, hvordan den holder under vedvarende belastning), siger artiklen det i stedet for at gætte.

Hvad giver Arcane dig gratis, som Portainer ikke gør?

Én ting, primært: fuld rollebaseret adgangskontrol. Portainer CE giver dig grundlæggende brugerstyring; rollehierarkiet er Business Edition. Arcane leverer det gratis ved ethvert antal noder sammen med Trivy-scanning, GitOps-genudrulning, Swarm-understøttelse, passkey-login, fjernagenter og S3-backups tilføjet i v2.9.0.

RBAC er den del, der er værd at se nærmere på, fordi "har RBAC" dækker over mange meget forskellige ting. Arcanes dokumentation om adgangskontrol beskriver seks uforanderlige indbyggede roller: Admin, Editor, No-Shell Editor, Deployer, Monitor og Viewer. Du kan klone enhver af dem til en brugerdefineret rolle og afkrydse individuelle tilladelser, som følger en <resource>:<action> form som containers:start. Tildelinger er globale eller pr. miljø, og en bruger kan have flere på én gang. Dokumentationen giver eksemplet direkte: Editor på prod, Viewer på staging.

Det, der betyder noget for en SSO-udrulning, er, at rolletildelingen kan styres fra identitetsudbyderen selv: "Ved hvert login læser Arcane brugerens gruppeclaim og synkroniserer deres OIDC-baserede tildelinger igen", og en bruger i flere mappede grupper får foreningsmængden af dem. Det er den tilladelsesmodel, Portainer CE aldrig har haft.

Sårbarhedsscanning er den anden brik. Arcanes scanningsdokumentation fastslår, at "scanninger er tilvalg, kører efter en cron-tidsplan, og resultaterne gemmes pr. image", med resultaterne vist i brugerfladen. Standarden er dagligt ved midnat, trivyIgnoreUnfixed indsnævrer resultaterne til sårbarheder med en kendt rettelse, og Trivy leveres i et værktøjsimage med fastlåst version, så scanneropdateringer er ikke dit ansvar.

Nu modvægten, og den er stor. Portainers egen side om CE kontra BE siger, at Business Edition "er gratis for altid op til 3 noder. Ingen prøveperiode. Intet kreditkort. Ingen funktionsbegrænsninger." Det er hele BE-pakken: RBAC med sit eget rollehierarki, OIDC, auditlogs med Syslog-eksport, avanceret GitOps. Take 3-vilkårene udsteder en etårig licens, der fornys årligt uden omkostninger, så længe du bliver på tre noder eller færre.

Så regnestykket for det gratis niveau begynder først at falde ud til Arcanes fordel ved node fire. Under det er der ingen betalingsmur. Arcane tilbyder stadig noget ved en eller to noder: ingen licensnøgle, ingen fornyelse at huske, et projekt du kan forke. Men det er ikke det samme argument som "RBAC koster penge".

Arcane er et af fire værktøjer, der seriøst konkurrerer om Portainers plads, og de andre deler sig efter andre linjer.

LÆS

Alternativer til Portainer: en brugsscenarie-guide til Dockge, Arcane, Dockhand og Komodo

Hvor pålidelig er Arcane lige nu?

Bedre, end det så ud ved v2.9.0, men stadig ung. Arcanes fejlhistorik læses som et aktivt projekt, der retter ting, og den alvorlige GitOps-fejl med opbrugt diskplads, rapporteret mod v2.8.0 og v2.9.0, blev rettet i v2.10.0 den 31. august 2026.

En driftsansvarlig rapporterede den 26. august 2026, at GitOps-synkronisering lækker en klonmappe: "gitops-<N> klonmapper hober sig op med cirka 1.000 om dagen (~9 GB/dag) og bliver aldrig ryddet op, så disken til sidst fyldes." Seks dage af den slags løb op i cirka 6.467 mapper og 40 GB. Da disken var fuld, kunne manageren ikke længere skrive til sin SQLite-database og gik i en genstartsløkke, nåede en genstartstæller på 389 og trak edge-agent-forbindelser og API-kald med ned. Sagen er nu lukket, og v2.10.0 indeholder oprydningsrettelsen for efterladte midlertidige Git-klonmapper.

Hvis du stadig er på v2.8.0 eller v2.9.0: opgrader, før du stoler på hyppig GitOps-synkronisering. Rettelsen af klonlækagen kommer i v2.10.0.

Den ældre historik er mere opmuntrende. Et hæng efter opdatering mellem 2.0 og 2.0.1 blev løst. En fejl, hvor "Update Projects" ramte hver eneste container på værten i stedet for det valgte projekts, blev lukket med den sammenflettede rettelses-PR #2289. Image-polling, der stille og roligt ikke blev udløst i v1.13.2, blev rettet i v1.14.0. Tre fejl, tre rettelser.

Det rå antal åbne sager siger meget lidt i sig selv om et projekt, der udgiver i dette tempo. Projekter, som ingen indberetter fejl mod, er ikke mere pålidelige af den grund.

Min vurdering er stadig, at dette er et problem med anciennitet snarere end evner. Hurtig udgivelse er grunden til, at hullerne i RBAC og scanning overhovedet blev lukket, og det er også grunden til, at v2.10.0 måtte rette en alvorlig GitOps-fejl under en uge efter v2.9.0. Ny kode er der, hvor risikoen ligger, og at tage den i brug er et valg.

Hvad koster det egentlig at skifte fra Portainer?

Et nedetidsvindue og noget manuel oprydning, groft sagt. Arcane har stadig ingen direkte import af Portainer-stacks, men v2.10.0 tilføjer en eksperimentel Convert to Compose-handling til kørende containere. Den genererer en Compose-fil, mens originalerne bliver ved med at køre, hvilket fjerner noget af YAML-genopbygningsarbejdet. Du skal stadig gennemgå bind mounts, netværk, miljøværdier og selve omlægningen; navne og publicerede porte kan kollidere, indtil originalerne er stoppet, så dette er ikke en migrationsknap uden nedetid.

Før v2.10.0 afspejlede projektets eget forum en helt manuel vej. En driftsansvarlig med mere end 80 containere fordelt på fem servere spurgte, om en live-migration var mulig uden først at tage de webvendte tjenester ned. Svaret fra en, der allerede havde gjort det: "du har ikke andet valg end at slette de eksisterende containere (og dermed Portainer-stacks) og genskabe dem fra bunden i Arcane." Hans rækkefølge: luk pænt ned, tag backup, slet, kopier dataene over, genskab og genudrul.

I praksis: backup af volumes, før du rører noget, og et vedligeholdelsesvindue dimensioneret efter både hvor mange stacks du kører, og hvor mange data der skal flyttes. Genskabelse af containere er som regel den hurtige del; kopiering af store volumes og at få afhængige tjenester op i den rigtige rækkefølge kan trække vinduet ud. En terminologinote, mens du planlægger: det, Portainer kalder en stack, kalder Arcane et projekt.

Tidsomkostningen mærkes selv i homelab-skala. Moises Aguirre, der den 28. februar 2026 skrev om at flytte et homelab væk fra Portainer, kaldte det "en solid weekends arbejde (og at se mine dæmoner i øjnene)", og dæmonerne var hans eget rod: han måtte gennemgå hver container, han kørte, og skrive YAML til tjenester, han tidligere "bare havde klikket til eksistens". Det er hans erfaring snarere end en regel, men mønstret går igen.

Én ting at fange, før du flytter Compose-filer over. Udgivelsesnoterne til v2.7.0 indsnævrede variabelopløsning til fire kilder: dine globale variabler i .env.global, projektets egen .env -fil, standardværdier skrevet ind i selve compose-filen samt tidszone og locale fra Arcanes miljø. Den erklærede effekt er, at et projekt udrullet gennem Arcane opløser sine variabler på samme måde, som docker compose up gør i projektmappen. Det er mere korrekt adfærd. Det betyder også, at alt, der stille og roligt arvede en værdi fra managerens eget containermiljø, nu vil opløses til noget andet, eller til ingenting, og det gør det uden at klage.

Intet af dette er en fejl i produktet. Det er en engangsomkostning, forudsigelig nok til at planlægge efter, og det er det vigtigste, man ønsker sig af en migration.

Byg på en Linux VPS med root-adgang, NVMe og AMD EPYC-kraft.

Se Linux-planer

Hvad skal du hærde før produktion?

Én krypteringsnøgle, den offentlige URL og TLS. Arcane opretter en standard-adminkonto ved første kørsel og tvinger en adgangskodeændring ved første login, hvilket er en fornuftig standard. To indstillinger skal være rigtige før produktion. Den første er ENCRYPTION_KEY; den anden er APP_URL.

Referencen for miljøvariabler angiver stadig ENCRYPTION_KEY med en standardværdi på arcane-dev-key-32-characters!!!, mens installationsdokumentationen beder dig levere en unik 32-byte-værdi. Skift den før produktion. Én ting mere har ændret sig: installationsdokumentationen siger nu, at JWT_SECRET ikke længere bruges. Arcane genererer selv sessionssigneringsnøglen; at lade JWT_SECRET være konfigureret giver kun en advarsel ved opstart, så fjern den fra miljøet. Installationsdokumentationen specificerer, at ENCRYPTION_KEY "skal være 32 bytes lang (rå, base64 eller hex)."

Versionshygiejne hører også til på den tjekliste. Arcane udgav flere sikkerhedsadvarsler i 2026; én advarsel med høj alvorlighed, udgivet den 29. juli 2026, angiver udgivelser før v2.5.0 som berørte og beskriver, hvordan en delegeret users:update -tilladelse kunne nulstille en administrators adgangskode. Den nævner v2.6.0 som den rettede udgivelse, så v2.10.0 er ikke berørt, men det er en konkret grund til ikke at lade en produktionsinstallation stå på et gammelt tag.

APP_URL har som standard http://localhost:3552, og denne har en funktionel konsekvens ud over hygiejne. Passkey-login og passkey-MFA kører begge på WebAuthn, og Arcanes passkey-dokumentation er eksplicit: "Browsere eksponerer kun WebAuthn-API'et i en sikker kontekst, så passkeys kræver HTTPS (eller localhost)." Relying party-ID'et udledes af APP_URL, passkeys er bundet til det værtsnavn, og hvis APP_URL ikke indeholder et værtsnavn, initialiseres passkey-tjenesten ikke. På almindelig HTTP skjuler Arcane passkey-kontrollerne helt. Udrul på en bar IP og port, og v2's vigtigste autentificeringsfunktion er der simpelthen ikke. Dokumentationen siger det ligeud: "Sæt APP_URL til den URL, dine brugere faktisk besøger, over HTTPS, før nogen registrerer en passkey."

Fjernagenter afgør, hvad du skal åbne. Arcanes dokumentation om miljøer siger, at i direkte tilstand "forbinder Manageren til Agenten på TCP 3553", så den port skal kunne nås indgående på fjernværten. I edge-tilstand "forbinder Agenten udgående til Manageren" og har slet ikke brug for en indgående port.

Ud over det vil jeg hellere pege end lade som om. Arcane udgiver en vejledning til opsætning af socket-proxy , hvis præmis er, at en direkte socket-mount "giver Arcane fuld adgang til Docker", og at en proxy indsnævrer det til de API-kald, den har brug for. Samme eksponering, som gør Docker-socketen værd at isolere overalt, og det er også værd at gøre her. Jeg læser disse dokumenter, som den, der udruller, læser dem, ikke som en revision af token-ordningen.

Hvad kan Arcane stadig ikke?

To huller holder stadig mod Arcanes aktuelle dokumentation: ingen LDAP og ingen generel browser til en containers eget filsystem. Flere andre huller, der fandtes før v2, er siden lukket.

LDAP mangler. Arcanes single sign-on-dokumentation dækker OIDC og kun OIDC, og hverken den eller siden om adgangskontrol nævner LDAP eller Active Directory nogen steder. Portainers Business Editionintegrerer derimod med "Active Directory, LDAP og OIDC-kompatible identitetsudbydere". Hvis din organisation autentificerer mod et katalog uden et OIDC-lag foran, er det et hårdt stop, ikke en omvej.

Ingen generel filbrowser inde i containere. Arcanes containervisning viser konfiguration, mounts, logs og Compose-kilde, men ikke en browser til containerens eget filsystem. Den har nu et Volume Workspace, der kan gennemse og redigere filer inde i Docker-volumes, så det tilbageværende hul er smallere end den gamle beskrivelse "ingen filbrowser".

Rettelserne er værd at sige ligeud, fordi beskrivelsen af Arcane som "ingen RBAC, ingen sårbarhedsscanning" ikke længere holder. RBAC kom med v2.0.0 den 7. juni 2026, og Trivy-scanning er dokumenteret og kører efter en tidsplan. Aktivitetslogning har også flyttet sig: Arcanes aktivitetsdokumentation beskriver et Activity Center, der dækker pulls, builds, livscyklushandlinger, scanninger og oprydninger, sammen med en hændelseslog med alvorlighed, type, tidsstempel og den bruger, der udløste hver handling, hvor Arcane kan tilskrive den. Om den eksporterer til Syslog, som Portainers Business-niveau gør, er ikke noget, dokumentationen afgør.

Det, udgivelseshastighed ikke løser, er alder. Arcane-repositoriet blev oprettet i april 2025. Portainer har årevis af opsamlede Stack Overflow-svar, tredjepartsvejledninger og integrationer bag sig, og når du støder på noget mærkeligt klokken 23, er det den forskel, du mærker.

Hvem bør skifte til Arcane, og hvem bør ikke?

Skift til Arcane, hvis du er forbi tre noder på Portainer og vil have afgrænset flerbrugeradgang med git-sporet Compose, uden en licenssamtale. Bliv, hvor du er, hvis du er på tre noder eller færre. At tælle værter afgør det meste af dette hurtigere end nogen funktionsliste.

Tre profiler, hvor Arcane er et klart ja:

• Driftsansvarlige forbi Portainers loft på tre noder, som har brug for afgrænset adgang. Over tre noder koster de funktioner penge hos Portainer og intet hos Arcane, og rollerne er finkornede nok til at give nogen Deployer i ét miljø og Viewer alle andre steder.
• Driftsansvarlige, der vil have Compose-filer som sandhedskilde. Hvis det, der driver skiftet, er, at stack-definitioner bor i en database i stedet for et repo, er det et strukturelt match, ikke en præference. Migrationsweekenden går mest med at skrive ned, hvad du allerede kører, hvilket er arbejde, du alligevel skyldte.
• Driftsansvarlige, der konsoliderer flere værter, herunder nogle bag NAT. Agenter i edge-tilstand kræver ingen indgående port på fjernsiden, Swarm-klynger styres fra manager-noden, og fjernmiljøer koster ingenting.

To profiler, hvor det ikke er det:

• Alle på tre noder eller færre. Business Edition er gratis i den størrelse med det fulde funktionssæt, så et skift bruger et nedetidsvindue og en weekend på at få funktioner, du allerede har. Som Portainer-alternativ er Arcane dygtig; det er stadig ikke en grund til at flytte.
• Alle, der har brug for LDAP, eller som ikke kan tage stacks ned. Katalogautentificering er ikke tilgængelig, og migrationen kræver stadig en planlagt omlægning. Ingen af delene har en smart omvej.

Én betingelse følger med den dom. Hvis GitOps-genudrulning specifikt er grunden til, at du flytter, så brug v2.10.0 eller nyere. Fejlen med opbrugt diskplads, der blev rapporteret mod v2.8.0 og v2.9.0, er rettet der.

LÆS

Sådan får du Docker på VPS: En omfattende guide til at bruge VPS til containerisering 🗂️

Ofte stillede spørgsmål