Recensione di Arcane per Docker: è pronto a sostituire Portainer?

Arcane ha rilasciato il controllo degli accessi basato sui ruoli completo il 7 giugno 2026, con la versione v2.0.0. Inoltre analizza le tue immagini alla ricerca di vulnerabilità note, con la pianificazione che decidi tu. Nulla di tutto questo era vero quando Brandon Lee ha pubblicato le sue prime impressioni su Arcane il 29 dicembre 2025, poco più di cinque mesi prima del rilascio del RBAC.

Quel divario è la parte scomoda di qualsiasi recensione di Arcane per Docker in questo momento. Lo strumento è già alla v2.10.2, pubblicata il 5 settembre 2026, meno di due settimane dopo la v2.9.0. La versione v2.10.0 ha corretto la perdita di cloni GitOps discussa più avanti e aggiunto un flusso sperimentale Convert to Compose per i container in esecuzione. Un elenco di funzionalità scritto anche solo pochi giorni prima descrive un prodotto diverso.

TL;DR

Arcane alla v2.10.2 è un sostituto praticabile di Portainer per l'operatore giusto. Offre RBAC completo, single sign-on OIDC, scansione delle vulnerabilità con Trivy e ridistribuzione GitOps senza costi e senza limite di nodi. Portainer riserva quella gerarchia di ruoli alla Business Edition oltre i tre nodi. 4 su 5. Ciò che lo frena è la giovane età, non le capacità.

• Passa ad Arcane una volta superato il terzo nodo di Portainer, quando ti servono ruoli che delimitano chi può toccare cosa. Ottieni sei ruoli integrati, ruoli personalizzati, assegnazione per ambiente e mappatura dei claim di gruppo OIDC, senza pagare e senza contatori.
• La scansione delle vulnerabilità è inclusa. Arcane esegue Trivy, uno scanner di immagini open source, con una pianificazione cron e salva i risultati per immagine.
• Portainer Business Edition è gratuito fino a tre nodi, senza limitazioni di funzionalità. Sotto quella soglia hai già RBAC e SSO, quindi l'argomento dell'accesso gratuito di Arcane pesa molto meno.
• Non esiste ancora un'importazione diretta degli stack di Portainer. La v2.10.0 può convertire in via sperimentale i container in esecuzione in progetti Compose, il che riduce parte del lavoro manuale, ma devi comunque rivedere lo YAML generato e pianificare un passaggio, perché nomi e porte pubblicate possono entrare in conflitto finché gli originali sono in esecuzione. Prima fai il backup dei volumi.
• Metti in sicurezza ENCRYPTION_KEY prima della produzione e imposta APP_URL correttamente. ENCRYPTION_KEY ha ancora un valore predefinito di sviluppo, e l'accesso con passkey non funzionerà finché APP_URL non punterà all'hostname HTTPS che gli utenti aprono davvero. JWT_SECRET non è più usato, secondo la documentazione di installazione attuale.
• Il bug GitOps di esaurimento del disco segnalato sulle v2.8.0 e v2.9.0 è corretto nella v2.10.0. La correzione elimina le directory temporanee di clonazione Git residue invece di lasciarle accumulare sull'host del manager.
• LDAP è ancora assente. L'integrazione delle identità è solo OIDC.

Come è stata fatta questa valutazione: questa è una recensione basata sulle evidenze, non una prova pratica. Nessuna sponsorizzazione, nessun pagamento, nessun prodotto fornito, nessun contatto con il maintainer. Ogni affermazione sulle funzionalità è verificata sulla documentazione e sulle note di rilascio attuali di Arcane, e ogni affermazione sull'affidabilità rimanda a un ticket datato sul tracker pubblico del progetto o a un operatore identificato che racconta il proprio deployment. Nessuno qui ha eseguito Arcane per scriverla, quindi dove questo limita la lettura (come si sente l'interfaccia, come regge sotto carico prolungato) l'articolo lo dice invece di tirare a indovinare.

Cosa offre Arcane gratis che Portainer non offre?

