Alternative a Open WebUI: licenza, BYOK, RAG e migrazione

La maggior parte delle ricerche sulle alternative a Open WebUI non riguarda davvero il prezzo: Open WebUI è gratuito da ospitare autonomamente per un numero illimitato di utenti interni e il progetto non pubblica alcun prezzo. I motivi per cui le persone se ne vanno sono più specifici: la licenza ha smesso di essere open source standard alla v0.6.6, un server è la forma sbagliata per una sola persona, la gestione degli endpoint personalizzati non è adatta al loro gateway oppure vogliono che sia qualcun altro a ospitarlo. Ognuno di questi motivi indica una sostituzione diversa e il costo della migrazione tra le varie opzioni è molto diverso.

Prima una precisazione, perché i risultati di ricerca mescolano diversi progetti omonimi ma non correlati. Open WebUI è open-webui/open-webui, precedentemente Ollama WebUI. Non è la web UI Stable Diffusion di AUTOMATIC1111, non è OpenUI (genera una UI da un prompt) e non è text-generation-webui, che è stato rinominato TextGen in oobabooga/textgen ed è un’app desktop per modelli locali, non un frontend per team.

Inizia dal motivo per cui te ne vai

La licenza, esattamente — e il mito che bisogna smettere di ripetere

L'evento determinante nel ciclo di vita non è una ridenominazione né un'acquisizione. È un cambiamento di licenza. Secondo la documentazione sulla licenza del progetto, tutto il codice inviato o integrato fino alla release v0.6.5 inclusa rimane soggetto alla licenza BSD-3. Dalla v0.6.6 il progetto viene distribuito con la Open WebUI License, una derivata della BSD-3 con una clausola di protezione del marchio, e l'API del repository di GitHub indica la licenza come NOASSERTION anziché come una licenza standard riconosciuta. Le release di GitHub datano il confine: v0.6.5 il 14 aprile 2025 e v0.6.6 il 5 maggio 2025. Tieni presente che la documentazione della licenza associa al cambiamento una propria data di calendario — "Effective with v0.6.6 (April 19, 2025)" — che non coincide con la data registrata da GitHub per quella release; cita quindi la versione anziché una delle due date.

E ora la correzione. Il testo della licenza vieta di alterare, rimuovere, oscurare o sostituire il branding di Open WebUI, salvo in tre circostanze; la prima è una distribuzione "where the total number of end users … does not exceed fifty (50) within any rolling thirty (30) day period"; le altre due sono l'autorizzazione scritta preventiva del titolare del copyright e una licenza enterprise debitamente sottoscritta. La documentazione della licenza elenca separatamente "Deploy to any number of internal users within your own organization (with all official branding kept)" tra le attività consentite dalla licenza gratuita. Quindi la cifra di cinquanta utenti è un'eccezione relativa al branding, non un limite alla distribuzione — l'opposto di quanto afferma la maggior parte degli articoli comparativi. Il copyright è detenuto da Open WebUI Inc. [Created by Timothy Jaeryang Baek].

Ciò che la licenza enterprise limita effettivamente è il white-labeling, la rimozione del branding e le funzionalità riservate all'enterprise. Il prezzo non è pubblicato: la pagina enterprise chiede di "Send us your deployment end user count (seats)", e openwebui.com/pricing restituiva HTTP 404 quando è stata controllata il 21 settembre 2026. Qualsiasi cifra per postazione visibile altrove è il prezzo di un fornitore di hosting gestito oppure è inventata.

Il progetto in sé è in buona salute secondo i numeri che contano: non è archiviato, ha più di 150.000 stelle, ha ricevuto push fino a pochi giorni prima di questo controllo e la release stabile v0.11.3 è stata pubblicata il 31 agosto 2026 (API delle release). Un sottocomponente, invece, non lo è: open-webui/pipelines, il framework per i plugin, ha ricevuto l'ultimo push il 18 agosto 2025. Se la tua distribuzione dipende da Pipelines, vale la pena considerare questa cadenza prima di costruirci sopra ulteriormente.

La rosa ristretta, raggruppata in base al modo in cui lo esegui

