SSD Nodes Learn
Guide Matt ConnorDi Matt Connor · Aggiornato 2026-07-24

Migliori app da self-host nel 2026

Scopri 25 applicazioni da installare su VPS nel 2026. Analisi tecnica di RAM e disco per Docker su Ubuntu 24.04 KVM con i consigliati per ogni funzione.

Cosa stai costruendo

Non una singola app, ma una selezione. Questo è il hub per tutto il resto di questo sito: venticinque applicazioni che vale davvero la pena eseguire sul proprio VPS nel 2026, raggruppate per funzione. Per ognuna riceverai il servizio che sostituisce, un dato onesto di RAM e disco, e l'unico problema critico se decidi di saltarlo. I link rimandano alla guida completa passo dopo passo, dove disponibile.

Gestisco un provider VPS da quindici anni e eseguo la maggior parte di queste app sui miei server. Pertanto, i valori di risorse indicati sotto sono quelli effettivamente utilizzati dall'app sotto un carico reale ridotto, non il "minimo" indicato nelle pagine di marketing. Considerali come un budget, a cui poi aggiungere un margine di manovra.

Prerequisiti e la realtà dei fatti

Ogni app qui presente gira su un nuovo VPS Ubuntu 24.04 KVM con privilegi root o sudo. Quasi tutte sono distribuite come container Docker, quindi installa Docker una volta sola e sarai pronto per l'intera lista:

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker "$USER"
newgrp docker
docker run --rm hello-world

Se i comandi docker falliscono con permission denied while trying to connect to the Docker daemon socket, hai saltato il passaggio di gruppo o non hai aperto una nuova shell — esci e rientra. Se docker compose restituisce docker: 'compose' is not a docker command, hai il vecchio binario standalone; lo script sopra installa il moderno plugin Compose, che si chiama con docker compose (uno spazio, non un trattino).

Tre realtà definiscono tutto ciò che segue. Primo, la RAM è il limite, non il disco o la CPU. Un VPS da 1 GB esegue un'unica piccola app e nient'altro. 4 GB è il punto ideale per un server "self-host per alcune cose". 2 GB è la via di mezzo problematica dove un principiante accumula un terzo servizio, incontra un silenzioso errore Out-Of-Memory kill e non capisce mai perché il container è svanito — sudo dmesg mostra la riga Out of memory: Killed process che il daemon ha assorbito. Secondo, qualsiasi servizio pubblico necessita di un nome e di un certificato — un semplice IP funziona per i test ma fallisce non appena si desidera che un'app mobile o un browser si fidino di esso. Terzo, due porte decidono metà delle tue opzioni: la 80 e la 443 devono raggiungere il server per il TLS automatico, e la 25 in uscita è bloccata dalla maggior parte dei provider, motivo per cui l'email è nella lista "da non fare" alla fine.

File e foto

  • Nextcloud sostituisce Google Drive, Dropbox e Google Calendar in un'unica suite. Budget 1–2 GB di RAM più il peso dei tuoi file. L'unico problema: SQLite va bene per una demo ma è una trappola in produzione — installalo su PostgreSQL fin dal primo avvio, perché migrare il database dopo che i dati sono già presenti è il modo più comune in cui si rovina un Nextcloud. La guida completa Nextcloud su un VPS con Docker, TLS e backup lo configura correttamente fin da subito.
  • Immich sostituisce Google Photos, inclusa l'app per smartphone che carica automaticamente il rullino e la ricerca per volti e oggetti. Budget 6 GB di RAM — la documentazione di Immich indica questo come minimo, 8 GB sono ideali, e il container machine-learning è la parte più esigente — e il disco deve essere pari alla tua libreria più circa il venti percentuale per le miniature. Il problema: Immich presenta ancora cambiamenti radicali tra le release, quindi non eseguire mai un latest cieco; blocca una versione specifica e leggi le note di rilascio prima di ogni aggiornamento. La guida libreria fotografica Immich self-hosted copre il percorso di aggiornamento sicuro.
  • Seafile sostituisce Dropbox con il motore di sincronizzazione più veloce tra i tre. Budget circa 1 GB di RAM. Il problema: Seafile memorizza i file come blocchi indirizzati per contenuto, non come semplici file su disco, quindi non puoi navigare i dati con ls e devi eseguire il backup tramite gli strumenti proprietari di Seafile, non copiando una cartella.

