Portainer cambia rotta: è già il momento di cercare un’alternativa per gestire i propri container Docker?

Portainer è ormai quasi un elemento fisso in molti home lab. Lo si installa su un NAS, un Raspberry Pi, un mini PC o in una VM Proxmox e, cinque minuti dopo, si ha un’interfaccia Web per avviare, arrestare, aggiornare e monitorare i propri container Docker.

Nella domotica è molto pratico. Home Assistant funziona benissimo in un container e spesso, insieme a lui, troviamo Mosquitto, Zigbee2MQTT, Node-RED, ESPHome, Frigate, InfluxDB, Grafana, AdGuard Home, Nginx Proxy Manager… La lista si allunga in fretta.

L’11 settembre 2026, Portainer ha annunciato un cambio di rotta: la versione 3.0 sarà pensata innanzitutto per Kubernetes, mentre la Community Edition resterà sul ramo 2.x.

Bisogna disinstallare Portainer domani mattina? No. Ma è il momento giusto per andare a vedere cosa cresce nel giardino del vicino.

Portainer 3.0: rotta verso Kubernetes

È stato Neil Cresswell, CEO di Portainer, a illustrare la nuova strategia in un post sul blog. E non si tratta di un semplice cambio del numero di versione.

Portainer 2.45 LTS, uscita ad agosto, è l’ultima versione del ramo 2.x. La 3.x verrà sviluppata dando priorità a Kubernetes.

L’azienda lo spiega con una certa franchezza. Il divario tra Docker e Kubernetes è cresciuto così tanto che non è più sostenibile sviluppare tutto in parallelo per Docker, Podman, Swarm e Kubernetes all’interno della stessa base di codice. I clienti enterprise chiedono policy di sicurezza, osservabilità, GitOps e strumenti per eseguire workload di IA… Tutto questo si basa su meccanismi specifici di Kubernetes (network policy, admission controller) che Docker non ha.

Attorno a questo ecosistema sono in preparazione diversi prodotti: Portainer-Run, Portainer-IDP, Portainer-Command, Portainer-Operations e Portainer-AiGrid. Già solo i nomi danno un’idea della direzione.

Quando si vuole semplicemente far funzionare Zigbee2MQTT e una manciata di servizi su un mini PC, si è piuttosto lontani dalle esigenze iniziali.

Portainer CE non è morto, però

Alcuni titoli pubblicati dopo l’annuncio erano decisamente allarmistici, quindi facciamo chiarezza: Portainer non abbandona Docker e non stacca la spina alla Community Edition da un giorno all’altro.

La CE resta sul ramo 2.x e continuerà a ricevere patch di sicurezza e correzioni di bug. Portainer promette inoltre di retroportare le novità della 3.x che hanno un equivalente nell’API Docker. La 2.45 LTS sarà supportata fino a maggio 2027.

Se oggi il vostro server funziona bene con Portainer CE, non c’è fretta.

Non ci sarà, però, una Portainer CE 3.0. Per usufruire gratuitamente della 3.x, bisognerà aderire al programma «3 Nodes Free», ovvero l’edizione Business gratuita fino a tre nodi. Gli ambienti Docker, Swarm e Podman continueranno a essere gestiti, ma passeranno in secondo piano nell’interfaccia, e le nuove funzionalità arriveranno prima, se non esclusivamente, sul versante Kubernetes.

Oggi la differenza sembra poca. Tra due o tre anni, secondo me, si noterà molto di più.

Perché riguarda la domotica

Per un home lab, Kubernetes è spesso eccessivo.

Prendiamo un server classico con Home Assistant, Mosquitto, Zigbee2MQTT, Node-RED, Frigate e due o tre strumenti di monitoraggio. Docker Compose fa il suo lavoro: un file per ogni applicazione, i dati nei volumi e qualche comando per fare un backup completo o ricostruire tutto.

Mettere in piedi un cluster Kubernetes solo per mantenere le ultime funzionalità di un’interfaccia di amministrazione è un po’ come usare una ruspa per piantare tre tulipani.

Del resto, Portainer lo riconosce: Docker continuerà a essere supportato nella 3.x, ma lo sviluppo si concentrerà su Kubernetes. Se non avete intenzione di passare a Kubernetes, viene spontaneo chiedersi: esistono interfacce pensate innanzitutto per Docker e Docker Compose?

Sì. E negli ultimi mesi diverse hanno fatto grandi progressi.

Arcane: probabilmente oggi il sostituto più convincente

Se nel 2026 dovessi provarne uno solo, sceglierei questo.

Arcane somiglia a quello che ci si aspetterebbe da un Portainer moderno: container, immagini, volumi, reti e progetti Docker Compose in un’interfaccia Web, oltre alla gestione di macchine remote grazie a un agent.

Per l’autenticazione offre OIDC, passkey e autenticazione a due fattori. Ci sono anche un’API, la gestione degli aggiornamenti delle immagini e uno scanner di vulnerabilità che mostra i rischi associati a ciascuna immagine.

E lo sviluppo procede in fretta. Le versioni dalla 2.10 alla 2.14 sono uscite in meno di un mese. La 2.14.0 è del 26 settembre 2026, pochi giorni prima che scrivessi queste righe. Aggiunge azioni in blocco sulle vulnerabilità, una vista dei rischi per la sicurezza rinnovata e una scheda che mostra i processi di ciascun container.

L’installazione è semplice: Arcane gira a sua volta in un container e accede al socket Docker dell’host. Come con Portainer, tenete presente che l’accesso al socket equivale a concedere i diritti di root sulla macchina. Meglio quindi evitare di esporre l’interfaccia su Internet senza le dovute precauzioni.

