Installare Ollama e Open WebUI su Windows Server 2025 per creare un chatbot locale
L’utilizzo di un chatbot basato sull’intelligenza artificiale all’interno della propria infrastruttura può essere utile in diversi scenari: dalla preparazione di testi alla scrittura di script, fino al supporto nelle attività quotidiane degli amministratori di sistema. Prima di pensare all’integrazione con i servizi aziendali, però, è necessario predisporre un ambiente in cui eseguire il modello e verificare quali risorse richieda.
In questa guida vedremo come installare Ollama su Windows Server 2025 e affiancargli Open WebUI, un’interfaccia web che permette di utilizzare il chatbot direttamente dal browser. Eseguiremo l’installazione sul sistema operativo, senza utilizzare Docker o Windows Subsystem for Linux (WSL), sfruttando WinGet per semplificare l’installazione dei componenti.
Ollama è il componente che si occupa di caricare ed eseguire i modelli linguistici, mentre Open WebUI mette a disposizione l’ambiente di conversazione. I due progetti sono indipendenti: potete utilizzare Ollama anche dalla riga di comando o attraverso le sue API e aggiungere successivamente l’interfaccia web.
Con un modello eseguito localmente, l’elaborazione delle richieste avviene sul server, senza doverle inviare a un servizio di inferenza cloud. Questo aspetto è utile quando volete mantenere il controllo sui dati elaborati, ma comporta anche la necessità di dimensionare correttamente la macchina: RAM, CPU ed eventuale GPU influenzano la scelta del modello e i tempi di risposta.
Preparazione dell’ambiente e prerequisiti
Per seguire la guida utilizzeremo una macchina con Windows Server 2025 con Desktop Experience, in modo da poter gestire l’installazione e accedere all’interfaccia del chatbot dal browser del server. Potete utilizzare un server fisico oppure una macchina virtuale: per le prime prove è sufficiente anche un ambiente di laboratorio.
Il primo aspetto da valutare è la memoria disponibile. Le risorse necessarie dipendono dal modello linguistico che sceglierete, dalla lunghezza delle conversazioni e dal numero di richieste contemporanee. Per il laboratorio descritto nella guida potete partire da una macchina virtuale con 4 vCPU, 32 GB di RAM e storage SSD, lasciando almeno 30 GB di spazio libero per i componenti e i primi modelli. Si tratta di un dimensionamento iniziale per le prove, da verificare in base al carico effettivo.
Una GPU compatibile con Ollama può ridurre sensibilmente i tempi di risposta, ma non è indispensabile per iniziare. Potete eseguire il modello anche utilizzando la CPU, tenendo presente che la generazione delle risposte potrebbe essere lenta. Se utilizzate una macchina virtuale, la presenza di una GPU nell’host non significa che questa sia automaticamente disponibile nel sistema operativo guest.
È inoltre necessaria una connessione a Internet per scaricare il software, le dipendenze Python e il modello linguistico. Una volta completati questi passaggi, le conversazioni con il modello locale non richiederanno un servizio di inferenza cloud.
Installazione di Ollama con WinGet
Dopo aver verificato i prerequisiti, possiamo procedere con l’installazione di Ollama. Dalla finestra di PowerShell eseguite:
|
1 2 |
winget install --id Ollama.Ollama |
WinGet individuerà il pacchetto e avvierà il programma di installazione. Seguite le indicazioni visualizzate e attendete il completamento della procedura.

Figura 1: Installazione di Ollama su Windows Server 2025 tramite WinGet

Figura 2: Schermata di benvenuto di Ollama al termine dell’installazione
Alla richiesta di creare un account, fate clic su No thanks, I’ll use Ollama locally per proseguire con l’utilizzo locale di Ollama senza registrarvi.

