Installare Ollama su VPS in sicurezza

Cosa stai costruendo

Un singolo modello linguistico open-weight in esecuzione su un server di tua proprietà. Il modello risponde tramite un'API HTTP e, se desiderato, tramite una pagina di chat nel browser. Ollama è il componente che scarica il modello, lo carica in memoria e gestisce le richieste sulla porta http://127.0.0.1:11434. L'installazione richiede un solo comando. Le complessità del processo risiedono in altri aspetti: la scelta di un modello compatibile con la RAM del tuo VPS e il rischio di pubblicare accidentalmente un server di inferenza senza autenticazione su Internet.

Due avvertenze importanti. Un VPS con sola CPU esegue i modelli piccoli lentamente e l'API non dispone di autenticazione integrata. Entrambi i punti sono trattati dettagliatamente di seguito, poiché sono le cause principali di errore.

Verifica delle dimensioni reali, in numeri semplici

L'impronta di memoria di un modello corrisponde approssimativamente alla dimensione del file, più circa un gigabyte di overhead durante l'esecuzione, più una quota aggiuntiva per la context window. I modelli predefiniti di Ollama sono quantizzati a 4-bit (etichettati come Q4), il che richiede circa mezzo gigabyte di RAM per ogni miliardo di parametri. Il calcolo è quindi semplice e determina i requisiti.

Un modello da 3B come llama3.2:3b richiede un download di circa 2 GB e necessita di circa 4 GB di RAM libera per l'esecuzione. Un modello da 7B o 8B come mistral:7b o llama3.1:8b occupa circa 5 GB su disco e richiede circa 8 GB di RAM, 16 GB per operare senza problemi. Un modello da 13B o 14B richiede circa 16 GB. Qualsiasi modello nella fascia 30B-70B richiede un sistema con molta RAM o, realisticamente, una GPU; su un VPS con sola CPU il modello non caricherà oppure risponderà troppo lentamente per essere utile.

Passiamo alla velocità, poiché è il parametro che viene sottovalutato. L'inferenza su CPU è limitata dalla larghezza di banda della memoria, non dalla frequenza di clock; un VPS con vCPU condivisa ha una larghezza di banda limitata. Ci si può aspettare una velocità compresa tra una e poche decine di token al secondo: un modello Q4 da 7-8B può raggiungere i 4-10 token al secondo, un modello da 3B i 10-25. Una GPU è circa dieci volte più veloce. Questi sono dati approssimativi: il metodo corretto è misurare le prestazioni del proprio sistema, come mostrato nel passaggio successivo. Affidati al tuo eval rate, non ai numeri riportati in un articolo, incluso questo.

Conclusione pratica: i modelli piccoli quantizzati su CPU sono utili per bozze, riassunti e classificazione, se si accetta la velocità di elaborazione. Per qualsiasi utilizzo più ampio o veloce, è necessario prevedere un'istanza con GPU.

Per confrontare un modello specifico con un hardware specifico, stima l'impronta di memoria qui:

Install Ollama

Esistono due metodi puliti. Lo script ufficiale è il più semplice su un VPS bare-metal:

curl -fsSL https://ollama.com/install.sh | sh

Questo crea un utente di sistema denominato ollama, installa il binary in /usr/local/bin/ollama e registra un servizio systemd chiamato ollama.service che si avvia al boot e associa la porta 127.0.0.1:11434. Verificare che sia attivo:

systemctl status ollama
ollama --version

Se si utilizza già Docker, utilizzare il container:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

Prestare attenzione al prefisso 127.0.0.1: nella mappatura della porta. Questo associa la porta solo a localhost. Scrivere -p 11434:11434 invece pubblica la porta su ogni interfaccia; questo è l'errore segnalato nella sezione sulla sicurezza. Scegliere un solo metodo di installazione; non eseguire contemporaneamente lo script e il container, altrimenti due processi entreranno in conflitto per la stessa porta.

Scarica ed avvia il tuo primo modello

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull scarica i layer del modello su disco (circa 2 GB per questo modello). run li carica in memoria e avvia una prompt >>>. Digita una domanda. Il primo token potrebbe richiedere diversi secondi mentre i pesi vengono caricati da disco a RAM, poi la risposta viene trasmessa in streaming. Digita /bye per uscire dalla chat; Ollama continua a essere eseguito in background.

Verifica cosa è caricato e l'occupazione di memoria:

ollama ps

La colonna PROCESSOR indica lo stato reale. 100% CPU significa che non viene utilizzata alcuna GPU; questo causa la lentezza. Misura la velocità reale utilizzando il flag verbose:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

La riga eval rate stampata alla fine indica i token al secondo su questo hardware. Questo è il valore da utilizzare per la pianificazione.

