Alternative a Open WebUI per un VPS: confronto pratico

Quale alternativa a Open WebUI scegliere su un VPS

Le alternative a Open WebUI vengono quasi sempre confrontate su un laptop, dove la RAM è abbondante e nessun servizio è in ascolto su un indirizzo pubblico. Un VPS cambia entrambe queste condizioni, modificando anche la graduatoria. Open WebUI resta la scelta predefinita quando accede una seconda persona, perché include account utente completi e un pannello di amministrazione. I progetti più leggeri sono avvantaggiati quando l'interfaccia deve condividere con il modello l'ultimo gigabyte di RAM disponibile. Il prezzo di questo vantaggio è l'autenticazione: non ne includono alcuna.

Tutto ciò che segue si basa sulla documentazione dei singoli progetti, consultata ad agosto 2026. I quattro criteri sono quelli che diventano rilevanti solo quando il server è raggiungibile da Internet.

Quattro aspetti rilevanti solo con un IP pubblico

• Memoria utilizzata dall'interfaccia. Il server del modello è il processo più oneroso sul sistema. Ogni megabyte utilizzato dall'interfaccia è un megabyte che il modello non può utilizzare.
• Autenticazione. Alcuni di questi progetti supportano account utente e ruoli. Altri presuppongono di essere l'unico software in esecuzione sul laptop e non includono alcun accesso.
• Inferenza remota. Un'interfaccia che può raggiungere soltanto 127.0.0.1:11434 obbliga a eseguire il modello sullo stesso sistema dell'interfaccia.
• Manutenzione. Un container con un file SQLite richiede una gestione diversa rispetto a sei container con MongoDB e un database vettoriale a supporto.

Quanta RAM lascia il modello all’interfaccia

L’interfaccia non è il componente più impegnativo del server. Il modello lo è. Le dimensioni pubblicate dei download indicano il limite minimo, perché i pesi devono restare residenti mentre il modello elabora le risposte. L’uso effettivo della memoria è maggiore rispetto alle dimensioni del download, una volta allocata la cache del contesto.

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.3"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

Questi sono i valori riportati dalle pagine della libreria Ollama nell’agosto 2026. Sono dimensioni pubblicate, non misurazioni. Su un VPS con 4 GB, qwen3:4b con 2.5 GB lascia meno di 1.5 GB al sistema operativo e a tutto il resto. La cache del contesto riduce ulteriormente questo margine man mano che la conversazione cresce. qwen3:8b con 5.2 GB non entra affatto in quel server. È una situazione che le raccolte comparative per laptop non considerano mai. Ed è proprio qui che un’interfaccia di chat che occupa qualche centinaio di megabyte può determinare se il modello riesce a funzionare.

Misura invece di fidarti dei valori riportati in una raccolta comparativa, incluso questo articolo. Esegui docker stats --no-stream dopo un’ora di utilizzo reale, non un minuto dopo l’avvio del container, perché la memoria rilevante viene allocata al primo utilizzo.

Open WebUI: ancora l’impostazione predefinita per più utenti

Open WebUI viene eseguito a partire da una sola immagine e conserva i dati in un unico volume.

docker run -d -p 127.0.0.1:3000:8080 -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main

Il comando nel README del progetto pubblica -p 3000:8080, che resta in ascolto su tutte le interfacce. Il prefisso 127.0.0.1: lo mantiene sull’interfaccia di loopback. Su un VPS questo prefisso è più importante di qualsiasi altro elemento della riga, perché Docker scrive regole iptables proprie e una porta pubblicata ignora le regole di blocco di ufw.

Raggiungi la pagina tramite un tunnel o un proxy, descritti entrambi più avanti, quindi crea il primo account. Questo account diventa l’amministratore. Le registrazioni successive vengono create con il ruolo pending, il valore predefinito documentato di DEFAULT_USER_ROLE. Anche un utente estraneo che raggiunge la pagina non può quindi usare il tuo modello finché un amministratore non lo approva.