Tre precisazioni su quella tabella, tutte verificate il 21 settembre 2026. Il tag più recente di LibreChat è la prerelease v0.8.8-rc3 del 15 settembre 2026 e /releases/latest di GitHub restituisce 404; quindi al momento nessuna release è indicata come ultima — consulta il changelog del progetto prima di fissare una versione, invece di fidarti di un numero riportato in un riepilogo. La pagina dei prezzi di LobeHub è incoerente: le schede dei piani mostrano Starter, Premium e Ultimate a $9,9, $19,9 e $39,9 al mese, mentre la tabella comparativa nella stessa pagina mostra $12,9 per Starter insieme a una cifra annuale di $118,8; verifica quindi l'importo al checkout prima di impegnarti. Inoltre, il prezzo Premium di TypingMind è soggetto a una promozione pubblicizzata del 50%, il tipo di cifra che invecchia più rapidamente. I livelli a pagamento di Chatbox sono destinati ai suoi modelli ospitati; secondo la sua guida per l'uso della propria chiave, collegarlo alla tua chiave è il percorso gratuito.

Due progetti che compaiono negli elenchi delle alternative e non dovrebbero comparirvi: Chatbot UI è MIT e non è archiviato, ma l'ultimo push risale al 3 agosto 2024 e non ha release, quindi è inattivo anziché un'opzione attiva; inoltre NextChat ora si descrive come un assistente a configurazione zero a cui ci si iscrive senza bisogno di una chiave API, con fatturazione a consumo, anziché come un frontend esclusivamente con chiave propria. Vale anche la pena distinguere nei risultati di ricerca: Jan non è Janitor AI, Msty Studio non è il fondo negoziato in borsa MSTY e LobeChat e LobeHub sono un unico progetto dopo una ridenominazione; pertanto i tutorial di configurazione di LobeChat precedenti alla v1.0 non sono aggiornati.

Come ciascuno accetta un endpoint personalizzato compatibile con OpenAI

Ognuno degli otto client qui sotto documenta un modo per indirizzarlo verso un endpoint di terze parti. Ciò che cambia è la superficie di configurazione, la forma dell'URL e la possibilità di fare qualcosa oltre a Chat Completions. Una colonna richiede che la domanda sia formulata in modo circoscritto: "Anthropic Messages route" chiede se il client stesso invierà richieste nel formato Anthropic al tuo endpoint. "None documented" significa che la documentazione del fornitore non descrive una modalità simile — non che sia noto che tale modalità non esista.

Quella tabella è tratta dalla documentazione dei singoli fornitori: le pagine di connessione OpenAI-compatible e Open Responses di Open WebUI, il riferimento sugli endpoint personalizzati di LibreChat, la pagina Generic OpenAI di AnythingLLM, la documentazione sugli endpoint personalizzati di Jan, la documentazione sui provider personalizzati di ChatWise, la pagina dei provider di LobeHub, la documentazione sui provider online di Msty e la documentazione sulle connessioni dei modelli di TypingMind.

Cherry Studio è volutamente assente da quella tabella. Il dominio della documentazione ora reindirizza da docs.cherry-ai.com a docs.cherryai.com.cn, un sito in lingua cinese le cui pagine sui provider non sono state consultate per questa pagina; pertanto i nomi dei campi e la convenzione dei percorsi non sono verificati qui — controllali nell'app prima di copiare un URL di base da un tutorial precedente.

Due aspetti specifici di Open WebUI che vale la pena conoscere indipendentemente dalla scelta. La sua documentazione sulle connessioni ai provider osserva che alcuni provider non implementano affatto /models; in tal caso la verifica della connessione fallisce, ma le chat completions continuano a funzionare e gli ID dei modelli vengono inseriti manualmente. Avverte inoltre che il livello di compatibilità di Google si discosta dallo schema di streaming OpenAI e raccomanda di impostare Function Calling su Legacy, così gli strumenti passano attraverso una richiesta separata non in streaming. L'avvertenza riguarda il livello di un singolo fornitore, non i livelli di compatibilità in generale — ma ricorda utilmente che il tool calling arriva tramite ciò che l'upstream implementa effettivamente e che il frontend non può correggere una lacuna nello schema.

Dal lato Kunavo, /v1/chat/completions, /v1/messages e /v1/responses esistono tutti come percorsi; quindi le modalità compatibili con Anthropic di provider: anthropic di LibreChat, di Jan e di ChatWise e il percorso sperimentale Responses di Open WebUI hanno ciascuno una superficie corrispondente. Nessuno di questi client è stato testato a runtime con Kunavo per questa pagina; una guida di configurazione pubblicata è un riferimento di configurazione, non un test di compatibilità. Un blocco personalizzato funzionante di LibreChat si presenta così:

endpoints:
  custom:
    - name: "Kunavo"
      apiKey: "${KUNAVO_API_KEY}"
      baseURL: "https://api.kunavo.com/v1"
      models:
        default: ["claude-sonnet-4-6", "claude-haiku-4-5"]
        fetch: true
      titleConvo: true
      titleModel: "claude-haiku-4-5"