Una cosa, principalmente: il controllo degli accessi basato sui ruoli completo. Portainer CE offre una gestione utenti di base; la gerarchia dei ruoli è della Business Edition. Arcane la fornisce gratis con qualsiasi numero di nodi, insieme alle scansioni Trivy, alla ridistribuzione GitOps, al supporto Swarm, all'accesso con passkey, agli agent remoti e ai backup S3 aggiunti nella v2.9.0.

Il RBAC è la parte da guardare da vicino, perché «ha il RBAC» copre cose molto diverse tra loro. La documentazione di Arcane sul controllo degli accessi descrive sei ruoli integrati immutabili: Admin, Editor, No-Shell Editor, Deployer, Monitor e Viewer. Puoi clonarne uno qualsiasi in un ruolo personalizzato e spuntare i singoli permessi, che seguono una <resource>:<action> forma come containers:start. Le assegnazioni sono globali o per ambiente, e un utente può averne più di una alla volta. La documentazione fa l'esempio direttamente: Editor su prod, Viewer su staging.

La parte che conta per un rollout SSO è che l'assegnazione dei ruoli può essere guidata dallo stesso identity provider: «A ogni accesso Arcane legge il claim di gruppo dell'utente e risincronizza le sue assegnazioni provenienti da OIDC», e un utente presente in più gruppi mappati ottiene l'unione di tutte. È il modello di permessi che Portainer CE non ha mai avuto.

La scansione delle vulnerabilità è il secondo pezzo. La documentazione di Arcane sulle scansioni afferma che «le scansioni sono opzionali, girano con una pianificazione cron e i risultati sono salvati per immagine», e i risultati vengono mostrati nell'interfaccia. Per impostazione predefinita girano ogni giorno a mezzanotte, trivyIgnoreUnfixed restringe i risultati alle vulnerabilità con una correzione nota, e Trivy è distribuito in un'immagine di strumenti con versione fissata, quindi gli aggiornamenti dello scanner non sono a carico tuo.

Ora il contrappeso, ed è grosso. La pagina di Portainer che confronta CE e BE dice che la Business Edition «è gratuita per sempre fino a 3 nodi. Nessun periodo di prova. Nessuna carta di credito. Nessuna limitazione di funzionalità». È il set completo della BE: RBAC con la sua gerarchia di ruoli, OIDC, log di audit con esportazione Syslog, GitOps avanzato. I termini di Take 3 rilasciano una licenza annuale rinnovata ogni anno senza costi finché resti a tre nodi o meno.

Quindi il conto del piano gratuito comincia a favorire Arcane solo dal quarto nodo. Sotto, il paywall non esiste. Arcane offre comunque qualcosa con uno o due nodi: nessuna chiave di licenza, nessun rinnovo da ricordare, un progetto che puoi forkare. Ma non è lo stesso argomento di «il RBAC costa».

Arcane è uno dei quattro strumenti che si contendono seriamente il posto di Portainer, e gli altri si dividono lungo linee diverse.

LEGGI

Alternative a Portainer: guida per casi d'uso a Dockge, Arcane, Dockhand e Komodo

Quanto è affidabile Arcane in questo momento?

Meglio di come sembrava alla v2.9.0, ma ancora giovane. Lo storico dei bug di Arcane si legge come quello di un progetto attivo che sistema le cose, e il grave bug GitOps di esaurimento del disco segnalato sulle v2.8.0 e v2.9.0 è stato corretto nella v2.10.0 il 31 agosto 2026.

Un operatore ha segnalato il 26 agosto 2026 che la sincronizzazione GitOps lascia in giro una directory di clonazione: "gitops-<N> le directory di clonazione si accumulano a un ritmo di circa 1.000 al giorno (~9 GB/giorno) e non vengono mai ripulite, fino a riempire il disco." Sei giorni così hanno prodotto circa 6.467 directory e 40 GB. Con il disco pieno, il manager non riusciva più a scrivere nel suo database SQLite ed è entrato in un ciclo di riavvii, arrivando a 389 riavvii e trascinando con sé le connessioni degli agent edge e le chiamate API. Il ticket è ora chiuso, e la v2.10.0 include la correzione che ripulisce le directory temporanee di clonazione Git residue.