Figura 3: Scelta dell’utilizzo locale di Ollama senza creare un account
Al termine, chiudete e riaprite PowerShell, in modo che la nuova sessione possa utilizzare il percorso aggiunto alla variabile d’ambiente PATH. Verificate quindi che il comando sia disponibile:
|
1 2 |
ollama --version |
Se viene restituita la versione installata, potete passare alla verifica del motore di esecuzione.
Ollama espone le proprie API sulla porta TCP 11434, utilizzando per impostazione predefinita l’indirizzo di loopback. Per controllare che risponda, eseguite:
|
1 2 |
Invoke-RestMethod -Uri "http://localhost:11434/api/version" |
Il comando deve restituire la versione del server Ollama. Questa verifica ci permette di controllare che il componente sia effettivamente in esecuzione, oltre a essere installato.

Figura 4: Verifica della versione di Ollama e della risposta delle API locali tramite PowerShell
Se ricevete un errore di connessione, avviate Ollama dal menu Start e ripetete il comando. In alternativa, potete avviare il motore direttamente da PowerShell: ollama serve
In questo caso lasciate aperta la finestra, perché il processo viene eseguito in primo piano, e utilizzate una seconda sessione di PowerShell per le verifiche successive. Se compare un errore che indica che la porta è già occupata, controllate nuovamente l’endpoint: potrebbe essere già attiva un’altra istanza di Ollama.
È utile chiarire un aspetto prima di proseguire: l’installazione standard di Ollama per Windows non equivale alla configurazione di un servizio Windows con avvio automatico indipendente dall’accesso dell’utente. Per il nostro laboratorio utilizzeremo l’esecuzione nella sessione corrente; l’avvio automatico sarà affrontato separatamente.
A questo punto il motore è disponibile, ma dobbiamo ancora scaricare un modello linguistico. Potete verificare quelli presenti con: ollama list
Su una nuova installazione l’elenco sarà vuoto.
Download del modello linguistico e prima conversazione
Ora che Ollama è installato e risponde alle richieste, possiamo scaricare il modello linguistico da utilizzare nel nostro laboratorio. Per questa guida ho scelto Qwen3.5 nella variante da 4 miliardi di parametri, disponibile nel catalogo di Ollama con il nome qwen3.5:4b.
La scelta del modello deve tenere conto delle risorse disponibili. Nel nostro caso vogliamo utilizzare una macchina virtuale con 32 GB di RAM, senza richiedere una GPU dedicata. Un modello di dimensioni contenute è un punto di partenza pratico per verificare il funzionamento del chatbot e valutare i tempi di risposta sulla CPU.
Ho scelto Qwen3.5:4b per il suo orientamento multilingue e per le dimensioni contenute, che permettono di iniziare le prove lasciando risorse disponibili per Windows Server e Open WebUI. Il pacchetto indicato nel catalogo occupa circa 3,3–4 GB su disco, a seconda della variante distribuita. Il supporto multilingue è un elemento utile per il nostro scenario, ma la qualità delle risposte in italiano andrà verificata con richieste rappresentative dell’utilizzo previsto.
È importante distinguere lo spazio occupato su disco dalla memoria necessaria durante l’esecuzione. Il consumo di RAM dipende anche dalla lunghezza del contesto e dalle richieste contemporanee. Inoltre, avere memoria sufficiente per caricare un modello non significa necessariamente ottenere risposte rapide: su una macchina senza GPU, le prestazioni della CPU rimangono determinanti.
Dalla finestra di PowerShell eseguite il comando seguente:
|
1 2 |
ollama pull qwen3.5:4b |
Ollama scaricherà le componenti del modello mostrando lo stato di avanzamento. Attendete il completamento del download prima di procedere.
Notate che abbiamo specificato anche il suffisso :4b: in questo modo scegliamo esplicitamente la dimensione del modello utilizzato nella guida, anziché affidarci alla variante predefinita.
Al termine, verificate che il modello sia presente:
|
1 2 |
ollama list |
Nell’output troverete il nome del modello, l’identificativo, le dimensioni e la data dell’ultima modifica.

