Come Eseguire Docker e Portainer su un VPS (Guida 2026)

Hai mai sentito parlare di Dockerception?

Beh, tieniti forte al cappello. Stiamo per addentrarci nella tana del Bianconiglio.

Portainer, l’interfaccia web che stai per installare su Docker, è a sua volta un container Docker.

È uno strumento che funziona sulla stessa cosa che gestisce. Lo avvii con una riga di docker run, e la prima cosa che fa è tornare indietro attraverso un piccolo buco nell’host (un file socket) e chiedere al demone Docker di mostrargli ogni container presente sulla macchina, incluso se stesso. Da quella scheda del browser gestisci tutti gli altri tuoi container Docker.

L’interfaccia che stai guardando compare nel suo stesso elenco di container.

Su un VPS dove già paghi per la box e sei già a tuo agio con SSH, Portainer si inserisce perfettamente sopra Docker senza modificare il funzionamento di ciò che c’è sotto.

Quello è il valore.

Una box da 4 GB può essere un punto di partenza per Docker e Portainer, ma sono le applicazioni che aggiungi a determinare se quella capacità basta. Pensa all’automazione domestica, all’archivio fotografico di famiglia, all’assistente IA e alla newsletter che minacci di lanciare da tempo, su un server di tua proprietà.

Ecco come farlo funzionare, proteggerlo e iniziare a vederne il valore.

Cos’è Esattamente Portainer?

Portainer è una UI web che funziona come un container Docker e gestisce gli altri tuoi container tramite il socket Docker.

È essenzialmente un frontend basato su browser (una GUI per Docker) per gli stessi comandi Docker che altrimenti digiteresti a mano, oltre alla gestione degli stack, all’accesso basato sui ruoli (se passi a Business Edition) e a una vista dashboard di CPU e memoria.

La connessione al socket è ciò che lo fa funzionare. Il bind appare come -v /var/run/docker.sock:/var/run/docker.sock nel comando di installazione, e quella singola riga fa tutto il lavoro pesante. Senza di essa, Portainer è una UI per un host Docker vuoto. Con essa, Portainer è il telecomando dell’host Docker.

Una cosa da tenere a mente: qualsiasi processo che può raggiungere /var/run/docker.sock può controllare il demone Docker, e la documentazione sulla sicurezza di Docker è chiara: solo gli utenti fidati dovrebbero poterlo fare, perché un container avviato tramite il demone può montare l’intero filesystem dell’host e modificarlo senza restrizioni. Questa è una funzionalità quando è Portainer a chiederlo e un problema quando è un container che hai avviato la settimana scorsa dimenticando di avergli dato accesso al socket.

Tratta il bind del socket come una capacità privilegiata, e verifica ogni altro container che ne richiede uno.

Hai Bisogno Di Portainer Se Hai Già Docker?

No. Docker funziona bene dal terminale, e molte persone gestiscono un paio di container per anni senza mai installare un’interfaccia utente sopra.

Vuoi Portainer se:

• Gestirai più di due o tre container Docker in diverse app.
• Preferisci cliccare su “riavvia” piuttosto che riscrivere un comando Compose alle 11 di sera. 
• Stai condividendo l’accesso con qualcuno che non vive in un terminale. 
• Vuoi distribuire aggiornamenti di stack da un repo Git senza scrivere uno script di deploy. 

Salta Portainer se:

• Gestisci uno o due container che cambiano raramente. 
• Sei già a tuo agio con Docker Compose e sei felice di continuare a usarlo.

Docker è ormai così diffuso che questa non è una decisione di nicchia. Nello Stack Overflow Developer Survey 2025, il 71% degli intervistati ha dichiarato di usare Docker, il risultato più alto tra le tecnologie di sviluppo cloud e di infrastruttura, dopo un balzo di 17 punti percentuali rispetto al 2024. Il progetto Portainer ha più di 38.000 stelle su GitHub ad agosto 2026.

Esistono altre opzioni. Dokploy, per esempio, tende di più verso una PaaS self-hosted completa, gestendo per te app, database e SSL. Portainer resta più vicino al Docker puro: stessi file Compose, stesse immagini, solo con un’interfaccia sopra.

Se vivi in tmux e gestisci una sola app, chiudi questa scheda. Va tutto bene. Se gestisci quattro app auto-ospitate e hai cercato su Google “Com’è che si vedono i log di Docker?” due volte questo mese, continua a leggere.

Quanto Grande Deve Essere Un VPS Per Eseguire Docker e Portainer?