Dove risiedono i modelli e quanta memoria disco acquistare

Installati dallo script ed eseguiti come servizio, i modelli risiedono nella home dell'utente ollama:

sudo du -sh /usr/share/ollama/.ollama/models

Se eseguiti interattivamente con il proprio utente, si trovano in ~/.ollama/models. All'interno del container, risiedono nel volume nominato ollama. Questo è importante perché i pesi quantizzati occupano spazio rapidamente: un modello da 3B occupa circa 2 GB, un modello da 7-8B circa 5 GB, un modello da 14B circa 9 GB. Scaricando quattro modelli per confrontarli, si consumano 20 GB senza accorgersene. Calcola la dimensione del disco in base ai modelli che intendi conservare e cancella gli altri con ollama rm <model>.

Eseguilo come un servizio controllato da te

Lo script di installazione ha già registrato ollama.service, quindi il servizio si riavvia all'avvio senza ulteriori interventi. L'impostazione da modificare è il tempo di permanenza di un modello in memoria e, su alcune configurazioni, l'indirizzo di bind; entrambe le voci vanno inserite in un file drop-in di systemd, in modo che un aggiornamento di Ollama non le sovrascriva:

sudo systemctl edit ollama.service

Aggiungi questo contenuto sotto l'header [Service] indicato dall'editor:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE indica per quanto tempo un modello rimane in memoria dopo l'ultima richiesta (default 5 minuti). Aumenta questo valore su un server interpellato costantemente per evitare il ricaricamento dei pesi ad ogni richiesta; imposta il valore a 0 su sistemi con poca memoria per liberare la RAM non appena una richiesta termina. systemctl edit ricarica i file dell'unità; riavvia per applicare le modifiche:

sudo systemctl restart ollama

Il punto di sicurezza più importante

Di default Ollama è vincolato a 127.0.0.1:11434, quindi solo i processi sul VPS stesso possono raggiungerlo. Questa impostazione predefinita è corretta. Mantienila.

L'API non ha autenticazione. Nessuna. Non esiste una API key, un login, un limite di frequenza o una allow-list. Chiunque riesca a raggiungere la porta 11434 può eseguire qualsiasi modello scaricato, scaricarne di nuovi, eliminarli e saturare la CPU o la GPU al massimo carico indefinitamente. Scanner come Shodan indicizzano migliaia di istanze Ollama aperte; un'istanza esposta viene individuata e sfruttata entro poche ore.

Ecco l'unico errore da non commettere mai: non impostare OLLAMA_HOST=0.0.0.0 e non aprire la porta 11434 nel firewall. Questo pubblica un server di inferenza non autenticato su tutta la rete internet. Nessuna configurazione può rendere sicura la porta 11434 su 0.0.0.0, perché Ollama non prevede opzioni di configurazione in merito: l'autenticazione semplicemente non esiste.

Esistono tre modi sicuri per raggiungere il modello da un dispositivo esterno al server:

• Mantienilo locale. Se l'unico chiamante è un altro programma sullo stesso VPS — uno script cron, un bot, un server MCP che collega i tuoi strumenti al modello — lascia il bind su 127.0.0.1 e fai in modo che quel programma chiami http://127.0.0.1:11434. Nulla viene esposto e non è necessario altro.
• Raggiungilo tramite un tunnel privato. Configura il VPS su un VPN WireGuard ospitata da te, imposta OLLAMA_HOST sull'indirizzo del tunnel (ad esempio 10.8.0.1, non 0.0.0.0) e solo i peer della VPN potranno connettersi. Internet non vedrà nulla sulla porta 11434.
• Utilizza un reverse proxy con autenticazione. Gestisci il TLS e richiedi una password o un token tramite nginx, Traefik o Caddy, quindi inoltra la richiesta a 127.0.0.1:11434. Ollama mantiene il bind su localhost; il proxy è l'unico elemento in ascolto sulla porta pubblica. Questo approccio è identico a applicare un certificato Let's Encrypt su nginx davanti a qualsiasi servizio locale.

L'opzione reverse-proxy è esattamente ciò che la chat UI ti offrirà nel passaggio successivo, con un sistema di login reale integrato.

Aggiungi un'interfaccia chat con Open WebUI, dietro TLS