Per la struttura generale di questa configurazione tra i client, consulta API compatibile con OpenAI. Per i confronti diretti tra due prodotti, LibreChat vs Open WebUI tratta gli ostacoli alla configurazione e AnythingLLM vs Open WebUI tratta RAG e distribuzione.

RAG: la parte che non segue l'endpoint della chat

Indirizzare un frontend verso un endpoint della chat non indirizza da nessuna parte la sua pipeline di recupero. Open WebUI mantiene credenziali separate per questa funzione. Secondo il suo riferimento sulle variabili d'ambiente, RAG_EMBEDDING_ENGINE seleziona il motore e RAG_OPENAI_API_BASE_URL / RAG_OPENAI_API_KEY ne gestiscono l'endpoint, proprio come la generazione di immagini ha il proprio IMAGES_OPENAI_API_BASE_URL. Se lasciato vuoto, RAG_EMBEDDING_ENGINE usa per impostazione predefinita SentenceTransformers in esecuzione locale — l'accelerazione GPU per gli embedding è attivabile tramite l'immagine CUDA — quindi l'impostazione predefinita non costa nulla per richiesta. Anche AnythingLLM separa le stesse componenti, configurando LLM, embedder e database vettoriale come provider distinti. La compatibilità della chat, quindi, non stabilisce la compatibilità del recupero in nessuno dei due prodotti.

Questo è importante qui per un motivo concreto: gli embedding non sono forniti da Kunavo — nessun modello abilitato supporta quell'endpoint — quindi il passaggio di recupero rimane locale oppure punta a un provider esterno a tua scelta. Consideralo separatamente rispetto alla chat e tienilo fuori da qualsiasi piano di migrazione del gateway. L'implementazione RAG spiega come vengono suddivise le fasi.

Cosa migra e cosa dovrai ricostruire

Definisci le aspettative prima di iniziare: la cronologia delle chat non passa automaticamente da un prodotto all'altro. La documentazione di importazione ed esportazione di Open WebUI afferma che l'esportazione comprende "All chat messages and their metadata, Model information used in each conversation, Timestamps and conversation structure" e che l'importazione accetta esportazioni di Open WebUI, esportazioni di ChatGPT e JSON personalizzato — con la frase esplicita che per le altre piattaforme "There is no built-in converter". Dal lato ricevente, la documentazione sull'importazione di LibreChat elenca ChatGPT, Claude e ChatbotUI v1 e non menziona Open WebUI. Due importer documentati, nessuna sovrapposizione.

Quell'ultima riga è la prima da risolvere anche se rimani. Secondo la documentazione sul ridimensionamento, la scelta del motore è di fatto permanente una volta che hai dati di produzione; le distribuzioni con più repliche richiedono PostgreSQL più Redis e un database vettoriale esterno anziché SQLite e Chroma integrato; inoltre, per SQLite su storage di rete, l'unico rimedio offerto dalla documentazione è passare a PostgreSQL anziché usare un flag di ottimizzazione. Un vero trasferimento dell'intera istanza consiste quindi nella copia a livello di file della directory dei dati, non in un file di esportazione. Il tutorial sulla manutenzione del database colloca webui.db — con i relativi file laterali -wal e -shm — in /app/backend/data all'interno del container, mentre il riferimento sulle variabili d'ambiente descrive DATA_DIR come directory di base "for data storage, including uploads, cache, vector database, etc.", e indica che il log di audit, per impostazione predefinita, si trova in audit.log all'interno della stessa directory. Copia la directory, non un elenco di file.

Esegui un backup prima di toccare qualsiasi cosa. Prima conferma il nome del tuo container — questa è la struttura, non uno script da incollare alla cieca:

# 1. Stop the instance so nothing writes mid-copy.
docker stop open-webui

# 2. Copy the whole data directory out of the container.
#    The documented location is /app/backend/data. DATA_DIR is
#    described as the base for uploads, cache, the vector database
#    and the audit log, so take the directory rather than webui.db.
docker cp open-webui:/app/backend/data ./open-webui-backup-$(date +%F)

# 3. Start it again and confirm the UI still loads before you touch anything.
docker start open-webui

Piano di rollback: mantieni intatta e in esecuzione la vecchia istanza e il relativo tag dell'immagine mentre provi la sostituzione, anziché migrare sul posto. Esegui entrambe sullo stesso endpoint per una settimana, sposta prima un team e dismetti l'originale solo dopo che la nuova istanza ha superato un carico di lavoro reale. Poiché la cronologia delle chat non viene trasferita, un rollback dopo aver dismesso l'originale significa perdere ciò che è stato scritto nel nuovo strumento — un argomento ancora più forte a favore dell'esecuzione affiancata rispetto a qualsiasi confronto di funzionalità.