Password

  • Vaultwarden sostituisce il piano a pagamento di Bitwarden, LastPass e 1Password con un piccolo server in Rust che utilizza il protocollo Bitwarden, rendendo compatibili tutte le app e le estensioni ufficiali di Bitwarden. Budget 100–200 MB di RAM e quasi zero disco. Il problema: questo server contiene ogni tua password, quindi TLS e backup non sono opzionali, sono l'essenza stessa del servizio — e imposta il ADMIN_TOKEN come hash Argon2, perché un token in chiaro nel tuo file compose è una chiave master esposta. La guida password manager Vaultwarden è il miglior possibile punto di partenza per il self-hosting.

Media

  • Jellyfin sostituisce Plex e, per la tua libreria personale, Netflix — totalmente open, senza account e senza streaming remoto a pagamento. Budget 1–2 GB di RAM in idle, ma la CPU ha picchi elevati durante il transcoding. Il problema: il transcoding software di uno stream 4K surriscalderà un piccolo VPS; fornisci al server l'accelerazione hardware o mantieni i file in un formato che i client possono riprodurre direttamente (Direct Play), così il server dovrà solo trasmettere byte. La guida Jellyfin media server su un VPS spiega la differenza.
  • Navidrome sostituisce Spotify per la tua musica, con streaming verso qualsiasi app compatibile con Subsonic. Budget 150–300 MB di RAM — è scritto in Go e consuma pochissimo. Il problema: la prima scansione della libreria legge i tag di ogni file e può richiedere un'ora su una collezione vasta, e tag ID3 errati portano a una pessima esperienza di navigazione.
  • Audiobookshelf sostituisce Audible e la tua app per podcast, mantenendo la posizione di riproduzione tra i dispositivi. Budget 200–500 MB di RAM. Il problema: richiede una struttura rigorosa di una cartella per libro, e un import disordinato produce una libreria disordinata e parzialmente rilevata, difficile da sistemare in seguito.

Automazione e AI

  • n8n sostituisce Zapier e Make con un costruttore di workflow visuale di tua proprietà, senza fatturazione per singola task. Budget 400 MB–1 GB di RAM. Il problema: n8n cripta le credenziali salvate con una chiave generata al primo avvio, e se perdi quella chiave — o dimentichi di impostare N8N_ENCRYPTION_KEY lasciando che la rigeneri — ogni credenziale salvata diventerà illeggibile e dovrai reinserirle tutte. La guida n8n self-hosted con HTTPS blocca la chiave e inserisce un certificato reale davanti agli URL dei webhook.
  • Ollama sostituisce un abbonamento a ChatGPT per l'inferenza locale e privata di LLM. Il budget dipende dal modello: un modello da 7–8B richiede circa 8 GB di RAM, e ogni modello occupa 4–8 GB su disco. Il problema: su un VPS con sola CPU, l'inferenza è reale ma lenta — considera parole al secondo, non le risposte istantanee delle API ospitate — quindi adegua le aspettative, o affitta un server con GPU. La guida esegui Ollama per ospitare un LLM fornisce numeri realistici.

Comunicazione

  • Rocket.Chat sostituisce Slack per un team, con thread, chiamate e integrazioni. Budget 2 GB di RAM e oltre, poiché gira su MongoDB che è il componente pesante. Il problema: Rocket.Chat richiede una specifica versione major di MongoDB per ogni release, e saltare una versione durante un aggiornamento può corrompere il database — aggiorna un passo alla volta. La guida Rocket.Chat con Docker Compose descrive la progressione delle versioni.
  • Matrix (Synapse) sostituisce Slack e Discord con una rete federata e con crittografia end-to-end dove possiedi il tuo homeserver. Budget 1–2 GB di RAM che aumenta man mano che ti unisci a grandi stanze pubbliche. Il problema: l'uso di memoria di Synapse aumenta drasticamente nelle grandi stanze federate, e deve girare su PostgreSQL — il default SQLite funziona solo per test monoutente e fallisce non appena si attiva la federazione. Se Synapse risulta troppo pesante, i server Conduit o Dendrite sono più leggeri e usano lo stesso protocollo.

