DanpLab AI Workspace: Open WebUI, Ollama e Pipelines in un ambiente self-hosted

2026-06-11T22:05:00.000Z

Architettura DanpLab AI Workspace

Perché costruire un workspace AI self-hosted

Usare l'AI nel lavoro operativo non significa soltanto aprire una chat e scrivere prompt. Per un laboratorio tecnico serve un ambiente dove interfaccia, modelli, pipeline, automazioni e monitoraggio siano separati e verificabili.

Il progetto DanpLab AI Workspace nasce con questo obiettivo: creare un punto di accesso unico per sperimentare modelli locali, servizi AI esterni quando servono, pipeline personalizzate e integrazioni operative, mantenendo una distinzione chiara tra ciò che resta nell'infrastruttura e ciò che può uscire verso provider cloud.

La scelta non è ideologica. Alcuni carichi hanno senso in locale, altri richiedono modelli remoti più capaci. La parte importante è sapere quale percorso sta usando ogni richiesta.


Componenti principali

L'architettura è volutamente modulare.

Utente autorizzato
  ↓
Open WebUI
  ↓
┌─────────────────────┬──────────────────────┐
│ Ollama              │ Pipelines            │
│ Modelli e runtime   │ Tool, API, workflow  │
└─────────────────────┴──────────────────────┘
  ↓
Monitoraggio: Prometheus, Grafana, metriche GPU

Open WebUI

Open WebUI è il front-end conversazionale. Gestisce login, sessioni, chat, modelli disponibili e configurazioni utente. Nel progetto DanpLab è stato personalizzato con un'interfaccia di accesso più coerente con l'identità del laboratorio: scura, sobria, tecnica e senza elementi visivi generici.

Ollama

Ollama è il backend usato per eseguire e servire modelli LLM. Può lavorare con modelli locali oppure fare da punto di integrazione per runtime compatibili. In un homelab è utile perché permette di testare rapidamente modelli diversi senza legare l'intero flusso a un singolo vendor.

Pipelines

Pipelines è il livello più interessante per trasformare una chat in un ambiente operativo. Non è il modello AI: è un middleware estendibile.

Può essere usato per:

  • creare flussi custom prima o dopo la chiamata al modello;
  • collegare script, API o servizi interni;
  • applicare logica di routing tra modelli o strumenti;
  • preparare esperimenti RAG o workflow con documenti;
  • esporre funzioni riutilizzabili da Open WebUI;
  • separare l'interfaccia utente dalla logica operativa.

In pratica, Open WebUI è la porta d'ingresso, Ollama è uno dei motori, Pipelines è lo strato che permette di costruire comportamento su misura.


Monitoraggio e verifiche

Un workspace AI serio non dovrebbe essere una scatola nera. Il progetto include monitoraggio con metriche di sistema e GPU, così è possibile capire quando un modello sta usando davvero accelerazione hardware, quanta memoria viene occupata e se un servizio è sano.

Questo punto è fondamentale: non basta dire "usa la GPU". Va verificato con metriche, log e stato dei container.


Privacy: cosa resta locale e cosa no

La parte delicata è la privacy. Un ambiente self-hosted migliora il controllo, ma non rende automaticamente tutto locale.

La regola corretta è:

i dati restano locali solo quando il modello e la pipeline selezionati lavorano interamente dentro l'infrastruttura.

Se una richiesta usa un provider esterno, il contenuto necessario alla risposta può uscire verso quel provider. Per questo il workspace deve rendere chiara la differenza tra modelli locali, modelli cloud e automazioni che chiamano API esterne.

Nel progetto pubblico non vengono esposti indirizzi interni, porte, chiavi, path reali, screenshot con contenuti privati o configurazioni sensibili. La Lab Note descrive il pattern architetturale, non la mappa dettagliata dell'infrastruttura.


Backup e rollback prima delle modifiche

Una lezione pratica: prima di cambiare container, compose o branding di un servizio usato davvero, serve un rollback.

Nel caso di questo workspace sono stati usati tre livelli:

  1. snapshot della macchina virtuale prima degli interventi più invasivi;
  2. backup dei file Compose e degli inspect/log dei container;
  3. backup dei volumi applicativi principali prima di ricreare i servizi.

Questa disciplina sembra lenta, ma evita di trasformare una modifica estetica o un aggiornamento in un fermo servizio non pianificato.


Personalizzazione dell'interfaccia

La login page è stata trasformata in una schermata DanpLab: titolo chiaro, card centrale, colori coerenti, nota privacy e un messaggio che comunica subito il perimetro d'uso.

Non è una modifica buttata dentro al container a mano. È montata come asset separato, in modo da poterla rimuovere o versionare senza perdere il controllo al prossimo aggiornamento dell'immagine.

Questo è il punto: anche una personalizzazione visiva dovrebbe essere trattata come infrastruttura, non come decorazione fragile.


Cosa rende utile questo progetto

Il valore non è avere una chat privata in più. Il valore è avere una base su cui costruire:

  • assistenti specializzati per documentazione tecnica;
  • workflow collegati ad automazioni esistenti;
  • test comparativi tra modelli locali e cloud;
  • analisi di log, file e procedure operative;
  • esperimenti RAG senza esporre inutilmente dati;
  • interfacce più semplici per strumenti complessi.

Per un SysAdmin, questo cambia il modo di sperimentare con l'AI: non solo prompt, ma architettura, controllo, misurazione e rollback.


Checklist riutilizzabile

Prima di portare un workspace AI in uso reale, controllerei sempre questi punti:

  • autenticazione attiva e account autorizzati;
  • distinzione chiara tra modelli locali e provider esterni;
  • backup dei volumi applicativi;
  • Compose versionato o comunque archiviato;
  • healthcheck dei servizi principali;
  • monitoraggio GPU e risorse;
  • log consultabili senza esporre contenuti privati;
  • interfaccia coerente con il contesto d'uso;
  • documentazione pubblica sanitizzata.

Conclusione

DanpLab AI Workspace è un tassello del laboratorio: un ambiente dove sperimentare AI operativa con più controllo rispetto a una semplice web app cloud.

La direzione è chiara: usare modelli locali quando ha senso, integrare provider esterni quando portano valore, e tenere sempre visibile il confine tra interfaccia, modello, pipeline e automazioni.

L'AI utile, per me, non è quella che risponde in modo brillante una volta. È quella che entra in un processo verificabile, con strumenti, limiti, metriche e rollback.