Se domani dovessi sostituire Portainer nel mio home lab, sarebbe il primo che installerei.

Dockge: la semplicità prima di tutto

Dockge è l’altro nome che ricorre continuamente nelle discussioni.

È opera di Louis Lam, lo sviluppatore di Uptime Kuma, e ha una filosofia diversa. Non cerca di rifare tutto Portainer: si concentra su Docker Compose. Dalla sua interfaccia essenziale si possono creare, modificare, avviare, arrestare e aggiornare gli stack.

La cosa che apprezzo di più è che i file compose.yaml restano veri file sul disco (in /opt/stacks per impostazione predefinita), anziché essere voci in un database interno. Si possono aprire con qualsiasi editor o avviare un bel vecchio docker compose up -d dal terminale.

Dalla versione 1.4, può anche connettersi ad altre istanze di Dockge per mostrare gli stack di più macchine nella stessa interfaccia.

Su un Raspberry Pi o un mini PC che esegue una decina di servizi domotici, è davvero piacevole da usare.

Il punto debole è il ritmo di sviluppo. L’ultima versione stabile, la 1.5.0, risale a marzo 2025. Questo non gli impedisce di funzionare, ma se dovessi fare una nuova installazione destinata a durare diversi anni, esiterei a sceglierlo come prima opzione.

Komodo: quando l’home lab include diversi server

Se il vostro home lab è cresciuto parecchio, Komodo merita un’occhiata.

È progettato per distribuire e gestire più server. È un progetto open source con licenza GPLv3, senza limiti sul numero di macchine connesse.

Gestisce Docker Compose, sa importare stack esistenti e recuperare le configurazioni da un repository Git. Potete quindi descrivere uno stack in Git, distribuirlo automaticamente su un server e ridistribuirlo a ogni modifica del repository. E se preferite tenere i file Compose direttamente sulla macchina, alla vecchia maniera, potete farlo.

Komodo 2 ha aggiunto la gestione di Docker Swarm, l’autenticazione a due fattori (TOTP o passkey) per gli account locali, la possibilità di associare più metodi di accesso (locale, OIDC, GitHub…) allo stesso account e terminali remoti rinnovati. Quanto all’automazione, era già ben attrezzato.

Un esempio concreto: un mini PC per la domotica, un secondo server per Frigate e le telecamere, un NAS con alcuni servizi e un VPS all’esterno. Komodo centralizza tutto.

È ovviamente più impegnativo da imparare rispetto a Dockge. Ma è anche molto più potente.

Dockhand: la novità da tenere d’occhio

Ultimo della lista: Dockhand. La sua prima versione risale a dicembre 2025 e il suo sviluppo procede a una velocità impressionante.

Gestisce container, stack Compose, diversi ambienti Docker, repository Git e webhook. Si possono anche esplorare i volumi e i file all’interno dei container, visualizzare le connessioni di rete o pianificare operazioni di manutenzione.

Si distingue soprattutto per la sicurezza, con funzionalità che si vedono raramente in uno strumento self-hosted. Analizza le immagini con Grype e Trivy per individuare le vulnerabilità note e può eseguire la scansione di una nuova immagine prima di sostituire un container in esecuzione. È utile per evitare che un aggiornamento automatico installi nel cuore della notte un’immagine piena di vulnerabilità note.

La versione 1.0.50 è uscita il 30 settembre 2026.

Attenzione, però, alla licenza. Dockhand è distribuito con la Business Source License 1.1: è gratuito per uso personale o interno all’azienda, ma non è software libero nel senso di un progetto GPL o MIT. Non lo si può, per esempio, rivendere come servizio ospitato. Nel 2029 il codice passerà alla licenza Apache 2.0.

Allora, bisogna lasciare Portainer?

Non necessariamente.

Se avete Portainer CE 2.45 su un server Docker di casa e tutto funziona, non vedo alcun motivo per stravolgere tutto. Il ramo è supportato e continueranno ad arrivare correzioni.

Ma l’annuncio ha cambiato il mio modo di considerare lo strumento nel lungo periodo. Portainer ha scelto la sua strada: Kubernetes e il mondo enterprise. Dal punto di vista dell’azienda lo capisco benissimo. Semplicemente, non è la strada di chi ha un mini PC e una ventina di container nel ripostiglio tecnico.

Per chi ha questo profilo, ecco la mia opinione:

• Arcane è oggi ciò che più si avvicina a un Portainer moderno e sviluppato attivamente;
• Dockge resta eccellente se volete un’interfaccia minimalista per Docker Compose e non vi disturba il rallentamento dello sviluppo;
• Komodo diventa davvero interessante non appena si gestiscono più server o si vuole passare al GitOps;
• Dockhand è molto completo, soprattutto sul fronte della sicurezza, e vale la pena seguirne gli sviluppi, se la licenza fa al caso vostro.

La scelta più prudente è non migrare subito. Installate uno di questi strumenti accanto a Portainer e provatelo per qualche settimana. Parlano tutti con lo stesso demone Docker e convivono senza problemi; anche le FAQ di Dockge lo affermano chiaramente. Unica cosa a cui fare attenzione: gli stack creati dall’editor Web di Portainer vengono archiviati nel suo volume di dati, non in una cartella sotto il vostro controllo. Recuperate i relativi file Compose prima di passare a un altro strumento.

È quello che farei al vostro posto.

Per anni, alla domanda «quale interfaccia usare per gestire Docker?» si rispondeva quasi automaticamente: Portainer. Nel 2026, finalmente, abbiamo una vera scelta e, per chi si diletta con il proprio home lab, è una bella notizia.

E voi, cosa ne pensate?