Open WebUI è un'interfaccia chat self-hosted. Eseguila in Docker e indirizzala verso l'Ollama locale:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Il flag --network=host è il dettaglio fondamentale su un VPS Linux. Posiziona il container nello stesso namespace di rete dell'host; di conseguenza, 127.0.0.1 all'interno del container corrisponde al loopback dell'host e il container raggiunge Ollama su 127.0.0.1:11434 senza che Ollama debba ascoltare su altre interfacce. La configurazione tramite bridge-network che si trova altrove — --add-host=host.docker.internal:host-gateway con OLLAMA_BASE_URL=http://host.docker.internal:11434 — non funziona in questo caso: quel nome punta al gateway del bridge di Docker, e un servizio vincolato a 127.0.0.1 sull'host non è raggiungibile attraverso il bridge. Di conseguenza, Open WebUI non riesce a connettersi a Ollama.

L'uso del network dell'host comporta che Open WebUI ascolti sulla porta 8080 dell'host su ogni interfaccia; qualsiasi mappatura -p viene ignorata e Docker segnala l'evento tramite un warning. Chiudi quindi la porta 8080 sia sul firewall dell'host che su quello del provider, lasciando il reverse proxy TLS come unico punto di accesso pubblico. Al primo accesso, Open WebUI richiede la creazione di un account admin: tale account funge da livello di autenticazione, quindi utilizza una password sicura.

Per accedere alla chat dal proprio laptop tramite HTTPS, posiziona un reverse proxy TLS davanti a 127.0.0.1:8080. Se si gestiscono già diverse applicazioni Docker sulla macchina, Traefik con TLS automatico per molte app è la soluzione più pulita: un singolo blocco di label emette il certificato e instrada chat.example.com verso Open WebUI. La regola della sezione sicurezza rimane valida: il proxy gestisce la porta pubblica e il login, mentre Ollama rimane su localhost e la porta 8080 di Open WebUI resta protetta dal firewall.

Utilizzare l'endpoint compatibile con OpenAI dal proprio codice

Ollama implementa un sottoinsieme dell'API chat di OpenAI sulla porta /v1. Per questo motivo, la maggior parte delle librerie client di OpenAI funziona modificando due parametri: la base URL e una chiave fittizia.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

La api_key è richiesta dalla libreria client ma viene ignorata da Ollama; è sufficiente inserire una stringa qualsiasi. model deve essere un modello già scaricato; un nome sconosciuto restituisce l'errore model "x" not found, try pulling it first. Anche una chiamata curl segue lo stesso principio:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

Questo metodo permette di integrare il modello in agent e strumenti di editing. Se si sviluppa localmente sulla macchina, un modello locale può supportare script e plugin insieme a Claude Code in esecuzione sul VPS all'interno di tmux. In questo modo, le bozze private ed economiche rimangono locali, mentre il ragionamento complesso viene delegato a un modello ospitato tramite API a pagamento.

Modalità di errore, con le stringhe esatte che visualizzerai

Il processo viene "Killed" durante la generazione. Avvii un modello di grandi dimensioni e il terminale stampa Killed, oppure il log del server mostra llama runner process has terminated: signal: killed. Il Linux OOM killer ha interrotto il processo perché il modello richiedeva più RAM di quella disponibile sul sistema. Conferma la causa con sudo dmesg | grep -i oom, dove vedrai una riga simile a Out of memory: Killed process ... (ollama). La soluzione consiste nell'utilizzare un modello più piccolo o con quantizzazione più spinta — llama3.2:3b invece di un 13B — oppure nell'aggiungere dello swap, in modo che un carico che eccede appena la RAM fisica venga gestito lentamente invece di interrompersi. Lo swap trasforma un crash immediato in una risposta lenta; non rende praticabile un modello da 70B su 4 GB di RAM.

"Error: model requires more system memory". Ollama rifiuta di avviare il modello e stampa Error: model requires more system memory (X GiB) than is available (Y GiB). Questa è la versione corretta del crash descritto sopra: Ollama ha eseguito i calcoli e si è fermato invece di lasciare che l'OOM killer interrompesse il processo. Il sistema fornisce anche i due valori numerici. Scegli un modello i cui requisiti siano inferiori alla RAM libera (verifica con free -h), riduci la lunghezza del contesto o passa a un VPS più potente. Nessun flag permette al modello di entrare in memoria: la memoria fisica è un limite reale.

Il primo token richiede molto tempo, poi procede normalmente. Un modello caricato a freddo non stampa nulla per cinque o trenta secondi, poi lo streaming procede normalmente. Quella pausa è dovuta al caricamento dei pesi dal disco alla RAM per la prima volta; l'uso di storage lenti peggiora il problema. Una volta caricato, il modello rimane in memoria per la durata di OLLAMA_KEEP_ALIVE, quindi il secondo prompt riceverà una risposta istantanea. Aumenta quel valore se i tempi di attesa sono eccessivi e usa ollama ps per verificare se un modello è attualmente caricato.

