Alternative a Open WebUI per un VPS: confronto

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 modifica entrambi questi aspetti e, di conseguenza, cambia la classifica. Open WebUI resta la scelta predefinita quando accede una seconda persona, perché include account utente reali e un pannello di amministrazione. I progetti più leggeri sono preferibili quando l’interfaccia compete con il modello per l’ultimo gigabyte di RAM. Il compromesso è l’autenticazione: non ne offrono alcuna.

Tutto ciò che segue è ricavato dalla documentazione dei singoli progetti, consultata ad agosto 2026. I quattro criteri sono rilevanti soltanto quando il server è raggiungibile da Internet.

Quattro aspetti che contano solo con un IP pubblico

• Memoria accanto al modello. Il server del modello è il processo più oneroso del 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 presumono di essere l'unico software in esecuzione sul laptop e non prevedono 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 un'attività diversa rispetto a sei container con MongoDB e un database vettoriale a supporto.

Quanta RAM lascia il modello per l'interfaccia

L'interfaccia non è l'elemento più pesante del server. Lo è il modello. Le dimensioni pubblicate per il download indicano il limite minimo, perché i pesi devono rimanere residenti mentre il modello genera le risposte. L'uso reale della memoria è superiore alle dimensioni del download dopo l'allocazione della 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 da 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 quando la conversazione cresce. Per questo il valore num_ctx impostato è una scelta relativa alla memoria tanto quanto alla qualità. qwen3:8b con 5.2 GB non entra affatto in quel server. È una situazione che le raccolte di modelli per laptop non considerano mai. È anche il caso in cui un'interfaccia di chat che occupa qualche centinaio di megabyte determina se il modello può essere eseguito. Se stai dimensionando un server per qualcosa di molto più grande di questi modelli, il calcolo per un modello 27B su un VPS con sola CPU mostra quanto rapidamente l'interfaccia smetta di essere il fattore determinante.

Misura invece di fidarti dei valori riportati in una raccolta, compreso questo. 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. Ollama rilascia inoltre i pesi dopo cinque minuti di inattività. Di conseguenza, una lettura eseguita tra due conversazioni sottostima il picco. Il messaggio successivo deve quindi ricaricare tutto il modello, a meno che tu non mantenga il modello residente con keep_alive.

Open WebUI: ancora la scelta predefinita per più utenti

Open WebUI viene eseguito da una singola immagine e conserva i dati in un 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 ascolta su tutte le interfacce. Il prefisso 127.0.0.1: lo mantiene sull'interfaccia di loopback. Su un VPS questo prefisso è più importante di ogni altro elemento della riga, perché Docker scrive regole iptables proprie e una porta pubblicata ignora le regole di deny di ufw.

Raggiungi la pagina tramite un tunnel o un proxy, descritti entrambi di seguito, 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, quindi un estraneo che raggiunge la pagina non può ancora usare il tuo modello finché un amministratore non lo approva.

Open WebUI usa più memoria dei progetti descritti di seguito perché offre più funzionalità, e la relativa pagina sulle prestazioni 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, affidi questa attività al model server che esegui già. AUDIO_STT_ENGINE=webapi evita di caricare un modello locale di speech-to-text. Con SQLite e DATABASE_POOL_SIZE non impostato, il pool ricorre a una dimensione interna elevata e ogni connessione crea una propria page cache e una propria memory map; su un sistema con poca memoria 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: multiutente, con uno stack dietro

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 giusta quando serve un sistema di gestione delle identità, non una semplice schermata di accesso: la documentazione descrive 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 e, su una macchina con 4 GB, si tratta della memoria necessaria al modello.

Gli aggiornamenti consistono in un’operazione Git, che è il punto in cui si commettono più errori.

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 parzialmente. Inserisci le modifiche in docker-compose.override.yml, che il progetto mette a disposizione proprio per questo scopo, e conserva i secret in .env. Entrambi i file non sono tracciati, quindi git pull non li modifica.

Configura LibreChat in modo che utilizzi il tuo server del modello tramite 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 ignora il relativo valore, quindi puoi usare un segnaposto. Se LibreChat viene eseguito in Docker e Ollama sulla stessa macchina, all’interno del container localhost indica il container stesso; usa invece host.docker.internal.

Hollama e OrionChat: il lavoro viene svolto dal browser

Hollama pubblica un'applicazione browser da un unico 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 per qualsiasi altro hostname con un errore di host bloccato invece di avviare l'applicazione.

OrionChat va 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 vengono 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 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 e implica un aspetto più facile da trascurare: è il browser a chiamare il modello, non il server.

Questo aspetto determina dove è possibile usare questi due progetti. Il browser deve raggiungere direttamente Ollama, quindi Ollama deve essere in ascolto su un indirizzo diverso dal loopback e non dispone di alcun tipo di autenticazione. Da questo derivano 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.. Una chiamata verso qualsiasi altra origine viene rifiutata con has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource finché non si autorizza quell'origine.

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 solo quando un firewall o un proxy con autenticazione controlla già chi può raggiungere la porta, perché la porta 11434 aperta espone un model server accessibile 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'origine localhost, che Ollama consente per impostazione predefinita, e la porta non lascia mai il server.

