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 è poco costosa e nessun servizio è in ascolto su un indirizzo pubblico. Un VPS cambia entrambe le condizioni, e questo modifica la graduatoria. 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 disponibile. Il compromesso è l'autenticazione: non ne offrono alcuna.

Tutto ciò che segue proviene dalla documentazione dei singoli progetti, consultata ad agosto 2026, ricontrollata il 20 ottobre 2026 e verificata nuovamente per Open WebUI, LibreChat, Hollama e OrionChat il 25 ottobre 2026. La documentazione di Ollama e le regole di sicurezza del browser sono state ricontrollate il 29 ottobre 2026. I quattro criteri sono quelli che diventano rilevanti solo 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 in termini di risorse 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’unica applicazione in esecuzione sul laptop e non offrono alcun accesso tramite login.
• Inferenza remota. Un’interfaccia a cui viene indicato soltanto 127.0.0.1:11434 presuppone che il modello sia sullo stesso sistema dell’interfaccia. Se il modello si trova altrove, è necessario un tunnel che inoltri quella porta locale all’host del modello.
• 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 di download pubblicate indicano il limite minimo, perché i pesi devono rimanere residenti mentre il modello genera le risposte, e l'uso effettivo 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.4"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

Questi sono i valori riportati dalle pagine della libreria Ollama il 25 October 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 man mano che la conversazione cresce. Per questo il valore di num_ctx che imposti è una scelta legata alla memoria tanto quanto alla qualità. qwen3:8b con 5.2 GB non può essere eseguito su quel server. È una situazione che le raccolte di modelli per laptop non considerano mai. In questo caso, un'interfaccia di chat che occupa alcune centinaia di megabyte può determinare se il modello riesce a funzionare. Se stai dimensionando un server per qualcosa di molto superiore a questi tag, il calcolo per un modello 27B su un VPS con la sola CPU mostra quanto rapidamente l'interfaccia smetta di essere il fattore decisivo.

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à. Una lettura effettuata tra una conversazione e l'altra sottostima quindi il picco. Il messaggio successivo deve ricaricare tutti i pesi, a meno che tu mantenga il modello residente con keep_alive.

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

Open WebUI viene eseguito da una sola immagine e conserva i dati in un solo 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 le proprie regole iptables 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. La registrazione viene quindi disattivata automaticamente finché un amministratore non riattiva New Sign Ups. Le registrazioni successive vengono create con il ruolo pending, il valore predefinito documentato di DEFAULT_USER_ROLE. In questo modo, anche se un estraneo raggiunge la pagina, non può usare il tuo modello finché un amministratore non lo approva.

Open WebUI usa più memoria dei progetti descritti di seguito perché offre più funzionalità. La relativa pagina sulle prestazioni indica quali componenti consumano queste risorse. Il motore di embedding predefinito carica un modello sentence-transformers all'interno del container, con un consumo documentato di circa 500 MB o più per processo worker. Impostando RAG_EMBEDDING_ENGINE=ollama, affidi questo lavoro al model server che stai già eseguendo. AUDIO_STT_ENGINE=webapi evita di caricare un modello locale di speech-to-text. Con SQLite e DATABASE_POOL_SIZE non impostato, il pool usa una dimensione interna elevata. Ogni connessione crea quindi una propria page cache e una propria mappatura di memoria. Su una macchina con risorse limitate, imposta DATABASE_POOL_SIZE=8 e DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. L'autocompletamento, che chiede al modello di generare un completamento mentre l'utente sta ancora digitando, ora viene distribuito disattivato (ENABLE_AUTOCOMPLETE_GENERATION ha come valore predefinito False). Su una macchina con risorse limitate, lascialo disattivato.

LibreChat: multiutente, con uno stack sottostante

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 identità, non una semplice schermata di accesso: documenta gli accessi LDAP e OAuth2 e il file compose predefinito definisce anche un pannello di amministrazione per utenti, gruppi e ruoli. Il pannello non viene avviato automaticamente. Non si avvia finché ADMIN_PANEL_SESSION_SECRET non è impostato in .env. Il valore è obbligatorio, deve contenere almeno 32 caratteri e non ha un valore predefinito. Se necessario, generane uno con openssl rand -hex 32. Il pannello viene eseguito come servizio separato, non all'interno del processo LibreChat, richiede LibreChat v0.8.5 o versioni successive e il progetto lo indica ancora come anteprima. Questa funzionalità viene fornita con 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": 5,
    "notes": "api, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