Portainer non indica un minimo di RAM. Un VPS da 4 GB può andare bene per un piccolo stack, ma dimensionalo in base ai requisiti combinati del sistema operativo, del demone Docker e di ogni container che prevedi di eseguire.

La pagina dei requisiti di Portainer dice sorprendentemente poco sulla RAM: il Server è distribuito come container leggero e le indicazioni sulle prestazioni riportate nella documentazione riguardano lo storage (ne parliamo più sotto). Il vero calcolo della RAM sono i tuoi carichi di lavoro: metti in conto il sistema operativo, il demone Docker e ogni container che prevedi di eseguire. Metti in conto anche il disco per i log: il driver di log json-file predefinito di Docker non effettua alcuna rotazione dei log, quindi i log di un container chiacchierone possono occupare una quantità significativa di disco nel tempo. La documentazione sul logging di Docker consiglia invece il driver local. Una volta installato Docker (passaggio 2 più sotto), crea la directory di configurazione di Docker e imposta il driver di log local, poi riavvia Docker: esegui sudo install -d -m 0755 /etc/docker, poi printf '%s\n' '{ "log-driver": "local" }' | sudo tee /etc/docker/daemon.json > /dev/null, poi sudo systemctl restart docker. Fallo prima di distribuire app che restano in esecuzione a lungo: il driver local ruota i log per impostazione predefinita, e la modifica si applica solo ai container creati dopo.

Ecco come si applica a carichi di lavoro reali:

Il foglio di calcolo è una semplice addizione: cerca il requisito di RAM documentato per ogni app che prevedi di eseguire, aggiungi il sistema operativo e il demone Docker, poi lascia un margine per i picchi di utilizzo. Portainer stesso non indica un minimo di RAM, quindi sono le app, non l’interfaccia, a riempire la box.

Da DreamHost, il nostro VPS Hosting è disponibile in quattro piani Stack basati sulla RAM (Stack 4, 8, 16 e 32). Il piano base Stack 4 (2 vCPU, 4 GB di RAM, 75 GB di SSD NVMe, accesso root completo) è la scelta naturale per un piccolo host Docker. Con la fatturazione mensile costa $8,99/mese per i primi 3 mesi e si rinnova automaticamente a $15,99/mese in seguito (ad agosto 2026; l’intero periodo più le tasse viene addebitato al checkout; i prezzi aggiornati sono sempre sulla pagina VPS Docker + Portainer).

Se sei indeciso se il self-hosting valga il tempo, Stack 4 è la dimensione da cui partire: abbastanza grande per scoprirlo, abbastanza piccola da non pagare un margine che non userai. Se il tuo foglio di calcolo lo supera, puoi passare a un piano superiore e il tuo ambiente si sposta con te, ma tieni presente che al momento non è possibile tornare a uno Stack più piccolo, quindi inizia in piccolo di proposito.

Una nota sullo storage: il volume dati di Portainer contiene il suo database e la sua configurazione, più un clone di qualsiasi repository Git da cui distribuisci stack; la documentazione di Portainer avverte che repository grandi o multipli possono occupare molto spazio su disco. Le indicazioni sulle prestazioni della documentazione riguardano lo storage, non la memoria: prestazioni a livello di SSD (≈3,5 MB/s, 30.000 IOPS o più, latenza di scrittura inferiore a 10 ms) sono ciò che definisce ideale. Stack 4 include 75 GB di storage SSD NVMe.

Come Installare Docker e Portainer su un VPS?

Servono sette passaggi. I tempi di download e installazione dipendono dal tuo VPS e dalla connessione di rete. I comandi dei passaggi da 2 a 6 sono scritti per Ubuntu e possono essere incollati in ordine su un server pulito; l’unico punto in cui un comando richiede un valore che conosci solo tu (il tuo indirizzo IP, nel passaggio 4) è segnalato nel passaggio stesso. (Vuoi saltare tutto l’elenco? La libreria di app di DreamHost VPS Hosting include un’immagine Docker + Portainer con entrambi preconfigurati.)

1. Scegli una distribuzione Linux

Questa guida usa Ubuntu 24.04 LTS. Docker Engine supporta Ubuntu 22.04, 24.04 e 26.04 LTS (ad agosto 2026). Ubuntu è uno dei sistemi operativi preinstallati disponibili su DreamHost VPS Hosting.

