Nativo o container — quale scegliere?

Nativo esegue la tua app web direttamente sull'host con systemd — veloce, poca RAM, runtime condiviso. Container la esegue dentro Docker — versione del runtime dedicata per app, ~30–100 MB di RAM in più.

Ultimo aggiornamento 24 mag 2026

Rilevante solo se stai distribuendo una app web (Node, Python, Go). Per siti statici e WordPress questa scelta non viene mostrata.

Quando distribuisci una app web, la sezione Avanzate nella finestra di distribuzione ha un interruttore: Distribuisci come processo nativo o Container. Entrambe le opzioni mettono online la tua app dietro con HTTPS di : la differenza è come viene eseguito il tuo codice sotto il cofano.

Cosa stai scegliendo

L'interruttore "Distribuisci come" nella sezione Avanzate della finestra di distribuzione

Processo nativo — Server Manager installa il runtime una sola volta sull'host (Node 22 LTS, Python 3 + venv o Go), poi esegue la tua app direttamente sotto come servizio dedicato.
Container — Server Manager crea un'immagine Docker per la tua app con la versione del runtime che scegli, poi la esegue come container esposto tramite Caddy sull'host.

In entrambi i casi: stesso dominio, stesso HTTPS, stesso pulsante per scaricare l'ultima versione da git, stesso accesso al codice dalla scheda File.

Come funziona Nativo

La tua app si trova in /opt/<appName>/ e viene eseguita come unità chiamata <appName>.service. Il runtime (Node, Python, Go) viene installato una sola volta a livello di sistema operativo ed è condiviso tra tutte le app web native sul server.

Distribuzione nativa: tre app sotto systemd, tutte condividono una sola installazione di Node e una sola di Python sull'host

File in /opt/<appName>/
Servizio gestito da systemd — sudo systemctl status <appName> funziona come previsto
Log acquisiti da journald e mostrati nella scheda Log
Runtime una sola installazione di Node 22, una di Python 3 e una di Go sull'host: tutte le app native le condividono

Come funziona Container

La tua app viene eseguita dentro il proprio container Docker. Il file compose si trova in /opt/<appName>/docker-compose.yml e il container è esposto tramite Caddy sull'host, che fa da reverse proxy dal tuo dominio alla porta interna del container.

Distribuzione in container: tre app, ciascuna nel proprio container Docker con la propria versione del runtime fissata

File in /opt/<appName>/ — il tuo codice sorgente, più un Dockerfile e un docker-compose.yml generati da noi
Servizio gestito da Docker — sudo docker compose -f /opt/<appName>/docker-compose.yml ps mostra lo stato
Log acquisiti da Docker e mostrati nella scheda Log
Runtime ogni app fissa la propria versione: Node 18, Node 22, Python 3.11, Python 3.13 possono convivere

Quale dovrei scegliere?

La maggior parte delle app dovrebbe partire con Nativo. Scegli Container solo se hai un motivo specifico.

Se…	Scegli
Hai una sola app sul server e non ti interessa fissare la versione	Nativo
Vuoi il minimo consumo extra di RAM (importante su server da 1 GB / 2 GB)	Nativo
Vuoi distribuzioni più rapide (nessuna immagine da creare)	Nativo
Hai due app con versioni del runtime diverse (per esempio Node 18 + Node 22)	Container almeno per quella diversa dalle altre
Vuoi isolamento stretto tra le app (per esempio, una contiene codice di terze parti di cui non ti fidi completamente)	Container
La tua app porta con sé una dipendenza complessa non legata al runtime (versione specifica del client Postgres, build di ImageMagick, ecc.)	Container (tutto viene incluso nell'immagine)
Prevedi di spostare questa app su un altro host in futuro	Container (l'immagine è portabile; le distribuzioni native dipendono dal runtime dell'host)

Il compromesso in numeri (indicativi):

Nativo: ~50–200 MB RSS per app (solo l'app + interprete). Prima distribuzione: 10–30 s.
Container: ~50–200 MB RSS per l'app + ~30–100 MB di overhead Docker per container. Prima distribuzione: 1–3 min (creazione dell'immagine).

Su un server da 2 GB quasi inattivo, puoi eseguire 5–8 app web native + Caddy + un piccolo database. Con i container scendi a circa 4–6.

Cambiare in seguito

La modalità è intrinseca all'app: nel pannello del servizio non c'è un interruttore per passare un'app nativa a Container o viceversa.

Per cambiare, ridistribuisci l'app dalla finestra modale e scegli l'altra opzione:

Apri Azioni → Distribuisci dal mio computer (oppure Distribuisci una app web da un repository git)
Trascina il tuo codice o incolla l'URL del repository
Espandi Avanzate → cambia l'interruttore Distribuisci come
Fai clic su Distribuisci: l'app esistente viene sostituita con la nuova modalità

Il codice resta su disco (le regole .helm-keep descritte in Più siti sullo stesso server si applicano allo stesso modo alle ridistribuzioni in Container). Il tuo dominio continua a puntare allo stesso posto. Il downtime è quello di una normale ridistribuzione: di solito meno di un minuto.