Figura 5: Download completato del modello Qwen3.5:4b e verifica della sua presenza con il comando ollama list
Avvio della prima conversazione
Possiamo quindi avviare la prima conversazione:
|
1 2 |
ollama run qwen3.5:4b |
Il caricamento iniziale può richiedere qualche istante, soprattutto se il modello viene eseguito utilizzando soltanto la CPU. Quando compare il prompt della conversazione, inserite una domanda semplice:
Spiegami in italiano la differenza tra un server membro e un Domain Controller in un dominio Active Directory. Mantieni la risposta entro 200 parole.
Questa prova permette di osservare la chiarezza dell’esposizione, il rispetto delle istruzioni e la correttezza dei contenuti tecnici. Una risposta plausibile non è necessariamente corretta: prima di utilizzare procedure o comandi generati dal chatbot, verificateli nel vostro ambiente di laboratorio.

Figura 6: Risposta di Qwen3.5:4b alla richiesta di spiegare la differenza tra un server membro e un Domain Controller
Per terminare la conversazione e tornare a PowerShell, digitate /bye
Durante le prove potete aprire una seconda finestra di PowerShell ed eseguire:
|
1 2 |
ollama ps |
La colonna PROCESSOR indica se il modello è caricato sulla CPU, sulla GPU oppure distribuito tra entrambe. Se la macchina virtuale non dispone di una GPU compatibile accessibile dal sistema operativo guest, è normale vedere l’utilizzo della sola CPU.

Figura 7: Verifica con ollama ps del caricamento di Qwen3.5:4b distribuito tra CPU e GPU
Installazione di Open WebUI
Dopo aver verificato il funzionamento del modello dalla riga di comando, possiamo aggiungere Open WebUI, l’interfaccia che ci permetterà di gestire le conversazioni dal browser. Utilizzeremo un ambiente Python dedicato, mantenendo separate le dipendenze dell’applicazione.
Per prepararlo installeremo Miniconda tramite WinGet. Aprite PowerShell ed eseguite:
|
1 2 |
winget install --id Anaconda.Miniconda3 |

Figura 8: Installazione completata di Miniconda tramite WinGet su Windows Server 2025
Attendete il completamento dell’installazione, quindi aprite dal menu Start Anaconda Prompt, installato con Miniconda. I comandi riportati di seguito devono essere eseguiti in questo prompt, che utilizza la sintassi di cmd.exe.
Verificate che Conda sia disponibile:
|
1 2 |
conda –version |

Figura 9: Apertura di Anaconda Prompt dal menu Start e verifica della versione di Conda
Accettazione delle condizioni dei repository Anaconda
Dopo aver verificato la versione di Conda, è necessario esaminare e accettare le condizioni di utilizzo dei repository Anaconda prima di procedere con la creazione dell’ambiente Python. Potete consultarle eseguendo:
|
1 2 |
conda tos view |
Se intendete accettarle, eseguite i seguenti comandi da Anaconda Prompt:
|
1 2 3 4 5 6 |
conda tos accept --override-channels --channel https://repo.anaconda.com/pkgs/main conda tos accept --override-channels --channel https://repo.anaconda.com/pkgs/r conda tos accept --override-channels --channel https://repo.anaconda.com/pkgs/msys2 |

Figura 10: Consultazione e accettazione delle condizioni di utilizzo dei repository Anaconda tramite Anaconda Prompt
Completata l’accettazione, possiamo procedere con la creazione dell’ambiente dedicato a Open WebUI.
Preparazione dell’ambiente openwebui
Create quindi un ambiente chiamato openwebui, specificando la versione di Python:
|
1 2 |
conda create --name openwebui python=3.12 -y |

Figura 11: Creazione dell’ambiente Conda openwebui dedicato all’installazione di Open WebUI
Al termine, attivate l’ambiente:
|
1 2 |
conda activate openwebui |
La presenza di (openwebui) all’inizio del prompt indica che l’ambiente è attivo. I pacchetti installati nei prossimi passaggi saranno associati a questo ambiente.
Per Open WebUI utilizzeremo Python 3.12, una delle versioni indicate nella documentazione del progetto. Aggiornate pip e installate l’applicazione:
|
1 2 3 4 |
python -m pip install --upgrade pip python -m pip install open-webui |
Il download delle dipendenze può richiedere diversi minuti: attendete che venga restituito il prompt e verificate che l’installazione termini senza errori.