Anche Debian e le distribuzioni della famiglia RHEL come AlmaLinux funzionano, ma hanno le proprie procedure di installazione nella documentazione di Docker, e i comandi qui sotto non si applicano così come sono. Un’ulteriore complicazione per la famiglia RHEL: la documentazione di installazione di Portainer presuppone che SELinux sia disabilitato, e indica di passare --privileged a Docker quando distribuisci Portainer se ti serve SELinux attivo. Se questa frase non ti ha detto nulla, usa Ubuntu.

Non sei sicuro di quale versione di Ubuntu stai utilizzando? Scopri cinque modi per verificarlo.

2. Installa Docker dal repository ufficiale

Non eseguire apt install docker.io, e non installare Docker nemmeno tramite snap: la documentazione ufficiale di installazione di Docker elenca docker.io tra i pacchetti non ufficiali da disinstallare prima di installare Docker Engine, e la documentazione di installazione di Portainer avverte che il pacchetto snap può causare problemi di compatibilità.

Per prima cosa, elimina eventuali pacchetti in conflitto. Questo è il comando di rimozione dell’attuale documentazione di installazione di Docker, e su un server pulito di solito non trova nulla da rimuovere: la documentazione segnala che apt potrebbe indicare che nessuno di questi pacchetti è installato:

sudo apt remove $(dpkg --get-selections docker.io docker-compose docker-compose-v2 docker-doc docker-buildx podman-docker containerd runc | cut -f1)

Poi aggiungi la chiave GPG di Docker (ogni riga qui sotto è un comando a sé):

sudo apt update
sudo apt install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

Quindi aggiungi il repository apt di Docker. Questo scrive la definizione del repository in /etc/apt/sources.list.d/docker.sources, il file usato dalla documentazione di installazione di Docker, con la tua versione di Ubuntu e l’architettura della CPU compilate automaticamente:

sudo tee /etc/apt/sources.list.d/docker.sources > /dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF
sudo apt update

Infine, installa Docker Engine e il plugin Compose in un colpo solo:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

3. Verifica che Docker sia in esecuzione

Esegui sudo docker run hello-world.

Se non ricevi il messaggio “Hello from Docker!”, correggi il demone prima di sovrapporre Portainer.

4. Integra UFW con Docker prima di avviare Portainer

Ecco la parte che la maggior parte delle guide mette alla fine, quando ormai è troppo tardi: quando Docker pubblica una porta, il traffico verso di essa viene deviato prima di raggiungere le catene filtrate da UFW, quindi una porta pubblicata è raggiungibile da internet pubblico anche quando UFW dice che è negata. (La spiegazione completa è più sotto.) Nel momento in cui avvii Portainer, la sua porta 9443 sarà pubblica, proprio durante la finestra di cinque minuti in cui chiunque la raggiunga per primo può creare l’account amministratore. Quindi sistema il firewall prima.

Se UFW non è già attivo, consenti SSH e abilitalo. (Se il tuo SSH usa una porta personalizzata, consenti quella porta invece della 22, altrimenti questo è il passaggio in cui ti chiudi fuori.)

sudo ufw allow 22/tcp
sudo ufw enable

Poi installa chaifeng/ufw-docker, uno strumento di terze parti che aggiunge le regole necessarie a /etc/ufw/after.rules in modo che il traffico verso le porte pubblicate da Docker venga filtrato tramite la catena DOCKER-USER. I comandi qui sotto fissano la release 251123 del progetto (novembre 2025) invece di scaricare dal branch master in continua evoluzione, e usano curl, che hai installato nel passaggio 2:

sudo curl -fsSL -o /usr/local/bin/ufw-docker \
  https://github.com/chaifeng/ufw-docker/raw/251123/ufw-docker
sudo chmod +x /usr/local/bin/ufw-docker
sudo ufw-docker install
sudo ufw reload

Dopo il ricaricamento, le porte pubblicate dei container vengono filtrate tramite UFW. Se la tua policy per il traffico instradato nega le connessioni in entrata e nessuna regola esistente consente la porta, le connessioni pubbliche restano bloccate finché non le consenti esplicitamente. (Il progetto ufw-docker segnala che, se le regole non hanno effetto dopo un riavvio di UFW, un riavvio del server risolve il problema.)

Ora pre-autorizza il tuo accesso all’interfaccia di Portainer. Sostituisci YOUR_HOME_IP con l’IP pubblico da cui navigherai:

sudo ufw route allow proto tcp from YOUR_HOME_IP to any port 9443