Quanto costa il lato modelli, indipendentemente dal frontend scelto

Nessuno di questi frontend fattura i token; lo fa l'API che sta dietro di essi. Le cifre seguenti sono un calcolo illustrativo dei token, non costi misurati né un limite massimo di fatturazione. Supponi che una persona svolga 10 conversazioni per giornata lavorativa, ciascuna inviando 25.000 token di input non memorizzati in cache nell'arco dei suoi turni e ricevendo 1.500 token di output, per 20 giornate lavorative — cioè 5.000.000 token di input e 300.000 token di output per persona-mese. Le tariffe sono i prezzi attuali del catalogo Kunavo per milione di token.

Confrontalo con i prezzi del frontend, non al loro posto. Un frontend self-hosted non addebita nulla per postazione; quindi, secondo queste ipotesi, il traffico dell'intero team sui modelli Claude Sonnet 4.6 ammonta a $68,25 al mese, mentre lo stesso team sui modelli Claude Haiku 4.5 ammonta a $22,75 — una differenza mensile di $45,50 per un traffico ipotizzato identico, ricorrente ogni mese anziché pagata una sola volta. Il modello predefinito a cui viene indirizzato un frontend è quindi una decisione di budget attuale a tutti gli effetti, separata dalla licenza pagata per l'app. È la tua reale forma d'uso a determinarla, quindi misura le tue conversazioni prima di definire il budget. L'ottimizzazione dei costi dell'AI spiega come effettuare questa misurazione in modo corretto.

L'importo del catalogo Kunavo è una soglia minima di fatturazione, non un tetto massimo: quando l'upstream comunica il proprio addebito, la fattura è pari al maggiore tra il costo del catalogo e il costo dell'upstream moltiplicato per il markup applicabile. Gli addebiti per la cache e gli strumenti esterni non rientrano in questo esempio. La ricarica minima è di $10 in credito prepagato, che finanzia un saldo anziché acquistare una postazione o un piano — vedi i dettagli sulla fatturazione.

Se rimani su Open WebUI

È un esito difendibile di questa pagina e, per la maggior parte dei team, quello giusto: il cambiamento di licenza limita il white-labeling, non le dimensioni della distribuzione; il progetto riceve release attivamente e nulla di quanto sopra è un motivo per ricostruire un'istanza funzionante. In ogni caso, vale la pena separare la decisione sul frontend da quella sull'endpoint, così un futuro cambiamento di client non comporta anche un cambiamento di provider e una nuova chiave. Kunavo pubblica un riferimento di configurazione per questo client — la guida all'integrazione di Open WebUI — oltre alla documentazione di configurazione per LobeHub, Chatbox e Cherry Studio. Crea un account Kunavo quando vuoi una chiave e un saldo prepagato unici dietro qualunque frontend tu scelga.

Domande frequenti

Verificato il 21 settembre 2026 leggendo direttamente ogni pagina collegata o risposta dell'API di GitHub: il testo della licenza di Open WebUI, la documentazione sulla licenza e sull'enterprise, la documentazione sulle connessioni ai provider, sul ridimensionamento e sull'importazione/esportazione, il repository e l'ultima release, il 404 su openwebui.com/pricing, il repository e la documentazione sull'importazione di LibreChat e le pagine dei prezzi pubblicate per AnythingLLM, LobeHub, Msty, ChatWise e TypingMind. Sono state lette direttamente anche le pagine di Open WebUI su Open Responses e sul riferimento delle variabili d'ambiente, il riferimento di LibreChat sugli endpoint personalizzati, la pagina Generic OpenAI di AnythingLLM, la documentazione sui provider personalizzati di Jan e ChatWise, la pagina dei provider di LobeHub (ancora un segnaposto di migrazione), la guida di Chatbox all'uso della propria chiave e i metadati del repository per Pipelines, TextGen e Chatbot UI, ormai inattivo. I passaggi di configurazione di Msty e TypingMind sono collegati, ma sono stati ricavati da riepiloghi della documentazione anziché da una lettura completa. I campi di configurazione di Cherry Studio rimangono non verificati e sono indicati come tali sopra. Nessun client di questa pagina è stato testato a runtime con Kunavo. Le tariffe dei token Kunavo sono state lette dal catalogo attuale e ogni cifra in dollari nella sezione sui costi è un calcolo illustrativo dei token.