Open WebUI usa più memoria dei progetti riportati di seguito perché offre più funzionalità. La pagina sulle prestazioni del progetto indica i componenti responsabili di questo consumo. Il motore di embedding predefinito carica un modello sentence-transformers all’interno del container, con un consumo documentato di circa 500 MB per processo worker. Impostando RAG_EMBEDDING_ENGINE=ollama, deleghi questa attività al model server già in esecuzione. AUDIO_STT_ENGINE=webapi evita di caricare un modello locale di speech-to-text. Con SQLite e DATABASE_POOL_SIZE non impostata, il pool ricade su una dimensione interna elevata e ogni connessione crea una propria page cache e una propria memory map. Su un sistema con poche risorse, imposta quindi DATABASE_POOL_SIZE=8 e DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False impedisce all’interfaccia di chiedere un completamento al modello mentre l’utente sta ancora digitando.

LibreChat: più utenti, con uno stack alle spalle

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

L'interfaccia risponde sulla porta 3080. LibreChat è la scelta da considerare quando serve un sistema di gestione delle identità e non una semplice schermata di accesso: documenta gli accessi LDAP e OAuth2 e include un pannello di amministrazione per utenti e ruoli. Questa funzionalità richiede uno stack.

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 6,
    "notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

Il file compose predefinito avvia 6 servizi: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Nessuno di questi è il modello. MongoDB e pgvector richiedono memoria propria; su una macchina con 4 GB, è memoria che non sarà disponibile per il modello.

Gli aggiornamenti si eseguono con git, ed è proprio questo il passaggio che spesso viene eseguito in modo errato.

docker compose down
git pull
docker compose pull
docker compose up -d

git pull si interrompe con un conflitto se hai modificato il file tracciato docker-compose.yml, lasciando l'aggiornamento applicato solo in parte. Inserisci le modifiche in docker-compose.override.yml, che il progetto mette a disposizione a questo scopo, e conserva i secret in .env. Entrambi i file non sono tracciati, quindi git pull non li modifica.

Configura LibreChat per usare il tuo model server con un endpoint personalizzato in librechat.yaml.

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

Sostituisci model-host con l'indirizzo della macchina che esegue Ollama. Il campo apiKey deve essere presente anche se Ollama ne ignora il valore, quindi è sufficiente un placeholder. Se LibreChat viene eseguito in Docker e Ollama viene eseguito sulla stessa macchina, all'interno del container localhost indica il container stesso; usa invece host.docker.internal.

Hollama e OrionChat: il lavoro viene eseguito dal browser

Hollama pubblica un'applicazione web da un singolo container di piccole dimensioni. Le chat risiedono nello storage del browser, non sul server.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

La versione del README di questo comando usa --rm, che elimina il container quando si arresta. Di conseguenza, l'interfaccia non torna disponibile dopo un riavvio. Dietro un reverse proxy, aggiungere -e VITE_ALLOWED_HOSTS='chat.example.com', perché l'immagine consente soltanto l'host localhost e risponde alle richieste con qualsiasi altro hostname con un errore di host bloccato, invece di aprire l'applicazione.

OrionChat si spinge oltre e non dispone affatto di un componente server. Clonare il repository e pubblicare la directory con il web server già in uso, oppure aprire index.html dal disco. Le API key sono memorizzate nel localStorage del browser, la cronologia delle chat resta nel browser e l'applicazione elimina le chat più vecchie quando il numero supera 512.

Nessuno dei due progetti dispone di un login, perché nessuno dei due ha un server che possa verificarlo. Su un laptop questo non è un problema. Su un VPS significa che la pagina non deve mai essere pubblicata su 0.0.0.0. Significa inoltre che un aspetto può sfuggire più facilmente: è il browser, non il server, a chiamare il modello.

Questo fatto determina dove è possibile usare questi due progetti. Il browser deve raggiungere direttamente Ollama. Ollama deve quindi essere in ascolto su un indirizzo diverso dal loopback e non dispone di alcun tipo di autenticazione. Da ciò seguono due regole del browser. Una pagina pubblicata tramite HTTPS non può chiamare un endpoint HTTP semplice e la console stampa Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked.. Le chiamate verso qualsiasi altra origin vengono rifiutate con has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource finché non si autorizza tale origin.

Il metodo documentato da Ollama per modificare entrambe le impostazioni consiste nell'usare un override di systemd.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

