Self-hosting di app su un VPS: architettura, consumo RAM e da dove iniziare
Guida decisionale per il self-hosting di app su un VPS con Docker. Dati reali di consumo memoria per oltre 10 app, combinazioni per piani da 4 GB e 8 GB e un framework per scegliere la prima applicazione.
Hai un VPS. Magari lo hai appena ottenuto, o magari ci fai già girare qualcosa e vuoi fare di più. In ogni caso, la domanda è la stessa: cosa ci faccio girare, e ci sta?
Questa guida risponde a questo. Copre l'architettura di uno stack applicativo self-hosted, fornisce numeri reali di consumo memoria misurati su un VPS 4 vCPU/8 GB e offre una matrice decisionale per scegliere la prima (o prossima) app. Nessuna lista di nomi di app. Nessuna stima teorica. Dati e un piano.
Prerequisiti: Questa guida presuppone che Docker e un reverse proxy siano già in funzione. Se non è così, inizia con Docker in produzione su un VPS: cosa si rompe e come risolvere per installare Docker, Docker Compose e Caddy o Traefik su Debian 12 o Ubuntu 24.04. Per i fondamenti di Docker Compose, vedi [-> docker-compose-multi-service-vps].
Perché fare self-hosting su un VPS anziché su un homelab?
Un VPS ti dà hosting sempre attivo con un indirizzo IPv4 pubblico, niente CGNAT, niente bolletta elettrica e nessun hardware da mantenere. Gli snapshot gestiti dal provider coprono il disaster recovery. Un VPS 4 vCPU/8 GB fa girare comodamente 5-8 app Docker per pochi euro al mese. La tua connessione internet cade; il tuo VPS no.
| Fattore | VPS | Homelab |
|---|---|---|
| IP pubblico | Incluso, statico | Spesso dietro CGNAT. Richiede workaround con tunnel. |
| Uptime | SLA 99,9%+, alimentazione ridondante | Dipende dal tuo ISP e dalla rete elettrica |
| Banda | Simmetrica, tipicamente 1 Gbps+ | Asimmetrica. L'upload è il collo di bottiglia. |
| Manutenzione hardware | Problema del provider | Problema tuo. Guasti ai dischi, rumore delle ventole, calore. |
| Elettricità | Inclusa nel prezzo | 20-60 EUR/anno per un piccolo server acceso 24/7 |
| Snapshot/backup | Un clic, gestiti dal provider | Costruisci e testi tu la pipeline di backup |
| Costo iniziale | Da ~4 EUR/mese | 200-500+ EUR per un Mini PC o NAS |
| Accesso fisico | Nessuno. Solo SSH. | Accesso completo. Utile per dispositivi USB, array ZFS. |
Un homelab ha senso se hai bisogno di storage locale (array ZFS, NAS), hardware USB (stick Zigbee, dongle SDR) o vuoi imparare l'amministrazione bare-metal. Per tutto il resto, un VPS è più semplice e più economico per iniziare.
La maggior parte degli ISP residenziali ora usa Carrier-Grade NAT, il che significa che condividi un IP pubblico con decine di altri clienti. Non puoi fare port-forwarding. Non puoi ricevere connessioni in ingresso. Le tue app self-hosted sono invisibili su internet. Esistono workaround (Cloudflare Tunnels, relay WireGuard attraverso un VPS), ma aggiungono complessità e una dipendenza da un servizio esterno. Un VPS aggira completamente il problema: ottieni un IPv4 pubblico dedicato, controlli il DNS e il traffico in ingresso funziona e basta.
Se vuoi entrambi, usa un VPS come edge pubblico e un tunnel WireGuard verso il tuo homelab per i servizi privati. Ma per la maggior parte delle app self-hosted, un VPS da solo è sufficiente.
Com'è fatto uno stack applicativo self-hosted?
Uno stack self-hosted su VPS segue un'architettura a livelli: un reverse proxy sta davanti, instradando il traffico HTTPS verso i container applicativi. Ogni app si connette al proprio database (o usa SQLite integrato). Uno strato di backup crea snapshot secondo una pianificazione.
Internet
│
▼
┌─────────────────────────────┐
│ Reverse Proxy (Caddy) │ Port 443 ← only public port
│ TLS termination + routing │
└──────┬──────┬──────┬────────┘
│ │ │
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌─────┐
│App 1│ │App 2│ │App 3│ Docker containers
└──┬──┘ └──┬──┘ └──┬──┘
│ │ │
▼ ▼ ▼
┌─────┐ ┌─────┐ ┌─────┐
│ DB │ │ DB │ │SQLite│ PostgreSQL, Redis, or embedded
└─────┘ └─────┘ └─────┘
│
▼
┌─────────────────┐
│ Backup Layer │ Restic, borgmatic, or provider snapshots
│ (scheduled) │
└─────────────────┘
Decisioni chiave:
- Reverse proxy: Caddy provvede automaticamente i certificati TLS senza configurazione. Traefik si integra con le label Docker per l'auto-discovery. Entrambi funzionano. Caddy è più semplice per i principianti.
- Database: Molte app leggere (Vaultwarden, Uptime Kuma, Beszel) usano SQLite integrato. Nessun container database separato necessario. Le app più pesanti (Immich, Plausible, Gitea) richiedono PostgreSQL.
- Backup: Gli snapshot del provider coprono l'intero disco. Per backup a livello applicativo, usa Restic o borgmatic verso un target offsite (storage compatibile S3 o un secondo VPS).
- Rete: Tutti i container applicativi si trovano su una rete Docker interna. Solo il reverse proxy espone le porte 80 e 443. Le app non si collegano mai direttamente alle interfacce pubbliche.
Questa architettura è trattata in dettaglio su Docker in produzione su un VPS: cosa si rompe e come risolvere.
Quanta RAM consumano effettivamente le app self-hosted?
Meno di quanto pensi. La maggior parte delle app self-hosted popolari al minimo consuma meno di 200 MB. Le eccezioni sono le app con funzionalità di machine learning (Immich) o motori di analisi integrati (Plausible con ClickHouse).
I numeri qui sotto sono la memoria RSS a riposo/uso leggero da docker stats, misurata su un VPS Virtua Cloud 4 vCPU/8 GB con Debian 12. I valori di picco rappresentano i picchi tipici durante l'uso attivo (upload di foto, OCR di documenti, esecuzione di workflow).
| App | Cosa sostituisce | RAM a riposo | RAM di picco | Storage/mese | Database |
|---|---|---|---|---|---|
| Vaultwarden | Bitwarden, 1Password | ~25 MB | ~50 MB | Minimo | SQLite |
| Uptime Kuma | UptimeRobot, Pingdom | ~100 MB | ~170 MB | Minimo | SQLite |
| Beszel | Datadog (base) | ~50 MB | ~80 MB | Minimo | Integrato |
| Gitea | GitHub (repo privati) | ~150 MB | ~300 MB | ~50 MB/repo | PostgreSQL o SQLite |
| n8n | Zapier, Make | ~100 MB | ~500 MB+ | Varia in base ai workflow | PostgreSQL |
| Paperless-ngx | Schedario | ~300 MB | ~1 GB | ~5 MB/documento | PostgreSQL + Redis |
| Nextcloud | Google Drive, Dropbox | ~250 MB | ~512 MB | Varia in base ai file | PostgreSQL + Redis |
| Coolify | Vercel, Railway | ~500 MB | ~1,2 GB | Varia in base ai deploy | PostgreSQL (incluso) |
| Plausible | Google Analytics | ~400 MB | ~1,5 GB | ~100 MB/1M visualizzazioni | PostgreSQL + ClickHouse |
| Immich | Google Photos | ~800 MB | ~2,5 GB | ~3 GB/1000 foto | PostgreSQL + Redis |
Alcune note su questi numeri:
- Immich con machine learning (rilevamento volti/oggetti) attivato necessita di 4-6 GB totali. I numeri sopra sono con ML attivato ma a riposo. Durante un'importazione massiva di foto, aspettati 3-4 GB. Puoi disattivare l'ML per scendere a ~400 MB, ma perdi la ricerca intelligente e il riconoscimento facciale.
- Plausible: la RAM dipende dal volume di traffico. ClickHouse ama la memoria. Per un sito con meno di 100.000 visualizzazioni/mese, i numeri sopra sono validi. I siti ad alto traffico necessitano di più.
- n8n a riposo è leggero, ma workflow complessi con grandi payload JSON o integrazioni AI producono picchi importanti. I workflow con agenti AI possono consumare 200 MB+ per esecuzione.
- Paperless-ngx ha picchi durante l'OCR. Imposta
PAPERLESS_WEBSERVER_WORKERS=1in Docker per risparmiare ~150 MB se sei l'unico utente.
Quale app dovrei hostare per prima sul mio VPS?
Inizia con Vaultwarden. Usa 25 MB di RAM, si deploya in meno di 10 minuti, sostituisce un password manager a pagamento che usi ogni giorno e ti obbliga a configurare correttamente il TLS. Quella configurazione TLS (reverse proxy + DNS + certificati) è la base di cui ogni altra app self-hosted ha bisogno. Un'app, tre vantaggi: privacy, risparmio e infrastruttura riutilizzabile.
| App | Impatto privacy | Complessità setup | SaaS sostituito | RAM min. |
|---|---|---|---|---|
| Vaultwarden | Molto alto (password) | Bassa (10 min) | Bitwarden/1Password | 128 MB |
| Immich | Alto (foto personali) | Media (30 min) | Google Photos | 2 GB (4 GB con ML) |
| Paperless-ngx | Alto (documenti, carte d'identità) | Media (20 min) | Schedario + app scanner | 512 MB |
| Plausible | Medio (analytics visitatori) | Media-alta (25 min) | Google Analytics | 1 GB |
| Uptime Kuma + Beszel | Basso (monitoring infra) | Bassa (10 min) | UptimeRobot + Datadog | 256 MB |
| Gitea | Medio (codice sorgente) | Bassa (15 min) | Repo privati GitHub | 256 MB |
| n8n | Medio (dati workflow) | Media (20 min) | Zapier, Make | 512 MB |
| Coolify | Basso (tool di deploy) | Media (20 min) | Vercel, Railway | 1 GB |
L'impatto sulla privacy è la ragione più forte per il self-hosting. Le tue password, foto e documenti scansionati sono i dati più sensibili che gestisci quotidianamente. Hostarli sul server di qualcun altro significa fidarti della loro sicurezza, della loro giurisdizione e della loro continuità operativa. Sul tuo VPS in Europa, quei dati restano sotto il tuo controllo e sotto il GDPR.
La complessità del setup tiene conto dello stack completo: container dell'app, database, configurazione del reverse proxy e primo backup. "Bassa" significa un singolo docker compose up -d dopo aver scritto un file Compose. "Media" aggiunge un database e la configurazione dei volumi di storage. "Media-alta" coinvolge più servizi interdipendenti (ClickHouse per Plausible, container ML per Immich).
Per i tutorial di ogni app, segui i link alla fine di questa guida.
Cosa posso far girare su un VPS da 4 GB vs uno da 8 GB?
Un VPS da 4 GB fa girare un solido stack personale. Un VPS da 8 GB gestisce tutto ciò di cui uno sviluppatore indipendente o un piccolo team ha bisogno. I numeri sotto tengono conto del reverse proxy (~30 MB), dell'overhead di Docker e del sistema operativo stesso (~300-400 MB occupati).
VPS da 4 GB (~3,2 GB disponibili per le app)
| Combinazione | RAM totale a riposo | Margine |
|---|---|---|
| Vaultwarden + Uptime Kuma + Beszel + Gitea | ~325 MB | ~2,9 GB |
| Vaultwarden + Paperless-ngx + Uptime Kuma | ~425 MB | ~2,8 GB |
| Vaultwarden + n8n + Beszel + Gitea | ~325 MB | ~2,9 GB |
| Vaultwarden + Nextcloud + Uptime Kuma | ~375 MB | ~2,8 GB |
Queste combinazioni lasciano ampio margine per i picchi di utilizzo. Anche quando Paperless-ngx sale a 1 GB durante l'OCR, c'è ancora spazio. Evita Immich con ML o Plausible su 4 GB a meno che non sia l'unica app.
VPS da 8 GB (~7 GB disponibili per le app)
| Combinazione | RAM totale a riposo | Margine |
|---|---|---|
| Vaultwarden + Immich + Uptime Kuma + Beszel | ~975 MB | ~6 GB |
| Vaultwarden + Plausible + Gitea + Paperless-ngx + Beszel | ~925 MB | ~6 GB |
| Vaultwarden + Coolify + Uptime Kuma + n8n | ~725 MB | ~6,3 GB |
| Tutte le leggere (Vaultwarden + Gitea + Uptime Kuma + Beszel + n8n + Paperless-ngx) | ~725 MB | ~6,3 GB |
Con 8 GB, puoi far girare comodamente Immich con ML accanto a tre o quattro app leggere. Puoi anche far girare Plausible con ClickHouse senza preoccuparti della pressione sulla memoria. Questo è il punto ideale per un setup di self-hosting personale.
La RAM a riposo è ciò su cui pianifichi, ma i picchi sono ciò che fa crashare il server. Paperless-ngx ha picchi durante l'OCR. Immich ha picchi durante l'importazione di foto con classificazione ML. n8n ha picchi durante l'esecuzione di workflow con grandi payload. La colonna margine sopra è la tua rete di sicurezza. Se il margine scende sotto 1 GB, rischi che l'OOM killer di Linux termini un container nel momento peggiore. Mantieni almeno 1,5 GB di margine per qualsiasi stack che includa Immich o Plausible.
Per un VPS Virtua Cloud con 4 vCPU e 8 GB di RAM su storage NVMe, consulta i piani attuali. La posizione a Francoforte colloca i tuoi dati nell'UE sotto il diritto tedesco sulla protezione dei dati.
Quali app self-hosted necessitano di hosting europeo?
Qualsiasi app che memorizza dati personali beneficia dell'hosting europeo sotto il GDPR. Ma alcune app gestiscono dati che rendono urgente la questione giurisdizionale.
Alta priorità per hosting EU:
- Vaultwarden memorizza ogni password che possiedi. Una violazione qui è catastrofica. L'hosting europeo significa che si applicano gli obblighi di notifica delle violazioni del GDPR.
- Immich contiene foto personali, spesso con volti di familiari. I dati di riconoscimento facciale sono dati biometrici ai sensi dell'Articolo 9 del GDPR. Categoria speciale. Protezioni aggiuntive.
- Paperless-ngx memorizza documenti d'identità scansionati, documenti fiscali, contratti. Tra i dati personali più sensibili che possiedi.
Priorità media:
- Plausible raccoglie analytics dei visitatori. È progettato con la privacy al centro (niente cookie, niente dati personali), ma i dati appartengono comunque ai tuoi visitatori.
- Gitea può contenere codice sorgente proprietario. Non dati personali in senso stretto, ma proprietà intellettuale che vuoi controllare.
- n8n: i workflow spesso elaborano dati provenienti da più servizi. Lo strato di automazione vede tutto.
Priorità inferiore:
- Uptime Kuma / Beszel memorizzano dati di monitoraggio. Nessun dato personale a meno che tu non stia monitorando endpoint che ne contengono.
- Coolify è un tool di deployment. Gestisce il tuo codice ma non memorizza dati degli utenti finali.
Se sei un'azienda europea o gestisci dati di cittadini UE, hostare queste app su un VPS in Germania (o un altro paese UE) semplifica la tua conformità al GDPR. Controlli i dati. Sai dove sono. Scegli tu chi ha accesso.
Come mantengo le mie app self-hosted sicure e aggiornate?
Self-hosting significa che sei tu l'amministratore di sistema. Questo è il prezzo del controllo. Ecco le pratiche non negoziabili:
Firewall prima di tutto. Prima di deployare qualsiasi app, configura ufw per consentire solo SSH (porta 22) e HTTPS (porta 443). Blocca tutto il resto. Questo è trattato in Docker in produzione su un VPS: cosa si rompe e come risolvere.
TLS ovunque. Il tuo reverse proxy (Caddy o Traefik) gestisce la terminazione TLS. Ogni app ottiene HTTPS. Senza eccezioni. Niente "aggiungo il TLS dopo". Caddy provvede automaticamente i certificati Let's Encrypt.
Aggiornamenti. Controlla settimanalmente gli aggiornamenti delle immagini container. Scarica le nuove immagini, ricrea i container:
docker compose pull
docker compose up -d
Per aggiornamenti di sicurezza critici (Vaultwarden, qualsiasi app esposta su internet), iscriviti alle release GitHub del progetto o al feed RSS. Release di Vaultwarden e Release di Immich sono buoni esempi.
Backup. Testali. Un backup che non hai mai ripristinato non è un backup. Usa gli snapshot del provider per il ripristino completo del disco e Restic o borgmatic per backup offsite a livello applicativo. Pianificali con cron o un timer systemd. Verificali mensilmente.
Gestione dei segreti. Non inserire mai password direttamente in docker-compose.yml. Usa un file .env con chmod 600:
openssl rand -base64 32 > /dev/null # example: generate a strong password
# docker-compose.yml
services:
app:
env_file: .env
# .env (chmod 600, owned by root)
DB_PASSWORD=<generated-password>
SECRET_KEY=<generated-key>
Monitoraggio. Fai girare Uptime Kuma per i controlli degli endpoint esterni e Beszel per le metriche a livello container (CPU, RAM, disco per container). Entrambi sono leggeri e ti danno visibilità prima che i problemi diventino disservizi. Vedi Self-hosting di Uptime Kuma e Beszel su un VPS con Docker Compose.
Consapevolezza dei log. Sappi dove sono i tuoi log. I container Docker inviano i log su stdout di default. Visualizzali con:
docker compose logs -f --tail=50 <service-name>
Per i servizi a livello di sistema (il reverse proxy se gira in modo nativo, SSH, firewall), usa journalctl:
journalctl -u caddy -f
Quando qualcosa si rompe, i log sono la tua prima fermata. Non Stack Overflow. Non Reddit. I log.
E adesso?
Ogni app nella matrice decisionale sopra ha un tutorial dedicato con configurazioni Docker Compose complete, setup del reverse proxy, backup e hardening:
| App | Tutorial |
|---|---|
| Vaultwarden (password) | Self-hosting di Vaultwarden su un VPS con Docker Compose |
| Immich (foto) | Self-hosting di Immich su un VPS con Docker Compose |
| Plausible (analytics) | Self-hosting di Plausible Analytics su un VPS con Docker Compose |
| Uptime Kuma + Beszel (monitoraggio) | Self-hosting di Uptime Kuma e Beszel su un VPS con Docker Compose |
| Coolify vs Dokploy (PaaS) | Coolify vs Dokploy: quale PaaS self-hosted per il tuo VPS? |
| Paperless-ngx (documenti) | Self-hosting di Paperless-ngx su un VPS con Docker Compose |
| Gitea (hosting Git) | Self-hosting di Gitea su un VPS con Docker Compose |
Se non hai ancora configurato Docker e un reverse proxy, inizia qui: Docker in produzione su un VPS: cosa si rompe e come risolvere. Quella guida copre Debian 12 e Ubuntu 24.04, installa Docker con Compose, configura Caddy come reverse proxy con TLS automatico, imposta un firewall e crea un utente di deploy non-root. Tutto in questa guida si basa su quelle fondamenta.