Con questa regola attiva prima dell’avvio di Portainer, il traffico IPv4 verso l’interfaccia è consentito dal tuo IP e da nessun altro, anche durante la finestra di creazione dell’amministratore iniziale. La regola così come è scritta copre solo IPv4. La documentazione di ufw-docker dice che lo strumento supporta anche le reti IPv6 e aggiorna /etc/ufw/after6.rules quando necessario, ma non fidarti sulla parola: se il tuo VPS risponde su un indirizzo IPv6 pubblico, esegui anche via IPv6 il test dall’esterno descritto nella sezione sul firewall prima di fidarti. Il compromesso: la maggior parte delle connessioni domestiche cambia IP di tanto in tanto, quindi potresti dover aggiornare la regola in seguito. Se la cosa ti dà fastidio, la soluzione più pulita a lungo termine è una VPN davanti all’interfaccia (trattata nella sezione sulla messa in sicurezza).

5. Crea un volume persistente per i dati di Portainer

In seguito, esegui sudo docker volume create portainer_data.

Mantenere il database di Portainer su un volume Docker (non all’interno del container) significa che un aggiornamento di Portainer non cancellerà la tua configurazione.

6. Esegui Portainer Community Edition

Questo è il comando della documentazione di installazione di Portainer per Linux, meno un flag: la versione ufficiale pubblica anche la porta 8000, un tunnel TCP necessario solo se in seguito colleghi ambienti remoti tramite Edge Agent. Un’installazione su un singolo host non ne ha bisogno, quindi la omettiamo:

sudo docker run -d \
  -p 9443:9443 \
  --name portainer \
  --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:lts

Analizziamolo riga per riga:

• -d lo esegue in modalità distaccata.
• -p 9443:9443 è l’interfaccia web di Portainer su HTTPS, la porta che hai autorizzato per il tuo IP nel passaggio 4.
• --restart=always fa ripartire Portainer dopo un riavvio.
• -v: questi flag sono il bind del socket e il volume persistente del passaggio 5.
• :lts ti vincola al canale di rilascio Long Term Support di Portainer, il tag usato dalla documentazione di installazione di Portainer.

7. Apri l’interfaccia e crea il tuo account amministratore

Indirizza il tuo browser su https://YOUR_VPS_IP:9443 (dall’indirizzo IP che hai autorizzato nel passaggio 4).

Ignora l’avviso del certificato autofirmato. Arriverai alla schermata “crea l’utente amministratore iniziale”. Scegli un nome utente che non sia admin, imposta una password forte e salvala in un posto sicuro. E… sei dentro!

Perché Portainer È Appena Andato In Timeout?

Perché Portainer attende esattamente cinque minuti affinché qualcuno lo rivendichi alla prima installazione. Se nessuno lo fa, chiude la porta.

Testo esatto dalla FAQ di Portainer:

“Come misura di sicurezza, quando Portainer viene installato per la prima volta, attenderà 5 minuti per la creazione di un utente amministratore (parte della configurazione iniziale). Se un utente non viene creato entro quei 5 minuti, il Server Portainer smetterà di ascoltare le richieste.“

Traduzione: se hai impiegato il passaggio 6 a prepararti un panino, ora la tua installazione si rifiuta di parlarti, e non hai fatto nulla di sbagliato.

La soluzione è semplice. Esegui sudo docker restart portainer.

Questo fa ripartire il container, ti dà un’altra finestra di cinque minuti e ti porta alla schermata di creazione dell’amministratore. Ripeti quanto necessario. Benvenuto nel self-hosting.

Se stai scriptando l’installazione per una flotta (Ansible, Terraform, una pipeline di deploy), Portainer accetta un flag --admin-password-file che crea l’utente admin da un file al primo avvio del container, così non c’è nessuna schermata di creazione dell’amministratore contro cui correre. La documentazione sulla configurazione CLI di Portainer copre la sintassi. Per un’installazione VPS una tantum, il trucco del riavvio va bene.

Come Impedire a Docker Di Bypassare Il Tuo Firewall?

L’hai già fatto, nel passaggio 4. Ecco cosa è successo davvero, come aprire le porte di proposito e come dimostrare che ha funzionato.

Il problema: quando pubblichi la porta di un container con -p 80:80, quella porta è raggiungibile da internet pubblico anche se ufw status indica che la porta 80 è negata. Secondo la documentazione sul filtraggio dei pacchetti di Docker, “Docker instrada il traffico dei container nella tabella nat, il che significa che i pacchetti vengono deviati prima di raggiungere le catene INPUT e OUTPUT utilizzate da ufw.”