Networking e accesso

  • WireGuard sostituisce una VPN commerciale, fornendo un tunnel privato verso il tuo IP e i tuoi altri servizi. Budget quasi nullo — meno di 50 MB e la crittografia gira nel kernel. Il problema: sulla virtualizzazione basata su container (OpenVZ, alcuni LXC) il modulo fallisce con RTNETLINK answers: Operation not supported; è necessario usare KVM. La guida VPN WireGuard self-hosted è il riferimento, e accoppiarlo a servizi vincolati al tunnel è il modo per tenere tutto fuori da internet pubblico.
  • Traefik sostituisce i virtual host nginx scritti a mano e il rinnovo manuale dei certificati — scopre i tuoi container tramite i loro Docker labels e recupera automaticamente i certificati Let's Encrypt. Budget circa 100 MB di RAM. Il problema: il modello di configurazione basato su label è inizialmente confuso, e un singolo label errato lascia un'app senza routing senza errori evidenti. La guida Traefik reverse proxy per più app Docker è progettata esattamente per far girare diverse app di questa lista dietro un unico punto di accesso.
  • AdGuard Home sostituisce un dispositivo Pi-hole e il filtraggio DNS a pagamento, bloccando pubblicità e tracker per ogni dispositivo sulla rete a livello DNS. Budget 100–150 MB di RAM. Il problema: richiede la porta 53, che collide con systemd-resolved su Ubuntu — fallisce l'avvio con listen udp 0.0.0.0:53: bind: address already in use finché non si libera la porta.

Monitoraggio

  • Uptime Kuma sostituisce Pingdom, UptimeRobot e StatusPage con una dashboard pulita e avvisi su quasi ogni canale. Budget 150–300 MB di RAM. Il problema, che molti ignorano, è questo: monitora il tuo server di produzione da un server diverso — Uptime Kuma che gira sullo stesso server che monitora non può dirti quando quel server si arresta. La guida monitoraggio stato Uptime Kuma copre l'installazione esterna.
  • Zabbix sostituisce Datadog e suite di monitoraggio enterprise, con metriche profonde basate su agent, trigger e cronologia. Budget 2 GB di RAM e oltre, più il proprio database. Il problema: Zabbix è potente ma molto complesso da configurare — è eccessivo per monitorare tre container, ma è lo strumento giusto per una flotta di server. Inizia con Uptime Kuma; passa a server di monitoraggio Zabbix quando avrai un'infrastruttura reale da monitorare.

Prometheus e Grafana sono stati omessi intenzionalmente da questa lista: sono strumenti eccellenti per scale di flotta, ma sono più pesanti da eseguire e configurare rispetto a quanto giustificato da un setup personale di due o tre server, e Uptime Kuma insieme a Zabbix rispondono alle stesse domande a questa scala con meno manutenzione.

Dashboard e pannelli di controllo

Questi cambiano l'intero modello — invece di eseguire file compose manualmente, un pannello gestisce le app per te.

  • Cloudron sostituisce la necessità di installazioni manuali con un app store rifinito, TLS automatico e backup integrati. Budget minimo 2 GB di RAM, 4 GB per stare comodi. Il problema: è un sistema molto strutturato che vuole gestire l'intero server, ed è gratuito solo fino a due app — oltre tale limite è un prodotto a pagamento.
  • CasaOS sostituisce le dashboard homelab disordinate con una griglia di app intuitiva, gratuita e leggera. Budget circa 150-300 MB per CasaOS stesso. Il problema: è progettato per una rete domestica affidabile e non è protetto per internet pubblico — non esporlo direttamente; raggiungilo tramite WireGuard.
  • Coolify sostituisce Heroku, Vercel e Netlify — deployment tramite git-push, database e preview sul proprio server. Budget minimo 2 GB di RAM. Il problema: è un progetto giovane che evolve rapidamente, quindi blocca le versioni e leggi le note di rilascio prima di aggiornare. La guida confronto Cloudron vs CasaOS vs Coolify analizza quale dei tre sia adatto a te.