ss dovrebbe ora stampare 0.0.0.0:11434, mentre prima stampava 127.0.0.1:11434. Applicare questa modifica soltanto quando un firewall o un proxy con autenticazione controlla già chi può raggiungere la porta, perché una porta 11434 aperta espone un model server e gli scanner automatici raggiungono rapidamente una nuova porta pubblica. Il tunnel SSH riportato di seguito evita completamente il problema: la pagina viene quindi eseguita su un'origin localhost, consentita da Ollama per impostazione predefinita, e la porta non lascia mai il server.

Ogni applicazione può usare un endpoint Ollama o vLLM remoto

Open WebUI può farlo e la connessione viene effettuata lato server. OLLAMA_BASE_URL=http://model-host:11434 indica l’endpoint Ollama. Per vLLM o qualsiasi altro server compatibile con OpenAI, imposta OPENAI_API_BASE_URL=http://model-host:8000/v1 con un OPENAI_API_KEY non vuoto e mantieni il suffisso /v1, che è obbligatorio. OPENAI_API_BASE_URLS accetta più backend separati da punto e virgola.

LibreChat può farlo tramite baseURL dell’endpoint personalizzato mostrato sopra. Anche questa richiesta esce dal server, quindi le regole del browser non si applicano.

Hollama e OrionChat possono puntare a qualsiasi endpoint inserito nelle rispettive impostazioni, ma la richiesta esce dal browser. Tutto ciò che è descritto nella sezione precedente si applica a queste applicazioni e a nessun’altra.

Separare l’interfaccia dal modello è il vantaggio più utile offerto da un endpoint remoto. Installa l’interfaccia su un server di dimensioni ridotte e il modello sul server con memoria sufficiente. Questo è anche il momento di decidere se Ollama o vLLM deve gestire le richieste, perché i due componenti si comportano in modo molto diverso quando più persone usano contemporaneamente il modello. Se il model server non esiste ancora, inizia da eseguire Ollama su un VPS e, su un server con sola CPU, leggi il confronto tra Ollama e llama.cpp prima di scegliere il runner.

Non pubblicare una UI di chat senza login su 0.0.0.0

La pagina dedicata all'hardening di Open WebUI afferma che il progetto è «progettato per reti private e affidabili, come altre infrastrutture self-hosted quali database, registri di container e server CI», e indica di posizionarlo dietro una VPN oppure dietro un reverse proxy con autenticazione. Un progetto completamente privo di login richiede almeno lo stesso trattamento.

Verifica quali servizi sono in ascolto prima di considerare sicura una configurazione.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

Una riga con 127.0.0.1:3000 è il risultato desiderato. Una riga con 0.0.0.0:3000 significa che l'interfaccia di chat è esposta su Internet. Dal computer locale, una risposta curl -sI http://YOUR.VPS.IP:3000 a HTTP/1.1 200 OK indica la stessa cosa in modo ancora più esplicito.

Disabilitare il login di Open WebUI con WEBUI_AUTH=False è un'impostazione per un singolo utente, adatta a una macchina che nessun altro può raggiungere. Inoltre, l'impostazione non viene applicata a un'installazione che contiene già account; in quel caso viene visualizzato il messaggio You can't turn off authentication because there are existing users.

Schema uno: associare il servizio al loopback e raggiungerlo tramite SSH. Pubblica ogni porta su 127.0.0.1, quindi inoltra solo ciò che serve: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, e apri http://localhost:3000 sul laptop. Non viene pubblicato nulla, quindi nulla può essere sottoposto a scansione. Per Hollama o OrionChat, inoltra la porta del modello nello stesso comando con -L 11434:127.0.0.1:11434 e lascia Ollama in ascolto sul loopback. La sicurezza di questo schema dipende dalla configurazione SSH, quindi abbinalo a SSH con sole chiavi e sshd con hardening.

Schema due: un reverse proxy che autentica la richiesta prima che raggiunga l'applicazione. Mantieni l'applicazione sul loopback, assegna al proxy la porta 443 e configura il single sign-on davanti all'applicazione. Traefik gestito tramite le label di Docker Compose con Authentik come identity provider assegna a ogni applicazione del server un unico login e un unico certificato. Con Open WebUI dietro TLS (transport layer security), imposta WEBUI_SESSION_COOKIE_SECURE=true e WEBUI_SESSION_COOKIE_SAME_SITE=strict. Riduci anche JWT_EXPIRES_IN rispetto al valore predefinito di quattro settimane, perché la documentazione di Open WebUI specifica che, senza Redis, il logout non invalida il token: questo resta utilizzabile fino alla scadenza automatica.