Tutto è semplicemente lento. Dieci token al secondo o meno, senza alcun errore. Si tratta dell'inferenza tramite CPU che opera secondo le sue caratteristiche. ollama ps mostra 100% CPU, il che significa che non è presente una GPU. Questo non è un bug e nessuna impostazione può risolverlo, poiché il limite è la larghezza di banda della memoria e non una configurazione errata. Usa un modello più piccolo, accetta la velocità ridotta o passa a un'istanza con GPU — e misura il tasso reale con --verbose prima di concludere che ci sia un malfunzionamento.

Connection refused da un'altra macchina. Dal tuo laptop ricevi curl: (7) Failed to connect to <ip> port 11434: Connection refused. Il comportamento è corretto: Ollama è vincolato solo a localhost. Non tentare di "risolvere" il problema effettuando il bind su 0.0.0.0, che rappresenta esattamente l'errore di esposizione descritto sopra. Accedi al modello tramite VPN o attraverso un proxy con autenticazione.

Hai esposto la porta 11434 su internet. Se hai impostato OLLAMA_HOST=0.0.0.0, aperto il firewall e ora vedi download di modelli che non hai avviato o la CPU al 100% per colpa di client sconosciuti, il tuo sistema è stato scoperto e utilizzato. Questo è l'errore principale, non un caso isolato. Riconfigura il bind su 127.0.0.1 o sull'indirizzo VPN, chiudi la porta 11434 sul firewall e inserisci un sistema di autenticazione. Considera come interrogato da estranei qualsiasi comando inviato a quell'indirizzo mentre era aperto.

Backups and upgrades

I dati da preservare sono pochi. I modelli possono essere scaricati nuovamente; pertanto, è necessario eseguire il backup solo del volume dati di Open WebUI (account, cronologia chat, impostazioni) e di eventuali file systemd drop-in creati. Eseguire il backup del volume utilizzando un container temporaneo:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Aggiornare Ollama eseguendo nuovamente lo script di installazione; aggiornare Open WebUI con docker pull ghcr.io/open-webui/open-webui:main e successivamente ricreare il container. Non bloccare le versioni a lungo termine: sia la qualità dei modelli che il runtime evolvono rapidamente. Leggere le note di rilascio ed eseguire nuovi benchmark sul proprio sistema invece di fare affidamento sui dati dell'ultimo trimestre.

FAQ

È possibile eseguire un LLM su un VPS con sola CPU?

Sì, entro certi limiti. I modelli piccoli quantizzati tra 3B e 8B funzionano su CPU e sono utili per bozze, riassunti e classificazione — ma lentamente, con una velocità compresa tra i singoli e i pochi decine di token al secondo su una vCPU condivisa. I modelli da 13B in su sono estremamente lenti o non rientrano affatto nella RAM. Per prestazioni elevate o modelli più grandi è necessaria un'istanza con GPU.

Quanta RAM richiede ogni modello?

Una regola approssimativa per i modelli predefiniti quantizzati a 4-bit: circa 0.5 GB di RAM per ogni miliardo di parametri per i pesi, più circa 1 GB di overhead e un po' di spazio extra per il contesto. Un modello da 3B richiede circa 4 GB liberi, un modello da 7-8B circa 8 GB e un modello da 14B circa 16 GB. Verifica la memoria disponibile con free -h e lascia spazio per il sistema operativo e altri processi sul server.

L'API di Ollama è autenticata?

No. Ollama non dispone di autenticazione integrata, API key o limiti di frequenza (rate limit) — chiunque raggiunga la porta 11434 ha il controllo totale. Per questo motivo Ollama effettua il bind su 127.0.0.1 per default e non bisogna mai esporre la porta 11434 su 0.0.0.0 verso internet. Accedete localmente, tramite una VPN privata o attraverso un reverse proxy che aggiunga un login.

Come posso aggiungere un'interfaccia web di chat?

Esegui Open WebUI in Docker con --network=host in modo che condivida il loopback dell'host e raggiunga Ollama nativo su http://127.0.0.1:11434, quindi posiziona un reverse proxy TLS davanti alla porta 8080 per l'accesso dal tuo laptop. Mantieni la porta 8080 chiusa sul firewall in modo che il proxy sia l'unico punto di accesso pubblico. L'account admin di Open WebUI gestisce il login e la password si imposta al primo avvio.

Come posso chiamarlo dalla mia applicazione?

Usa l'endpoint compatibile con OpenAI su http://127.0.0.1:11434/v1. Punta qualsiasi SDK di OpenAI a quell'URL base, passa una stringa qualsiasi come API key poiché viene ignorata, e imposta model con il nome di un modello scaricato. Il codice OpenAI esistente solitamente funziona senza modifiche, tranne che per l'URL base e la chiave.