Strumenti per sviluppatori e produttività

  • Gitea (o Forgejo) sostituisce GitHub per repository privati, issue e CI. Budget 200–500 MB di RAM. Il problema: Forgejo è il fork di Gitea gestito dalla community ed è quello che molti consigliano ora; entrambi sono eccellenti, ma scegline uno e fai il backup dei repository e del database insieme — un backup del repo senza il database fa perdere ogni issue e pull request.
  • Paperless-ngx sostituisce un archivio cartaceo e scanner documentali a pagamento, effettuando l'OCR di tutto per rendere i documenti ricercabili. Budget circa 1 GB di RAM, con picchi di CPU durante l'OCR. Il problema: i risultati dell'OCR dipendono dalla qualità delle scansioni, e rielaborare un archivio vasto è lento — ottimizzalo prima di importare massivamente dieci anni di documenti.
  • Actual Budget sostituisce YNAB e Mint con una gestione del budget a buste, locale e privata. Budget circa 150 MB di RAM. Il problema: la sincronizzazione bancaria automatica è un modulo separato con la sua configurazione, quindi di base le transazioni vanno importate manualmente.
  • FreshRSS sostituisce Feedly e il defunto Google Reader — un lettore di feed veloce e privato con app mobile. Budget circa 150 MB di RAM. Il problema: configura il refresh dei feed basato su cron, altrimenti i feed si aggiornano solo quando apri la pagina.
  • BookStack sostituisce Notion e Confluence per la documentazione, organizzata come scaffali, libri e pagine. Budget circa 500 MB di RAM su PHP e MySQL. Il problema: struttura il contenuto in modo specifico invece di note libere, cosa che alcuni amano e altri trovano rigida — provalo prima di affidargli l'intero wiki.
  • Home Assistant sostituisce SmartThings e una dozzina di app dei produttori, unificando la smart home localmente. Budget circa 1 GB di RAM. Il problema: gran parte della sua funzionalità richiede l'accesso alla rete locale per comunicare con i dispositivi, quindi funziona meglio su hardware domestico che su un VPS remoto — esegui la dashboard da remoto e usa un bridge se necessario.

Un'installazione rappresentativa

Per rendere il concetto concreto, ecco la struttura di un self-hosting: un file compose, un certificato reale e un backup. Questo è Uptime Kuma, ma ogni app della lista segue lo stesso schema.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    volumes:
      - ./data:/app/data
    ports:
      - "127.0.0.1:3001:3001"
    restart: unless-stopped
docker compose up -d
docker compose logs -f

Nota il 127.0.0.1: — l'app ascolta solo su localhost, e un reverse proxy come Traefik o nginx termina il TLS davanti ad essa. Vincolare direttamente alla porta 0.0.0.0:3001 è il modo in cui si pubblicano accidentalmente pannelli admin non criptati su tutta internet.

Cosa NON ospitare da soli (ancora)

  • Email. Questo è il punto onesto. La porta 25 in uscita è bloccata dalla maggior parte dei provider VPS — vedrai Connection timed out da telnet aspmx.l.google.com 25 e non c'è nulla da correggere, è una politica aziendale. Anche con la porta 25 aperta, un IP nuovo senza reputazione, record PTR, SPF, DKIM e DMARC farà finire la tua mail nello spam o la farà rifiutare. È un lavoro continuo, non un progetto per il weekend. Se sei determinato, procedi con consapevolezza usando la guida email self-hosted con Mailcow e preparati a gestire la deliverability per mesi.
  • Qualsiasi cosa che non puoi backuppare e ripristinare in modo affidabile. Se non hai mai eseguito un test di ripristino, non hai un backup, hai solo una speranza. Non mettere dati insostituibili — l'unica copia delle tue foto, dei tuoi account — su un servizio finché il suo ripristino non è provato.
  • L'unica copia di una dipendenza critica. Un server DNS self-hosted che, quando crasha, porta via internet a tutta la tua rete, è un cattivo primo progetto. Mantieni sempre un fallback esterno.
  • Sistemi di sicurezza in tempo reale. Allarmi domestici, avvisi medici o qualsiasi cosa dove cinque minuti di downtime siano un problema reale non deve stare su un server amatoriale che aggiorni la domenica sera.