Lo schema due non protegge i progetti utilizzabili soltanto dal browser. Un proxy davanti alla pagina non protegge l'endpoint del modello, e una richiesta fetch dalla pagina verso un hostname diverso non include il cookie di sessione. Di conseguenza, il proxy con autenticazione davanti a Ollama risponde con un redirect verso un modulo di login e la chat non funziona. Instrada l'endpoint del modello sotto lo stesso hostname della pagina oppure usa lo schema uno.

Quale scegliere

Se lo utilizzeranno altre persone oltre a te, esegui Open WebUI. Offre account reali, inserisce i nuovi utenti in una coda di approvazione e i relativi manutentori pubblicano indicazioni per il rafforzamento della sicurezza che puoi seguire. Se ti servono LDAP o un pannello di amministrazione, esegui LibreChat e verifica con docker stats che i suoi sei servizi, oltre al modello, rientrino effettivamente nelle risorse disponibili prima di farvi affidamento. Se il servizio è destinato a una sola persona su un sistema di piccole dimensioni, dove il modello utilizza già la maggior parte della RAM, esegui Hollama o OrionChat tramite un tunnel SSH e lascia che sia il browser a mantenere lo stato. Su un VPS, la scelta sbagliata consiste nel pubblicare uno qualsiasi di questi servizi su 0.0.0.0 senza autenticazione davanti.

FAQ

Open WebUI è sicuro da esporre direttamente su un IP pubblico?

La relativa pagina sull'hardening lo descrive come un software destinato a reti private e attendibili, nella stessa categoria di un database o di un server CI. Supporta account reali: il primo account diventa amministratore, mentre quelli successivi restano pending finché non vengono approvati. È quindi molto più sicuro di un'interfaccia senza autenticazione. Tuttavia, va comunque pubblicato dietro un reverse proxy con TLS e, quando possibile, con single sign-on. Pubblica la porta del container come 127.0.0.1:3000:8080, in modo che le regole iptables di Docker non possano esporla a Internet senza che tu lo sappia.

Quale alternativa a Open WebUI usa meno RAM su un VPS?

Le applicazioni basate sul browser, Hollama e OrionChat, perché l'applicazione viene eseguita sul client. Il server invia soltanto file statici e OrionChat non richiede alcun container applicativo. Open WebUI mantiene in memoria un processo Python, un database e, per impostazione predefinita, un modello locale di embedding. La documentazione indica circa 500 MB per worker per il solo modello di embedding. Verifica i valori sul tuo server con docker stats --no-stream, perché cambiano in base alle funzionalità abilitate.

Queste interfacce di chat possono usare un server Ollama su un altro host?

Open WebUI e LibreChat lo consentono e la connessione viene effettuata dal server dell'applicazione, quindi non si applicano le regole del browser. Imposta OLLAMA_BASE_URL per Open WebUI oppure baseURL in un endpoint personalizzato per LibreChat. Per vLLM o un altro server compatibile con OpenAI, usa OPENAI_API_BASE_URL con il suffisso /v1 e una API key non vuota. Anche Hollama e OrionChat possono puntare a un endpoint qualsiasi, ma la richiesta proviene dal browser. Di conseguenza, l'endpoint deve essere raggiungibile anche dal browser.

Perché l'interfaccia di chat nel browser non riesce a raggiungere Ollama?

Quasi tutti i casi dipendono da due cause. Per impostazione predefinita Ollama si mette in ascolto su 127.0.0.1:11434, quindi un browser su un altro computer non può raggiungerlo finché non cambia OLLAMA_HOST. Inoltre, Ollama accetta richieste cross-origin soltanto da localhost. Una pagina pubblicata sul tuo dominio viene quindi rifiutata con No 'Access-Control-Allow-Origin' header is present on the requested resource finché quell'origine non viene aggiunta a OLLAMA_ORIGINS. Se la pagina usa HTTPS e l'endpoint usa HTTP, il browser blocca la richiesta come mixed content prima che Ollama possa riceverla. Imposta entrambe le variabili in un override systemctl edit ollama.service oppure inoltra la porta tramite SSH: in questo modo il problema scompare.