Il file compose predefinito avvia 5 servizi: api, MongoDB, Meilisearch, pgvector, RAG API. Un sesto servizio, il pannello di amministrazione, si trova nello stesso file e si aggiunge agli altri quando il relativo secret è impostato. Nessuno di questi servizi è il modello. MongoDB e pgvector richiedono entrambi memoria propria e, su un server con 4 GB, questa è memoria che serviva al modello.

Nel file, due servizi pubblicano porte e nessuna delle due mappature specifica un indirizzo bind: l'API sulla porta 3080 e il pannello di amministrazione sulla porta host 3000, il valore predefinito di ADMIN_PANEL_PORT. Di conseguenza, quando vengono avviati, entrambi restano in ascolto su tutte le interfacce. Anche Open WebUI usa la porta 3000, come indicato sopra, quindi su un server condiviso i due servizi entrano in conflitto non appena il pannello viene abilitato. Prima di esporre lo stack a Internet, modifica entrambe le mappature in 127.0.0.1 in docker-compose.override.yml.

Gli aggiornamenti si eseguono con git; è questo il passaggio che spesso viene gestito 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 docker-compose.yml, che è tracciato, e l'aggiornamento rimane applicato solo parzialmente. Inserisci le modifiche in docker-compose.override.yml, che il progetto fornisce a questo scopo, e conserva i secret in .env. Entrambi i file non sono tracciati, quindi git pull li lascia invariati.

Configura LibreChat per usare il tuo server modello specificando 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 del server 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 viene eseguito sulla stessa macchina, localhost all'interno del container indica il container stesso. In questo caso, usa host.docker.internal.

Hollama e OrionChat: il browser esegue il lavoro

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.

OrionChat si spinge oltre e non dispone affatto di un componente server. Clona il repository e pubblica la directory con il web server che già utilizzi, oppure apri index.html dal disco. Le API key vengono archiviate nel localStorage del browser, la cronologia delle chat resta nel browser e l'applicazione elimina le chat più vecchie quando il numero supera 512. L'indirizzo Ollama di OrionChat è fissato nel relativo codice sorgente (js/script.js) su http://localhost:11434 e nelle impostazioni non esiste alcun campo per modificarlo.

Nessuno dei due progetti dispone di un login. 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 qualcosa che è più facile non notare: è il browser a chiamare il modello, non il server.

Questo singolo fatto determina dove è possibile utilizzare queste due applicazioni. Il browser deve poter raggiungere direttamente Ollama. Per OrionChat questo significa sempre localhost:11434 sul computer che esegue il browser. Su un VPS, quindi, il tunnel SSH riportato di seguito è l'unico percorso verso il modello. Hollama accetta qualsiasi indirizzo immesso come URL di base della connessione e la guida per il self-hosting descrive anche l'uso di un server Ollama su un altro dispositivo: aggiungi l'origine di Hollama a OLLAMA_ORIGINS sul lato Ollama. Pertanto, se non inoltri la porta tramite SSH, Ollama deve essere in ascolto su un indirizzo diverso dal loopback. Inoltre, l'API di Ollama non richiede login né key. Da questo derivano due regole del browser. Una pagina pubblicata tramite HTTPS non può chiamare un endpoint HTTP semplice su un indirizzo IP pubblico 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.. Il loopback dispone di un'esenzione separata: la specifica Mixed Content blocca soltanto gli URL che non sono potenzialmente affidabili e la specifica Secure Contexts considera localhost, 127.0.0.0/8 e ::1 potenzialmente affidabili. La stessa pagina HTTPS può quindi chiamare http://localhost:11434 o http://127.0.0.1:11434. È questa l'esenzione su cui si basa il tunnel SSH riportato di seguito. Dalla versione 142, Chrome aggiunge un passaggio quando la pagina proviene da un sito pubblico come https://chat.example.com: una richiesta verso un indirizzo di loopback o della rete locale resta in attesa finché l'utente non consente l'accesso alla rete locale tramite una richiesta di autorizzazione. Chrome esenta inoltre dai controlli dei contenuti misti le richieste HTTP verso endpoint della rete locale soggette ad autorizzazione quando il nome host è un indirizzo IP privato indicato come valore letterale, ad esempio 192.168.0.1, un nome .local, oppure quando il fetch specifica targetAddressSpace: "local". Una pagina aperta su http://localhost tramite il tunnel è già sul loopback, quindi questa richiesta di autorizzazione non si applica. 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 autorizzi tale origine.