È possibile usare un endpoint Ollama o vLLM remoto?

Open WebUI può farlo e la connessione viene stabilita lato server. OLLAMA_BASE_URL=http://model-host:11434 lo indirizza a 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 punti e virgola.

LibreChat può farlo tramite baseURL dell’endpoint personalizzato mostrato sopra. Anche questa richiesta esce dal server, quindi non si applica alcuna regola del browser. Lo stesso URL di base e la stessa chiave segnaposto funzionano anche al di fuori di una finestra di chat: è sufficiente per indirizzare un agente di coding al modello già ospitato.

Hollama e OrionChat possono puntare a qualsiasi endpoint inserito nelle relative impostazioni, ma la richiesta esce dal browser. Tutto ciò che è descritto nella sezione precedente si applica anche a questi strumenti e a nessun altro in questa sezione.

Separare l’interfaccia dal modello è il vantaggio più utile offerto da un endpoint remoto. Puoi installare l’interfaccia su una macchina di piccole dimensioni e il modello sulla macchina che dispone della memoria necessaria. È anche il momento di decidere se usare Ollama o vLLM per gestire le richieste, perché i due strumenti si comportano in modo molto diverso quando più persone utilizzano contemporaneamente il modello. Se il server del modello non è ancora disponibile, inizia eseguendo Ollama su un VPS; su una macchina con sola CPU, leggi come Ollama si confronta con llama.cpp prima di scegliere il runtime.

Non pubblicare mai una UI di chat senza accesso su 0.0.0.0

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

Controlla cosa è in ascolto prima di considerare sicuro qualsiasi componente.

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. Dalla stessa macchina, una risposta curl -sI http://YOUR.VPS.IP:3000 a HTTP/1.1 200 OK indica la stessa cosa in modo ancora più diretto.

Disabilitare l'accesso 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; il messaggio restituito è You can't turn off authentication because there are existing users.

Pattern uno: associarsi al loopback e accedere tramite SSH. Pubblica ogni porta su 127.0.0.1, quindi inoltra quella necessaria: 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 approccio dipende dalla configurazione SSH, quindi abbinalo a SSH con sole chiavi e sshd protetto.

Pattern due: un reverse proxy che autentica la richiesta prima che raggiunga l'applicazione. Mantieni l'applicazione sul loopback, assegna al proxy la gestione della porta 443 e configura il single sign-on davanti all'applicazione. Traefik configurato tramite le label di Docker Compose con Authentik come provider di identità fornisce a ogni applicazione del server un unico accesso e un unico certificato. Con Open WebUI dietro TLS (sicurezza del livello di trasporto), 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: il token resta utilizzabile fino alla scadenza naturale.

Il pattern due non protegge i progetti accessibili 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 trasmette il cookie di sessione. Di conseguenza, il proxy con autenticazione davanti a Ollama risponde con un redirect verso un modulo di accesso e la chat non funziona. Instrada l'endpoint del modello sotto lo stesso hostname della pagina oppure usa il pattern uno.

Quale scegliere

Se lo useranno anche altre persone, esegui Open WebUI. Supporta account reali, inserisce i nuovi utenti in una coda di approvazione e i relativi manutentori pubblicano linee guida per l'hardening che puoi seguire. Se ti servono LDAP o un pannello di amministrazione, esegui LibreChat e verifica con docker stats che i suoi sei servizi, insieme al modello, rientrino nelle risorse disponibili prima di farci affidamento. Se lo utilizza una sola persona su una macchina di piccole dimensioni, dove il modello occupa già gran parte della RAM, pubblica Hollama o OrionChat tramite un tunnel SSH e lascia che sia il browser a mantenere lo stato. Su un VPS, la scelta sbagliata è pubblicare uno qualsiasi di questi servizi su 0.0.0.0 senza un'autenticazione davanti.

FAQ

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

La relativa pagina di hardening lo descrive come software destinato a reti private e affidabili, nella stessa categoria di un database o di un server CI. Dispone comunque di account reali: il primo account diventa amministratore, mentre quelli successivi restano pending fino all'approvazione. È quindi molto più sicuro di un'interfaccia priva di autenticazione. 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 te ne accorga.

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 affatto un container applicativo. Open WebUI mantiene in memoria un processo Python, un database e, per impostazione predefinita, un modello locale per gli embedding. La documentazione indica circa 500 MB per worker soltanto per il modello di embedding. Verifica i valori sul tuo server con docker stats --no-stream, perché cambiano in base alle funzionalità attivate.

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

Open WebUI e LibreChat possono farlo. La connessione viene effettuata dal server, quindi le regole del browser non si applicano. 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 chiave API non vuota. Anche Hollama e OrionChat possono puntare a un host qualsiasi, ma la richiesta proviene dal browser. L'endpoint deve quindi essere raggiungibile anche dal browser.

Perché la mia interfaccia di chat nel browser non riesce a raggiungere Ollama?

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