Se sei ancora sulla v2.8.0 o v2.9.0: aggiorna prima di affidarti a una sincronizzazione GitOps frequente. La correzione della perdita di cloni arriva con la v2.10.0.

Lo storico più vecchio è più incoraggiante. Un blocco dopo l'aggiornamento tra la 2.0 e la 2.0.1 è stato risolto. Un bug per cui «Update Projects» toccava tutti i container dell'host invece di quelli del progetto selezionato è stato chiuso con la PR di correzione #2289 unita. Il polling delle immagini che non scattava silenziosamente nella v1.13.2 è stato corretto nella v1.14.0. Tre bug, tre correzioni.

Il numero grezzo di ticket aperti dice molto poco da solo su un progetto che rilascia a questo ritmo. I progetti contro cui nessuno apre ticket non sono per questo più affidabili.

La mia lettura resta che sia un problema di anzianità e non di capacità. Il rilascio veloce è il motivo per cui le lacune su RBAC e scansioni si sono chiuse, ed è anche il motivo per cui la v2.10.0 ha dovuto correggere un grave difetto GitOps meno di una settimana dopo la v2.9.0. Il rischio sta nel codice nuovo, e adottarlo è una scelta.

Quanto costa davvero passare da Portainer?

Una finestra di inattività e un po' di pulizia manuale, grosso modo. Arcane non ha ancora un'importazione diretta degli stack di Portainer, ma la v2.10.0 aggiunge un'azione sperimentale Convert to Compose per i container in esecuzione. Genera un file Compose mentre gli originali continuano a girare, il che elimina parte del lavoro di ricostruzione dello YAML. Devi comunque rivedere i bind mount, le reti, i valori d'ambiente e il passaggio stesso; nomi e porte pubblicate possono entrare in conflitto finché gli originali non vengono fermati, quindi non è un pulsante di migrazione senza interruzioni.

Prima della v2.10.0, la bacheca del progetto rifletteva un percorso completamente manuale. Un operatore con più di 80 container su cinque server ha chiesto se fosse possibile una migrazione a caldo senza prima spegnere i servizi esposti sul web. La risposta di chi l'aveva già fatto: «non avrai altra scelta che cancellare i container esistenti (e quindi gli stack di Portainer) e ricrearli da zero in Arcane». La sua sequenza: spegnere in modo pulito, fare il backup, cancellare, copiare i dati, ricreare e ridistribuire.

In pratica: backup dei volumi prima di toccare qualsiasi cosa, e una finestra di manutenzione dimensionata sia sul numero di stack che esegui sia sulla quantità di dati da spostare. Ricreare i container è di solito la parte veloce; copiare volumi grandi e riportare su i servizi dipendenti nell'ordine giusto può allungare la finestra. Una nota di terminologia mentre pianifichi: quello che Portainer chiama stack, Arcane lo chiama progetto.

Il costo in tempo si sente anche su scala homelab. Moises Aguirre, scrivendo il 28 febbraio 2026 a proposito dello spostamento di un homelab fuori da Portainer, lo ha definito «un bel weekend di lavoro (e di resa dei conti con i miei demoni)», e i demoni erano la sua stessa deriva: ha dovuto controllare ogni container che eseguiva e scrivere YAML per servizi che prima aveva «semplicemente creato a colpi di clic». È la sua esperienza, non una regola, ma lo schema si ripete.

Una cosa da cogliere prima di portare i file Compose dall'altra parte. Le note di rilascio della v2.7.0 hanno ristretto la risoluzione delle variabili a quattro fonti: le tue variabili globali in .env.global, il file .env del progetto, i valori predefiniti scritti nel file compose stesso, e fuso orario e locale dall'ambiente di Arcane. L'effetto dichiarato è che un progetto distribuito tramite Arcane risolve le sue variabili nello stesso modo in cui lo fa docker compose up nella directory del progetto. È un comportamento più corretto. Significa anche che qualsiasi cosa ereditasse silenziosamente un valore dall'ambiente del container del manager ora si risolverà in qualcos'altro, o in niente, e lo farà senza lamentarsi.