Il metodo documentato da Ollama per modificare una delle due 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. Applica 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 server di modelli accessibile e gli scanner automatici raggiungono rapidamente una nuova porta pubblica. Il tunnel SSH riportato di seguito evita completamente il problema: la pagina viene eseguita su un'origine localhost, che Ollama autorizza per impostazione predefinita, e la porta non lascia mai il server.

Ogni client può 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 indica l'endpoint Ollama. Per vLLM, imposta OPENAI_API_BASE_URL=http://model-host:8000/v1 mantenendo /v1, sotto il quale vLLM espone la propria API. Imposta OPENAI_API_KEY solo se il server è stato avviato con una chiave, perché la guida di Open WebUI per vLLM non prevede autenticazione negli altri casi. Per gli altri server compatibili con OpenAI, usa il percorso di base indicato dalla relativa documentazione, che non è sempre /v1. OPENAI_API_BASE_URLS accetta più backend separati da punti e virgola.

LibreChat può farlo tramite baseURL dell'endpoint personalizzato mostrato in precedenza. Anche questa richiesta esce dal server, quindi le regole del browser non si applicano. Lo stesso URL di base e la stessa chiave segnaposto funzionano anche al di fuori di una finestra di chat. È tutto ciò che serve per indirizzare un agente di coding al modello già ospitato.

Hollama può usare qualsiasi endpoint inserito nelle impostazioni. La connessione Ollama dispone di un URL di base modificabile, che per impostazione predefinita è http://localhost:11434. Inoltre, Hollama offre una connessione compatibile con OpenAI, http://localhost:8080/v1 per impostazione predefinita, che consente di usare vLLM. La richiesta esce dal browser, quindi si applica tutto quanto descritto nella sezione precedente. OrionChat non può essere indirizzato a un endpoint diverso. I suoi endpoint sono hardcoded: Ollama è impostato su http://localhost:11434/v1/chat/completions. Il README indica inoltre che le richieste vengono inviate direttamente all'API ufficiale di ciascun provider. Un endpoint Ollama remoto è raggiungibile solo tramite un tunnel SSH che lo fa rispondere su quella porta locale. Non esiste alcuna impostazione per un server vLLM.

Separare l'interfaccia dal modello è il vantaggio principale di un endpoint remoto. Esegui l'interfaccia su un host di dimensioni ridotte e il modello sul server dotato della memoria necessaria. Questo è anche il momento di decidere se usare Ollama o vLLM per gestire le richieste, perché i due componenti si comportano in modo molto diverso quando più persone usano contemporaneamente il modello. Se il server del modello non esiste ancora, inizia eseguendo Ollama su un VPS. Su un host con la sola CPU, leggi il confronto tra Ollama e llama.cpp prima di scegliere il runtime.

Non pubblicare mai un'interfaccia di chat senza autenticazione 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 consiglia di collocarlo dietro una VPN oppure dietro un reverse proxy con autenticazione. Un progetto completamente privo di autenticazione richiede almeno lo stesso trattamento.

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

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

Una riga con 127.0.0.1:3000 è quella corretta. Una riga con 0.0.0.0:3000 significa che il servizio è in ascolto su tutti gli indirizzi e, per impostazione predefinita, Docker consente a qualsiasi indirizzo IP sorgente esterno di raggiungere una porta pubblicata. A meno che una regola nella catena DOCKER-USER di Docker o il firewall del provider non blocchi l'accesso, l'interfaccia di chat è esposta a Internet. Dalla macchina stessa, il fatto che curl -sI http://YOUR.VPS.IP:3000 risponda a HTTP/1.1 200 OK chiarisce la situazione senza ambiguità.