UFW non è rotto. È solo nel corridoio sbagliato.

La soluzione indicata da Docker stesso è la catena iptables DOCKER-USER, una catena che Docker crea appositamente per le regole definite dall’utente, elaborata prima delle regole delle catene di Docker. Lo script ufw-docker che hai installato nel passaggio 4 integra UFW in quella catena aggiungendo un blocco di regole (tra i marcatori # BEGIN UFW AND DOCKER e # END UFW AND DOCKER) a /etc/ufw/after.rules, così viene caricato insieme al resto della tua configurazione UFW.

Per aprire di proposito al pubblico la porta di un container, per esempio un’app web sulla porta 80 del container, usa una regola route:

sudo ufw route allow proto tcp from any to any port 80

Una trappola segnalata dalla documentazione di ufw-docker: la regola prende la porta del container, non quella dell’host. Se hai pubblicato con -p 8080:80, la regola corretta è quella qui sopra (porta 80), non la porta 8080.

Per verificare dall’esterno, fai un test da una rete che non è nella tua lista di autorizzazione; un hotspot del telefono va benissimo. Questo comando dovrebbe andare in timeout invece di restituire la pagina di login di Portainer:

curl -k --max-time 5 https://YOUR_VPS_IP:9443

# For IPv6, enclose the address in square brackets:
curl -k --max-time 5 'https://[YOUR_VPS_IPV6]:9443'

Esegui lo stesso comando dall’IP che hai autorizzato nel passaggio 4 e dovresti ricevere dell’HTML. UFW che dice “denied” è un’affermazione; un timeout da una rete estranea è una prova.

Per annullare tutto, esegui sudo ufw-docker uninstall, che secondo la documentazione del progetto ripristina la tua configurazione UFW ed elimina i file che ha installato, poi sudo ufw reload. Puoi anche rimuovere a mano il blocco tra i marcatori # BEGIN UFW AND DOCKER e # END UFW AND DOCKER in /etc/ufw/after.rules e ricaricare UFW.

Questa coglie in fallo ingegneri esperti tanto sulle macchine personali quanto sui server di produzione: UFW dice una cosa, internet pubblico un’altra, e la verità è in iptables. Se preferisci che Portainer non abbia mai una porta pubblica, proteggilo con un tunnel VPN come WireGuard.

Cosa Dovresti Mettere In Sicurezza Subito Dopo Il Primo Accesso?

Sei dentro. Cinque cose da fare prima di chiudere quella scheda del browser; le prime quattro vengono direttamente dalla guida alla sicurezza di Portainer:

• Attiva Force HTTPS only. L’installazione di questa guida pubblica solo la porta 9443, quindi nessuna porta HTTP è esposta fin dall’inizio. Attivare l’opzione Force HTTPS only in Settings → SSL Certificate rende definitiva questa scelta: secondo la documentazione sulle impostazioni di Portainer, disabilita completamente l’ascolto sulla vecchia porta HTTP (9000), quindi una futura ridistribuzione che aggiunga -p 9000:9000 non può riaprire un percorso non cifrato.
• Sostituisci il certificato autofirmato. Carica un certificato che hai generato, oppure metti davanti a Portainer un reverse proxy NGINX con un certificato Let’s Encrypt. Dopo il primo giorno, cliccare ogni volta sull’avviso del browser diventerà un’abitudine di cui ti pentirai.
• Utilizza un vero nome utente amministratore. Usare il nome utente admin predefinito lascia a un attaccante una credenziale in meno da indovinare. Scegli qualcosa di specifico per te.
• Limita l’UI a una VPN. Eseguire Portainer dietro una VPN WireGuard è il modello indicato dalla guida alla sicurezza di Portainer. Una 9443 limitata al tuo IP di origine (passaggio 4) va bene. Una 9443 raggiungibile solo su una rete privata è meglio.
• Verifica il bind del socket Docker. Qualsiasi cosa con accesso a /var/run/docker.sock controlla il demone Docker e, attraverso di esso, l’host. Non montare con leggerezza il socket in altri container. Ogni bind aggiuntivo è un nuovo percorso verso l’host. Se un container afferma di aver bisogno del socket, chiedi perché, e valuta un proxy del socket se la risposta è “per il monitoraggio”.

Come Utilizzi Effettivamente Portainer Nella Vita Quotidiana?

Il vantaggio dell’installazione di Portainer è il giorno in cui smetti di usare SSH per riavviare un container che non funziona bene, e inizi a cliccare su un pulsante. Il vantaggio maggiore è la gestione degli stack.

Uno stack di Portainer è un’app multi-container definita da un file Docker Compose. Portainer può distribuire le configurazioni Docker Compose supportate come stack attraverso quattro percorsi elencati nella documentazione ufficiale degli stack:

• Incolla il Compose nell’editor web
• Carica un file Compose
• Indirizza Portainer a un repository Git
• Distribuisci da un template personalizzato

Il percorso Git è quello che conta. Indirizzi Portainer a un repository pubblico o autenticato e a un percorso per docker-compose.yml, poi attivi gli aggiornamenti GitOps. Portainer controlla il repository a un intervallo di fetch che imposti tu, oppure ti fornisce un URL webhook da aggiungere al tuo host Git (attivato, per esempio, da una GitHub Action). Quando il file Compose cambia a monte, Portainer lo scarica e lo ridistribuisce automaticamente. E sì, funziona in Community Edition: nella pagina della documentazione sugli stack, solo l’opzione dei volumi con percorso relativo riporta il contrassegno Business Edition.

Questa è la versione self-hosted del “deploy on push” senza pagare una PaaS per il privilegio.

Anche le piccole vittorie quotidiane si accumulano. Pensa ai log in un pannello invece di seguirli dalla riga di comando, ai riavvii con un solo clic, alla ricostruzione di uno stack da un pulsante e ai grafici delle risorse che puoi scorrere in tre secondi invece di eseguire Docker stats.

Se in seguito aggiungi host remoti tramite Edge Agent, la porta 8000 torna in gioco: le FAQ più sotto trattano la ridistribuzione e la regola del firewall.

Come Eseguire Il Backup Di Portainer e Dei Tuoi Container?

Un volume è persistenza, non un backup. Il volume portainer_data del passaggio 5 sopravvive agli aggiornamenti del container, ma risiede sullo stesso disco di tutto il resto: un vero piano di backup ha quindi tre parti, e tutte e tre lasciano il VPS.

1. La configurazione di Portainer. Nell’interfaccia, vai su Settings → Back up Portainer, mantieni l’opzione predefinita Download backup file e fai clic su Download backup. Secondo la documentazione sulle impostazioni di Portainer, questo scarica un tar.gz di tutto ciò che Portainer memorizza sul suo volume /data, facoltativamente cifrato con password, e quell’archivio è tutto ciò che ti serve per ripristinare Portainer. La documentazione è altrettanto chiara sull’ambito: esegue il backup solo della configurazione di Portainer, non dei container, degli stack o dei volumi che hai distribuito. (I backup pianificati su S3 esistono, ma solo in Business Edition; con CE, metti un promemoria ricorrente nel tuo calendario.)

2. I dati delle tue applicazioni. La documentazione sui volumi di Docker definisce i volumi con nome il metodo preferito per rendere persistenti i dati dei container, e più facili da sottoporre a backup o migrare rispetto ai bind mount. Un mount in sola lettura impedisce di scrivere solo al container di backup: l’app stessa può ancora scrivere sul volume durante l’archiviazione e consegnarti una copia incoerente. Quindi ferma prima il container dell’app (sudo docker stop myapp), oppure usa il meccanismo di backup supportato dall’app stessa. Poi monta il volume in sola lettura in un container usa e getta, crea l’archivio con tar e riavvia l’app al termine (sostituisci con i tuoi nomi):

sudo docker run --rm \
  -v myapp_data:/source:ro \
  -v "$PWD":/backup \
  alpine tar czf /backup/myapp_data.tgz -C /source .

Per i database, preferisci lo strumento di dump del database stesso (pg_dump, mysqldump) alla copia dei file di dati attivi, così non archivi un file a metà scrittura. Poi sposta gli archivi fuori dalla macchina con una pianificazione: rsync o scp verso un’altra macchina, oppure invio a un object storage. Un backup che risiede sul disco di cui fa il backup sparisce insieme a quel disco.

3. I tuoi file Compose e i segreti. Se distribuisci gli stack da Git, i file Compose sono già fuori dall’host. Ciò che Git non contiene è tutto quello che non hai mai committato: file .env, chiavi API e password fornite al momento del deploy. Anche le directory montate in bind restano fuori dal backup dei volumi descritto sopra. Fai un inventario separato di questi elementi ed eseguine il backup cifrato.

Poi testa il ripristino, prima di averne bisogno. La documentazione di Portainer dice che il ripristino della configurazione funziona solo su un’istanza nuova: distribuisci un nuovo container Portainer con un volume dati vuoto (va bene un VPS usa e getta o il tuo laptop), scegli Restore Portainer from backup durante la configurazione iniziale e verifica di poter accedere con le vecchie credenziali e di vedere le definizioni dei tuoi stack. Questa prova copre solo la parte 1, la configurazione di Portainer. Le parti 2 e 3 richiedono un test a sé, app per app: ripristina un archivio in un volume nuovo, avvia l’app su di esso e controlla che i dati ci siano davvero. Un backup non testato è una speranza con un nome di file.

Quanto Costa Portainer? (E Quando Il Gratuito Smette Di Essere Gratuito?)

Portainer è doppiamente gratuito. Community Edition è gratuito e open source (licenza zlib), senza bisogno di chiave di licenza. E Portainer Business Edition è gratuito per sempre fino a 3 nodi: tutte le funzionalità Business, nessun limite di tempo, nessuna carta di credito. Ti registri per ottenere una chiave di licenza gratuita invece di pagare.

Edizione	Costo	Nodi	Ideale per
Community Edition	Gratuita, open source	Nessuna licenza per nodo	Progetti personali, homelab, self-hoster con un singolo VPS
Business Edition — 3 nodi gratis	Gratuita, senza limiti di tempo	Fino a 3	Piccoli homelab che vogliono funzionalità Business come RBAC
Home & Student	$155/anno	Fino a 15	Homelab più grandi e studenti; esclusivamente non commerciale
Business Starter	Da $105/mese	5, 10 o 15	Piccoli team che gestiscono infrastrutture reali (supporto della community)
Business Scale	Da $209/mese	Da 5 a 35	Team in crescita che necessitano di supporto 9×5
Enterprise	Su preventivo	Personalizzato	Esigenze di conformità e di supporto prioritario

I prezzi provengono dalla pagina dei prezzi di Portainer ad agosto 2026; Starter e Scale richiedono un impegno annuale.

Quindi quale dovresti scegliere? Per un singolo VPS con un solo amministratore, Community Edition: è open source, non richiede registrazione e fa tutto ciò che è descritto in questa guida, deploy da Git inclusi. Se vuoi il controllo degli accessi basato sui ruoli (RBAC) per un secondo utente, o gestisci già due o tre macchine, scegli invece il livello Business gratuito a 3 nodi: è lo stesso software con le funzionalità Business sbloccate, gratuito finché resti a tre nodi o meno. I piani a pagamento hanno senso solo quando gestisci un numero reale di nodi in un team, e controlla la voce sul supporto prima di dare per scontato che a pagamento significhi assistito: ad agosto 2026, la pagina dei prezzi di Portainer indica supporto della community sul piano Starter, supporto 9×5 entro il giorno lavorativo successivo dal piano Scale in su e supporto prioritario su Enterprise.

Dovresti Aggiungere Portainer o Saltarlo?

Ecco la risposta onesta in due frasi:

✅ Se prevedi di condividere questo server, fare il deploy da Git, o eseguire più di tre container da qui a un anno, installa Portainer mentre l’host è nuovo e le tue abitudini si stanno ancora formando intorno ad esso.

❌ Se stai eseguendo un’unica app tranquilla e ti trovi bene nel terminale, non ti mancherà l’interfaccia utente che non hai installato.

La vera domanda non è Portainer contro nessun Portainer. È se il self-hosting sia la scelta giusta per te, e hai risposto a questa domanda quando hai aperto questa scheda.

Un VPS da 4 GB, Docker e Portainer CE bastano per iniziare a fare self-hosting sul serio: scegli le tue app, somma i loro requisiti documentati e lascia che sia il foglio di calcolo, non la lista dei desideri, a decidere quando la box deve crescere.

Non è un brutto affare.

Domande Frequenti Su Docker E Portainer

Si può eseguire Docker su un VPS?

Sì. Un VPS con accesso root è uno dei posti più flessibili in cui eseguire Docker: installi Docker Engine sul sistema operativo Linux del server e ogni app gira nel proprio container. La distinzione su cui molti inciampano è che il VPS è il server virtuale che noleggi, mentre Docker è il software che esegui su di esso per isolare le applicazioni in container. Va bene qualsiasi VPS con accesso root e RAM sufficiente per i tuoi container; DreamHost VPS Hosting offre persino un’immagine Docker + Portainer preinstallata.

Per cosa si utilizza Portainer?

Portainer è utilizzato per gestire i container Docker, Docker Swarm e Kubernetes tramite un’interfaccia web. Funziona a sua volta come container Docker, si collega al socket Docker dell’host e ti offre una vista e un controllo tramite browser su tutti gli altri container dell’host: avviare e fermare i container, distribuire stack multi-container, visualizzare i log e gestire l’accesso degli utenti senza bisogno di SSH.

Ho bisogno di Portainer se ho Docker?

No, non hai bisogno di Portainer per usare Docker. Docker funziona completamente dal terminale, e molti self-hoster non installano mai un’interfaccia utente sopra.

Portainer dimostra il suo valore quando devi gestire più di due o tre container, condividere l’accesso con qualcuno che non vive in un terminale, o distribuire aggiornamenti di stack da un repository Git. Saltalo se gestisci uno o due container stabili e ti trovi a tuo agio con Docker Compose.

Su quale porta funziona Portainer?

Portainer serve la sua interfaccia web in HTTPS sulla porta 9443 per impostazione predefinita. Il comando di installazione ufficiale nella documentazione di installazione di Portainer per Linux pubblica anche la porta 8000, un tunnel TCP usato solo dagli Edge Agent quando in seguito colleghi host Docker remoti: è facoltativa, ed è per questo che l’installazione su un singolo host di questa guida elimina completamente il flag -p 8000:8000.

Quanta RAM richiede Portainer?

Gli attuali requisiti di sistema di Portainer non indicano un minimo di RAM: il Server gira come container leggero e le indicazioni sulle prestazioni riportate nella documentazione riguardano il disco, non la memoria. Dimensiona la RAM sommando i requisiti documentati del sistema operativo, del demone Docker e di ogni app che eseguirai, poi lascia un margine per i picchi.

Da DreamHost, il nostro piano VPS Hosting di base, Stack 4, include 4 GB di RAM: un punto di partenza per un piccolo stack di container per progetti secondari come Ghost o n8n. Che 4 GB bastino o meno dipende dalle app che esegui davvero; se i calcoli lo superano, puoi passare a un piano Stack più grande.

Portainer è gratuito?

Sì, e doppiamente. Portainer Community Edition è gratuito e open-source, senza bisogno di chiave di licenza. Anche Portainer Business Edition (che aggiunge funzionalità come il controllo degli accessi basato sui ruoli) è gratuito fino a 3 nodi, con tutte le funzionalità e senza limiti di tempo; ti registri per ottenere una chiave di licenza gratuita invece di pagare. Oltre tre nodi, i prezzi Business partono da $105/mese con il piano Starter secondo la pagina dei prezzi di Portainer (ad agosto 2026), e una licenza Home & Student da $155/anno copre gli homelab non commerciali fino a 15 nodi.

Portainer può gestire più host Docker?

Sì, Portainer gestisce più host Docker tramite Agent ed Edge Agent. L’Agent standard resta in ascolto sulla porta 9001 di ogni host remoto; gli Edge Agent invece si collegano in uscita alla porta tunnel 8000 del Server Portainer e, secondo la documentazione sui requisiti di Portainer, non hanno bisogno di porte in entrata aperte. Per chi fa self-hosting su un singolo VPS, nulla di tutto questo è necessario, ed è per questo che l’installazione di questa guida elimina il flag della porta 8000 incluso nel comando ufficiale di Portainer. Il giorno in cui colleghi un ambiente remoto tramite un Edge Agent, ridistribuisci Portainer aggiungendo -p 8000:8000, poi consenti la porta 8000 del container attraverso UFW dall’IP pubblico in uscita di ciascun Edge Agent, sostituendo qui EDGE_AGENT_IP: sudo ufw route allow proto tcp from EDGE_AGENT_IP to any port 8000.

Docker elude UFW su un VPS?

Sì, Docker elude UFW per impostazione predefinita perché Docker gestisce il traffico dei container a livello NAT di iptables, che si trova davanti alle catene INPUT e OUTPUT di UFW.

Secondo la documentazione sul filtraggio dei pacchetti di Docker, “i pacchetti vengono deviati prima di raggiungere le catene INPUT e OUTPUT utilizzate da ufw.” La soluzione è aggiungere le tue regole alla catena iptables DOCKER-USER, e uno strumento della community per integrarvi UFW è chaifeng/ufw-docker, installato prima ancora che Portainer si avvii, nel passaggio 4 di questa guida.