Come scegliere il primo e i due non negoziabili

Scegli l'app che elimina una bolletta che odi o una preoccupazione per la privacy che senti davvero. In pratica, le migliori prime installazioni sono Vaultwarden e Uptime Kuma: entrambi sono piccoli, entrambi sono immediatamente utili e entrambi sono tolleranti se commetti un errore. Fai funzionare uno end-to-end — installazione, certificato, backup, test di ripristino — prima di aggiungerne un secondo. La competenza che stai costruendo è l'operatività, non il semplice cliccare su install.

Due cose sono non negoziabili per ogni singola app sopra elencata, senza eccezioni:

  1. TLS su tutto ciò che è pubblico. Un servizio su IP nudo e in chiaro è una demo, non un deployment. Metti un certificato reale davanti ad esso con Certbot e Let's Encrypt su nginx, o lascia che Traefik lo faccia automaticamente. Poi proteggi l'ingresso con Fail2ban per SSH su Ubuntu 24.04.
  2. Backup che hai effettivamente ripristinato. Automatizza un dump notturno — database e volume dati insieme — invialo fuori dal server e, una volta al mese, ripristinalo su un VPS di prova per dimostrare che funziona. Il giorno in cui il tuo disco si rompe è il giorno sbagliato per scoprire che il backup era vuoto.

Se gestisci correttamente questi due punti, il self-hosting è un piacere. Se li ignori, è solo un conto alla rovescia.

Le opzioni vanno dal pratico all'assurdo, da un server Minecraft su un VPS per famiglie a, se vuoi una storia ammonitrice, il datacenter meno efficiente al mondo.

FAQ

Cosa dovrei ospitare per primo?

Vaultwarden. Un password manager ti dà valore quotidiano, sostituisce un abbonamento e ti costringe a imparare l'intero workflow — Docker, un reverse proxy, TLS e backup — su un'app abbastanza piccola da essere ricostruita in dieci minuti se la rompi. Uptime Kuma è un ottimo secondo, così scoprirai i disservizi prima dei tuoi utenti.

Di quanto VPS ho realmente bisogno?

Per una singola piccola app, 1 GB di RAM è sufficiente. Per un server confortevole per "gestire alcune cose", punta a 4 GB — il punto di mezzo da 2 GB è dove le persone incontrano i silenziosi errori Out-Of-Memory e non riescono a capire il perché. La RAM è quasi sempre il limite; aggiungi disco in base ai dati che prevedi di archiviare, e aspettati che Immich, Ollama e qualsiasi cosa con un database grande richiedano il massimo di entrambi.

Cosa non dovrei ospitare da solo?

L'email, prima di tutto — la porta 25 in uscita è bloccata dalla maggior parte dei provider e la deliverability è una lotta costante. Dopo di essa, qualsiasi cosa che non puoi backuppare e ripristinare in modo affidabile, e qualsiasi singolo punto di guasto il cui downtime causi danni reali, come un server DNS senza fallback o un sistema di sicurezza domestico. Tutto il resto in questa lista è valido.

Ho bisogno di Docker per tutto questo?

No, ma è consigliato. Ogni app qui ha un'immagine Docker, e Docker ti garantisce installazioni pulite, rimozioni pulite, facile gestione delle versioni e portabilità su un nuovo host. Alcune app (WireGuard, Zabbix) possono anche essere installate nativamente da apt se preferisci. Una volta imparato un file compose, li conosci tutti, motivo per cui l'intera lista è accessibile.

Come mantengo tutto sicuro?

Quattro abitudini coprono la maggior parte delle necessità: metti il TLS davanti a tutto, mantieni l'SSH protetto con l'accesso tramite chiave e Fail2ban per il ban dei tentativi di brute-force, esponi pubblicamente solo le porte strettamente necessarie e raggiungi il resto tramite la tua VPN WireGuard, e aggiorna regolarmente leggendo le note di rilascio in modo che un aggiornamento non ti sorprenda mai. I backup sono la quinta abitudine — sono la tua salvezza quando un errore scivola attraverso le prime quattro.

#self-hosting#docker#open-source#vps#homelab