Disattivare l'autenticazione di Open WebUI con WEBUI_AUTH=False è un'impostazione adatta a un singolo utente, su una macchina non raggiungibile da altri. La documentazione specifica inoltre che funziona solo su un'installazione senza utenti registrati, quindi non è possibile applicarla a un'installazione che contiene già account.

Primo schema: associare il servizio all'interfaccia di 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 pubblicata alcuna porta, quindi nessuna porta può essere sottoposta a scansione. Per OrionChat, inoltra la porta del modello nello stesso comando con -L 11434:127.0.0.1:11434 e lascia Ollama in ascolto sulla loopback. Hollama può raggiungere direttamente Ollama, ma lo stesso inoltro mantiene Ollama fuori da Internet, quindi è anche la soluzione più sicura per Hollama. Questo schema è sicuro solo quanto la configurazione SSH, quindi abbinalo a SSH con sole chiavi e sshd protetto.

Secondo schema: un reverse proxy che esegue l'autenticazione prima che la richiesta raggiunga l'applicazione. Mantieni l'applicazione sulla loopback, assegna al proxy la 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à assegna a ogni applicazione del server un'unica autenticazione 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, la disconnessione non invalida il token: il token resta utilizzabile fino alla scadenza naturale.

Il secondo schema non risolve il problema dei progetti accessibili solo 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 accesso e la chat non funziona. Inoltra l'endpoint del modello sotto lo stesso hostname della pagina oppure usa il primo schema.

Quale scegliere

Se lo utilizzerà qualcuno oltre a te, esegui Open WebUI. Offre account reali, inserisce i nuovi utenti in una coda di approvazione e i responsabili del progetto pubblicano linee guida per l'hardening che puoi seguire. Se ti serve LDAP o un pannello di amministrazione, esegui LibreChat, imposta ADMIN_PANEL_SESSION_SECRET se vuoi il pannello e verifica con docker stats che i suoi cinque servizi, sei con il pannello, oltre al modello, rientrino effettivamente nelle risorse disponibili prima di farvi affidamento. Se è una sola persona su una macchina con risorse limitate, dove il modello ha già occupato gran parte della RAM, esponi 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 affidabili, 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 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 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 o più 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 non si applicano i vincoli del browser. Imposta OLLAMA_BASE_URL per Open WebUI oppure baseURL in un endpoint personalizzato per LibreChat. Per vLLM o per un altro server compatibile con OpenAI, usa OPENAI_API_BASE_URL con il percorso di base indicato nella documentazione del server. Per vLLM il valore è /v1. Aggiungi una API key soltanto se il server la richiede. Anche Hollama può puntare a un host qualsiasi, ma la richiesta proviene dal browser. L'endpoint deve quindi essere raggiungibile anche dal browser. OrionChat non può farlo: l'indirizzo Ollama è codificato in http://localhost:11434. Un server Ollama remoto funziona quindi soltanto tramite un tunnel SSH che inoltri quella porta.

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

Nella quasi totalità dei casi le cause sono due. Per impostazione predefinita Ollama è in ascolto su 127.0.0.1:11434, quindi un browser su un altro computer non può raggiungerlo direttamente finché OLLAMA_HOST non viene modificata oppure la porta non viene inoltrata tramite un tunnel SSH. Inoltre, per impostazione predefinita Ollama accetta richieste cross-origin da localhost, 127.0.0.1 e 0.0.0.0. Una pagina pubblicata dal tuo dominio viene quindi rifiutata con No 'Access-Control-Allow-Origin' header is present on the requested resource finché quell'origine non viene inserita in OLLAMA_ORIGINS. Se la pagina usa HTTPS e l'endpoint usa HTTP non cifrato su un indirizzo IP pubblico, il browser blocca la richiesta come mixed content prima che Ollama possa riceverla. Gli indirizzi di loopback (localhost, qualsiasi indirizzo in 127.0.0.0/8 come 127.0.0.2 oppure [::1]) sono esclusi. Chrome esclude inoltre le richieste HTTP alla rete locale che usano indirizzi IP privati letterali come 192.168.0.1, hostname .local o targetAddressSpace: "local", dopo la concessione dell'autorizzazione per la rete locale. I requisiti CORS di Ollama restano comunque applicabili. Imposta entrambe le variabili in un override systemctl edit ollama.service oppure inoltra la porta tramite SSH: il problema viene così eliminato.