Niente di tutto questo è un difetto del prodotto. È un costo una tantum, abbastanza prevedibile da poterlo pianificare, che è la cosa principale che si chiede a una migrazione.

Costruisci su un VPS Linux con accesso root, NVMe e la potenza di AMD EPYC.

Vedi piani Linux

Cosa devi mettere in sicurezza prima della produzione?

Una chiave di cifratura, l'URL pubblico e TLS. Arcane crea un account admin predefinito al primo avvio e impone il cambio della password al primo accesso, un'impostazione predefinita sensata. Due impostazioni devono essere corrette prima della produzione. La prima è ENCRYPTION_KEY; la seconda è APP_URL.

Il riferimento delle variabili d'ambiente elenca ancora ENCRYPTION_KEY con un valore predefinito di arcane-dev-key-32-characters!!!, mentre la documentazione di installazione ti dice di fornire un valore univoco di 32 byte. Cambialo prima della produzione. Un'altra cosa è cambiata: la documentazione di installazione ora dice che JWT_SECRET non è più usato. Arcane genera da sé la chiave di firma delle sessioni; lasciare JWT_SECRET configurato produce solo un avviso all'avvio, quindi rimuovilo dall'ambiente. La documentazione di installazione specifica che ENCRYPTION_KEY «deve essere lungo 32 byte (grezzo, base64 o esadecimale)».

Anche l'igiene delle versioni fa parte di quella lista. Arcane ha pubblicato diversi avvisi di sicurezza nel 2026; un avviso di gravità alta, pubblicato il 29 luglio 2026, elenca come interessate le versioni precedenti alla v2.5.0 e riguarda un permesso delegato users:update che permetteva di reimpostare la password di un amministratore. Indica la v2.6.0 come versione corretta, quindi la v2.10.0 non è interessata, ma è un motivo concreto per non lasciare un deployment di produzione su un tag vecchio.

APP_URL ha come valore predefinito http://localhost:3552, e questo ha una conseguenza funzionale oltre all'igiene. L'accesso con passkey e l'MFA con passkey si basano entrambi su WebAuthn, e la documentazione di Arcane sulle passkey è esplicita: «I browser espongono l'API WebAuthn solo in un contesto sicuro, quindi le passkey richiedono HTTPS (oppure localhost)». L'ID del relying party è derivato da APP_URL, le passkey sono legate a quell'hostname, e se APP_URL non contiene un hostname il servizio passkey non si inizializza. Su HTTP semplice, Arcane nasconde del tutto i controlli delle passkey. Distribuisci su un IP nudo con una porta e la funzione di autenticazione di punta della v2 semplicemente non c'è. La documentazione lo dice chiaramente: «Imposta APP_URL sull'URL che i tuoi utenti aprono davvero, in HTTPS, prima che qualcuno registri una passkey».

Gli agent remoti decidono cosa devi aprire. La documentazione di Arcane sugli ambienti dice che in modalità diretta «il Manager si collega all'Agent sulla porta TCP 3553», quindi quella porta deve essere raggiungibile in ingresso sull'host remoto. In modalità edge «l'Agent si collega in uscita al Manager» e non ha bisogno di alcuna porta in ingresso.

Oltre a questo preferisco indicare piuttosto che fingere. Arcane pubblica una guida alla configurazione di un proxy per il socket la cui premessa è che montare il socket direttamente «dà ad Arcane accesso completo a Docker», e che un proxy lo restringe alle chiamate API necessarie. È la stessa esposizione che rende l'isolamento del socket Docker utile ovunque, e vale la pena farlo anche qui. Leggo questa documentazione come la legge chi fa il deployment, senza fare l'audit dello schema dei token.

Cosa non fa ancora Arcane?

Due lacune reggono ancora rispetto alla documentazione attuale di Arcane: niente LDAP e nessun browser generale per il filesystem di un container. Diverse altre lacune precedenti alla v2 si sono nel frattempo chiuse.