Figura 12: Aggiornamento di pip e installazione di Open WebUI con le relative dipendenze nell’ambiente Conda dedicato

Figura 13: Installazione completata di Open WebUI e delle relative dipendenze nell’ambiente Conda openwebui
Prima dell’avvio, predisponete una cartella per i dati e una directory di lavoro stabile:
|
1 2 3 4 |
mkdir "%LOCALAPPDATA%\OpenWebUI\data" cd /d "%LOCALAPPDATA%\OpenWebUI" |
Impostate quindi il percorso dei dati e l’indirizzo dell’istanza locale di Ollama:
|
1 2 3 4 |
set "DATA_DIR=%LOCALAPPDATA%\OpenWebUI\data" set "OLLAMA_BASE_URL=http://127.0.0.1:11434" |
La cartella dei dati conserverà gli utenti, le conversazioni e le impostazioni dell’applicazione. Le variabili impostate con set valgono per la sessione corrente: dovrete reimpostarle quando aprirete un nuovo prompt per avviare Open WebUI.

Figura 14: Preparazione della cartella dei dati di Open WebUI e configurazione del collegamento all’istanza locale di Ollama
Assicuratevi che Ollama sia ancora in esecuzione, quindi avviate l’interfaccia:
|
1 2 |
open-webui serve --host 127.0.0.1 --port 8080 |
Lasciate aperta la finestra del prompt, perché ospita il processo dell’applicazione. Il primo avvio può richiedere tempo per l’inizializzazione e per eventuali download aggiuntivi.

Figura 15: Primo avvio di Open WebUI con inizializzazione del database e configurazione dell’ascolto locale sulla porta 8080
Aprite Microsoft Edge sul server e raggiungete l’indirizzo http://127.0.0.1:8080
Abbiamo limitato l’ascolto all’indirizzo di loopback, così da utilizzare l’interfaccia soltanto dal server durante questa prima configurazione.
Al primo accesso comparirà la procedura per creare l’account amministratore di Open WebUI. Questo account è distinto sia dall’account Windows sia da un eventuale account Ollama.

Figura 16: Schermata di benvenuto di Open WebUI raggiungibile dal browser all’indirizzo locale 127.0.0.1:8080
Configurazione iniziale e prima conversazione dal browser
Dalla schermata di benvenuto di Open WebUI fate clic su Get started per avviare la configurazione iniziale. Vi verrà chiesto di inserire nome, indirizzo e-mail e password per creare il primo account, che avrà il ruolo di amministratore dell’applicazione.
Questo account viene gestito da Open WebUI ed è indipendente dall’account Windows utilizzato sul server. Inserire un indirizzo e-mail aziendale non abilita automaticamente l’integrazione con Active Directory.

Figura 17: Creazione del primo account amministratore di Open WebUI con nome, indirizzo e-mail e password
Completata la creazione dell’account, accederete all’interfaccia della chat. Aprite il selettore dei modelli e scegliete qwen3.5:4b, che abbiamo già scaricato tramite Ollama. Non è necessario scaricare nuovamente il modello: Open WebUI utilizza l’istanza di Ollama configurata nei passaggi precedenti.

Figura 18: Selezione del modello locale Qwen3.5:4b nell’interfaccia di chat di Open WebUI
Una volta selezionato il modello, create una nuova conversazione e inserite la stessa domanda utilizzata nella prova dalla riga di comando:
Spiegami in italiano la differenza tra un server membro e un Domain Controller in un dominio Active Directory. Mantieni la risposta entro 200 parole.
La comparsa della risposta conferma il funzionamento dell’intera configurazione: il browser comunica con Open WebUI, che inoltra la richiesta a Ollama per l’elaborazione tramite il modello locale.
A seconda delle impostazioni del modello e dell’interfaccia, potreste vedere anche una sezione dedicata al ragionamento, prima della risposta finale. Per valutare il risultato considerate soprattutto la correttezza delle informazioni, la chiarezza del testo e il tempo necessario a completare la risposta.

Figura 19: Prima conversazione con Qwen3.5:4b tramite Open WebUI sulla differenza tra server membro e Domain Controller
Per continuare a utilizzare il chatbot devono rimanere in esecuzione sia Ollama sia Open WebUI. Chiudere la scheda del browser non arresta l’applicazione; chiudere il prompt che ospita Open WebUI, invece, ne interrompe l’esecuzione. In questa configurazione l’interfaccia è accessibile soltanto dal server, tramite http://127.0.0.1:8080.
Arrestare e riavviare Open WebUI
Completate le prove, potete arrestare Open WebUI tornando alla finestra di Anaconda Prompt dalla quale avete avviato l’applicazione e premendo Ctrl+C. Attendete che la procedura di arresto termini e venga restituito il prompt.
Le conversazioni e gli account rimangono salvati nella cartella dei dati: l’arresto dell’applicazione non li elimina.
Per avviare nuovamente l’interfaccia, aprite Anaconda Prompt con lo stesso account Windows utilizzato durante l’installazione ed eseguite:
|
1 2 3 4 5 6 7 8 9 10 |
conda activate openwebui cd /d "%LOCALAPPDATA%\OpenWebUI" set "DATA_DIR=%LOCALAPPDATA%\OpenWebUI\data" set "OLLAMA_BASE_URL=http://127.0.0.1:11434" open-webui serve --host 127.0.0.1 --port 8080 |
È necessario ripetere l’impostazione delle variabili perché i comandi set hanno effetto soltanto nella sessione corrente. Non dovete reinstallare Open WebUI, ricreare l’ambiente Conda o scaricare nuovamente il modello.

Figura 20: Riavvio manuale di Open WebUI da Anaconda Prompt con ripristino delle variabili d’ambiente e ascolto locale sulla porta 8080
Verificate inoltre che Ollama sia in esecuzione, avviandolo dal menu Start se necessario. Quando Open WebUI ha completato l’avvio, aprite il browser all’indirizzo http://127.0.0.1:8080
Accedete con l’account creato in precedenza e controllate che la cronologia delle conversazioni sia disponibile.
Conservazione dei dati del laboratorio
Nella configurazione utilizzata nella guida, i dati di Open WebUI sono contenuti nella cartella %LOCALAPPDATA%\OpenWebUI\data
Nella directory di lavoro viene inoltre conservato il file .webui_secret_key, generato al primo avvio e utilizzato per la firma delle sessioni. Mantenete stabile la directory di lavoro, come previsto nei comandi di avvio, per riutilizzare la stessa chiave.
Per conservare una copia del laboratorio, arrestate Open WebUI ed effettuate un backup dell’intera cartella %LOCALAPPDATA%\OpenWebUI, includendo il file della chiave. La cartella contiene informazioni da proteggere, comprese le conversazioni e la configurazione dell’applicazione.
I modelli scaricati da Ollama sono gestiti separatamente: la cartella dei dati di Open WebUI non contiene il modello Qwen3.5:4b.

Figura 21: Contenuto della cartella dati di Open WebUI con il database, la cache, i file caricati e il database vettoriale
Aggiungere un modello OpenAI: gpt-oss
Oltre a Qwen3.5, possiamo utilizzare gpt-oss, la famiglia di modelli open-weight di OpenAI eseguibili localmente con Ollama. Per il nostro laboratorio proveremo gpt-oss:20b, il cui download occupa circa 14 GB.
Da una finestra di PowerShell eseguite:
|
1 2 |
ollama pull gpt-oss:20b |

Figura 22: Download completato del modello OpenAI gpt-oss:20b tramite Ollama
Attendete il completamento del download, quindi avviate una prima conversazione:
|
1 2 |
ollama run gpt-oss:20b |
Potete riproporre la domanda sulla differenza tra un server membro e un Domain Controller, confrontando la risposta con quella ottenuta da Qwen3.5:4b. Valutate sia la correttezza dei contenuti sia i tempi di elaborazione: sulla macchina del laboratorio il comportamento dipenderà dalla memoria disponibile e dalla distribuzione del modello tra CPU e GPU.