LDAP è assente. La documentazione di Arcane sul single sign-on copre OIDC e solo OIDC, e né quella né la pagina sul controllo degli accessi citano LDAP o Active Directory da nessuna parte. La Business Edition di Portainer, al contrario, si integra con «Active Directory, LDAP e identity provider compatibili OIDC». Se la tua organizzazione si autentica su una directory senza uno strato OIDC davanti, questo è un blocco totale, non qualcosa da aggirare.

Nessun browser di file generale dentro i container. La vista container di Arcane espone configurazione, mount, log e sorgente Compose, ma non un browser per il filesystem del container. Ora ha però un Volume Workspace che permette di esplorare e modificare i file dentro i volumi Docker, quindi la lacuna residua è più stretta della vecchia descrizione «nessun browser di file».

Vale la pena mettere queste correzioni nero su bianco, perché la descrizione di Arcane come «niente RBAC, niente scansione delle vulnerabilità» non regge più. Il RBAC è arrivato con la v2.0.0 il 7 giugno 2026, e la scansione Trivy è documentata e gira con una pianificazione. Anche la registrazione delle attività è cambiata: la documentazione di Arcane sulle attività descrive un Activity Center che copre pull, build, azioni del ciclo di vita, scansioni e pulizie, insieme a un registro eventi con gravità, tipo, timestamp e l'utente che ha avviato ogni azione, quando Arcane riesce ad attribuirla. Se esporti verso Syslog come fa il piano Business di Portainer è una cosa che la documentazione non chiarisce.

Quello che la velocità di rilascio non risolve è l'età. Il repository di Arcane è stato creato nell'aprile 2025. Portainer ha alle spalle anni di risposte accumulate su Stack Overflow, guide di terze parti e integrazioni, e quando alle 23 ti imbatti in qualcosa di strano è quella differenza che senti.

Chi dovrebbe passare ad Arcane, e chi no?

Passa ad Arcane se hai superato i tre nodi su Portainer e vuoi un accesso multiutente delimitato con file Compose versionati in git, senza discussioni sulle licenze. Resta dove sei se hai tre nodi o meno. Contare gli host risolve gran parte della questione più in fretta di qualsiasi elenco di funzionalità.

Tre profili per cui Arcane è un sì netto:

• Operatori oltre il limite dei tre nodi di Portainer che hanno bisogno di accessi delimitati. Oltre i tre nodi quelle capacità hanno un prezzo su Portainer e nessuno su Arcane, e i ruoli sono abbastanza granulari da dare a qualcuno Deployer su un ambiente e Viewer su tutti gli altri.
• Operatori che vogliono i file Compose come fonte di verità. Se ciò che spinge al cambio è che le definizioni degli stack vivono in un database invece che in un repository, è una corrispondenza strutturale, non una preferenza. Il weekend di migrazione se ne va soprattutto a mettere per iscritto quello che già esegui, un lavoro che dovevi comunque.
• Operatori che consolidano più host, compresi quelli dietro NAT. Gli agent in modalità edge non hanno bisogno di porte in ingresso sul lato remoto, i cluster Swarm si gestiscono dal nodo manager, e gli ambienti remoti non costano nulla.

Due profili per cui non lo è:

• Chiunque abbia tre nodi o meno. La Business Edition è gratuita a quella dimensione con il set completo di funzionalità, quindi cambiare spende una finestra di inattività e un weekend per ottenere capacità che hai già. Come alternativa a Portainer Arcane è capace; questo non è comunque un motivo per spostarsi.
• Chiunque abbia bisogno di LDAP, o non possa fermare gli stack. L'autenticazione tramite directory non è disponibile e la migrazione richiede ancora un passaggio pianificato. Nessuno dei due ha una scappatoia ingegnosa.

Una condizione accompagna questo verdetto. Se la ridistribuzione GitOps è proprio il motivo per cui stai migrando, usa la v2.10.0 o successiva. Il bug di esaurimento del disco segnalato sulle v2.8.0 e v2.9.0 lì è corretto.

LEGGI

Come ottenere Docker su VPS: una guida completa per usare un VPS per la containerizzazione🗂️

Domande frequenti