Figura 23: Prima conversazione con il modello OpenAI gpt-oss:20b dalla riga di comando di Ollama
Il download da 14 GB non corrisponde al consumo complessivo di memoria durante l’esecuzione. Sulla configurazione con 32 GB di RAM conviene iniziare con una sola conversazione e un contesto contenuto, controllando le risorse utilizzate.
Per terminare la prova digitate /bye. Tornate quindi in Open WebUI, aggiornate la pagina e selezionate gpt-oss:20b dal selettore dei modelli.
Questa configurazione esegue il modello sul vostro server e non richiede una chiave API OpenAI. Utilizzate il nome gpt-oss:20b, senza il suffisso -cloud, per scaricare ed eseguire la variante locale.
Utilizzare gpt-oss:20b da Open WebUI
Dopo aver verificato il funzionamento di gpt-oss:20b dalla riga di comando, tornate nel browser e aggiornate la pagina di Open WebUI. Aprite una nuova conversazione e, dal selettore dei modelli, scegliete gpt-oss:20b.
Non è necessario modificare la connessione a Ollama: entrambi i modelli sono gestiti dalla stessa istanza locale. Open WebUI permette di scegliere quale utilizzare per la conversazione, senza dover predisporre un’interfaccia separata.

Figura 24: Selezione del modello OpenAI gpt-oss:20b in Open WebUI, disponibile insieme a Qwen3.5:4b
Inserite la stessa richiesta utilizzata nelle prove precedenti:
Spiegami in italiano la differenza tra un server membro e un Domain Controller in un dominio Active Directory. Mantieni la risposta entro 200 parole.
Utilizzare la stessa domanda in due nuove conversazioni, una per ciascun modello, permette di confrontare le risposte senza introdurre il contesto dei messaggi precedenti. Osservate la precisione delle spiegazioni, il rispetto del limite di parole e il tempo necessario per completare la risposta.
Per controllare le risorse utilizzate, aprite PowerShell durante la generazione ed eseguite:
|
1 2 |
ollama ps |
Il comando mostra i modelli attualmente caricati e la distribuzione tra CPU e GPU. Potete affiancare questa verifica a Gestione attività, osservando il consumo di memoria e l’utilizzo dei processori durante la richiesta.

Figura 25: Esecuzione di gpt-oss:20b da Open WebUI sulla sola CPU e verifica delle risorse con ollama ps e Gestione attività
Il modello più grande non è automaticamente quello più adatto al vostro scenario. Se le risposte di Qwen3.5:4b sono sufficientemente precise e arrivano in tempi più brevi, può essere la scelta pratica per le richieste quotidiane. Potrete invece utilizzare gpt-oss:20b per le attività nelle quali riscontrate un vantaggio concreto nelle vostre prove.
Conclusioni
In questa guida abbiamo installato Ollama e Open WebUI su Windows Server 2025, utilizzando WinGet per l’installazione dei componenti e un ambiente Conda dedicato per l’interfaccia web. Abbiamo quindi scaricato Qwen3.5:4b e gpt-oss:20b verificato l’esecuzione dalla riga di comando e completato una conversazione dal browser.
Il laboratorio permette di valutare qualità delle risposte, consumo di risorse e tempi di elaborazione con richieste vicine alle vostre attività quotidiane. Queste prove sono utili per capire se il modello scelto è adeguato e se conviene destinare ulteriori risorse al server.
L’interfaccia è attualmente accessibile soltanto dal server e l’avvio delle applicazioni è manuale. Per renderla disponibile ad altri utenti sarà necessario affrontare l’accesso dalla rete, la protezione delle connessioni e l’avvio automatico. L’integrazione con Active Directory e documenti aziendali richiederà inoltre una configurazione specifica delle identità e delle autorizzazioni sui contenuti.