Por qué añadir Open-WebUI a tu servidor Ollama
Ollama expone una API REST compatible con OpenAI — eficiente para desarrolladores, inaccesible para otros miembros del equipo. Open-WebUI cierra esa brecha: una interfaz web completa que se conecta a Ollama (o cualquier proveedor compatible con OpenAI) y convierte un servidor de inferencia en una herramienta colaborativa.
El repositorio supera las 155 000 estrellas en GitHub. Cuidado con la licencia: no es MIT. El proyecto publica una licencia propia, de tipo BSD de tres cláusulas, con una condición añadida: por encima de 50 usuarios en 30 días móviles, está prohibido modificar o retirar la marca « Open WebUI », salvo permiso escrito o licencia empresarial. Para un equipo pequeño nada cambia; más allá, lee el archivo LICENSE antes de personalizar la interfaz. Por su parte, Ollama anunció en julio de 2026 una ronda Serie B de 65 millones de dólares, señal de que el motor de inferencia se instala a largo plazo en los equipos de desarrollo.
El proyecto se mantiene de forma continua y publica etiquetas estables a buen ritmo: la versión 0.12.4 es del 25 de octubre de 2026. Ese ritmo tiene un reverso, porque los comportamientos por defecto cambian de una versión menor a otra (la llamada nativa a herramientas pasó a ser la opción por defecto en la 0.10.0). De ahí el interés de fijar una etiqueta y leer las notas de versión antes de cada actualización. Open-WebUI cubre necesidades que van mucho más allá del chat: RAG sobre archivos locales, gestión de múltiples modelos, grupos de usuarios, búsqueda web e integración SSO mediante OpenID Connect.
Lo que Open-WebUI aporta concretamente a tu stack Ollama
- Interfaz multiusuario: cada miembro del equipo tiene su cuenta, historial y conversaciones — sin acceso a la API bruta ni a la línea de comandos.
- RAG nativo: importa archivos PDF, Markdown o Word directamente desde la interfaz; Open-WebUI los indexa y los inyecta en el contexto de cada conversación.
- Gestión de modelos: descarga, elimina y activa modelos de Ollama desde la interfaz web, sin pasar por
docker exec. - SSO con OpenID Connect: conecta Open-WebUI a tu proveedor de identidad (Keycloak, Authentik, Google Workspace…) para acceso unificado y revocación centralizada.
- Grupos y roles: define quién accede a qué modelos, quién puede subir archivos, quién tiene derechos de administración.
- Sin dependencia de la nube: todos los tokens, conversaciones y archivos permanecen en tu infraestructura.
Requisitos de hardware y software
Open-WebUI se ejecuta en un contenedor Docker y se conecta a Ollama a través de la red Docker interna. Ambos pueden coexistir en el mismo VPS.
Para un equipo de 5 a 10 personas con modelos 7B cuantizados (Q4), planifica como mínimo:
- 8 GB de RAM (6 GB para el modelo + margen para Open-WebUI y el sistema)
- 4 vCPU: la inferencia en CPU es lenta con menos núcleos; pasa a 8 vCPU para un uso diario cómodo
- 30 GB de almacenamiento SSD mínimo, más espacio para tus modelos (un modelo 7B Q4 ≈ 4,5 GB, un modelo 13B ≈ 8 GB)
- Docker y Docker Compose instalados
- Un nombre de dominio apuntando a tu VPS (necesario para TLS y SSO)
- Un proxy inverso con HTTPS — Nginx, Traefik o Caddy (servido en HTTP sobre un dominio o una IP no locales, Open-WebUI pierde funciones en el navegador: ver la solución de problemas)
Desplegar Open-WebUI y Ollama con Docker Compose
Crear el archivo Docker Compose
Crea un directorio de trabajo y escribe el archivo de composición:
mkdir -p /opt/openwebui && cd /opt/openwebuiContenido de
compose.yml:services: ollama: image: ollama/ollama:latest container_name: ollama volumes: - ollama_data:/root/.ollama restart: unless-stopped open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui depends_on: - ollama ports: - "127.0.0.1:3000:8080" environment: - OLLAMA_BASE_URL=http://ollama:11434 - WEBUI_SECRET_KEY=cambia-esto-por-una-cadena-aleatoria volumes: - open_webui_data:/app/backend/data restart: unless-stopped volumes: ollama_data: open_webui_data:La clave
WEBUI_SECRET_KEYdebe ser una cadena aleatoria larga: genera una conopenssl rand -hex 32.Iniciar el stack
Lanza los dos servicios:
docker compose up -dVerifica que ambos contenedores estén activos:
docker compose psDescargar un primer modelo
Desde el host, descarga un modelo mediante Ollama:
docker exec -it ollama ollama pull llama3.1:8bTambién puedes hacerlo desde la interfaz Open-WebUI una vez conectado, en Panel de administración → Modelos → Descargar desde Ollama.com.
Configurar el proxy inverso Nginx con HTTPS
Open-WebUI escucha en
127.0.0.1:3000. Crea un virtual host en Nginx para exponerlo en HTTPS:server { listen 443 ssl; server_name openwebui.yourdomain.com; ssl_certificate /etc/letsencrypt/live/openwebui.yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/openwebui.yourdomain.com/privkey.pem; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 300s; } }Obtén el certificado con Certbot:
certbot --nginx -d openwebui.yourdomain.comCrear la cuenta de administrador
Abre
https://openwebui.yourdomain.comen tu navegador. La primera cuenta creada se convierte automáticamente en administrador. Introduce un correo y una contraseña.
Configurar el SSO con OpenID Connect
Open-WebUI admite de forma nativa la autenticación mediante OpenID Connect (OIDC). Puedes integrarlo con Keycloak, Authentik, Authelia o cualquier proveedor compatible (incluido Google Workspace o Microsoft Entra).
En compose.yml, añade las siguientes variables de entorno al servicio open-webui:
environment:
- OAUTH_CLIENT_ID=tu-client-id
- OAUTH_CLIENT_SECRET=tu-client-secret
- OPENID_PROVIDER_URL=https://tu-idp.example.com/.well-known/openid-configuration
- OAUTH_PROVIDER_NAME=Mi SSO
- ENABLE_OAUTH_SIGNUP=trueLa URL de callback que debes declarar en tu proveedor de identidad es https://openwebui.yourdomain.com/oauth/oidc/callback.
Reinicia el stack tras la modificación:
docker compose up -dPara restringir el acceso SSO a un dominio de correo específico (p. ej. @tu-empresa.com), configura la restricción directamente en tu proveedor de identidad, no en Open-WebUI. Keycloak y Authentik permiten filtrar por dominio a nivel del cliente OIDC — es el punto de control más seguro, ya que también cubre la API.
Activar el RAG sobre tus documentos
Open-WebUI integra un pipeline RAG (Generación Aumentada por Recuperación) que permite consultar tus documentos locales en una conversación. El procesamiento se realiza completamente en tu VPS — ningún documento se envía a un servicio externo.
Para activar el RAG:
1. Desde la interfaz, haz clic en el clip en la zona de entrada de una conversación, o usa la pestaña Documentos en el menú lateral.
2. Importa un archivo PDF, Markdown, DOCX o TXT. Open-WebUI lo trocea, vectoriza y almacena en su base de datos local.
3. En la conversación, prefija tu mensaje con # seguido del nombre del documento para inyectarlo como contexto.
Añadir la búsqueda web con SearXNG
La búsqueda web no viene integrada en Open-WebUI: la interfaz consulta un motor externo y luego inyecta las páginas encontradas en el contexto del modelo. SearXNG, un metabuscador autoalojado, evita depender de una clave de API de pago: consulta por ti varios motores públicos y devuelve una lista única. Ahí está también su fragilidad, detallada en la sección de solución de problemas más abajo.
Bastan tres ajustes. En SearXNG, abre settings.yml y añade json a la lista formats situada bajo search, junto a html: sin eso, Open-WebUI recibe un error 403. En Open-WebUI, abre Panel de administración → Ajustes → Búsqueda web, elige searxng e introduce la URL de consulta, por ejemplo http://searxng:8080/search?q=<query> (variable SEARXNG_QUERY_URL). También puedes definir ENABLE_WEB_SEARCH=true y WEB_SEARCH_ENGINE=searxng en el compose.yml. Si los dos servicios comparten una red Docker, el nombre del servicio sirve de host y el puerto de SearXNG no hace falta publicarlo en Internet.
Queda una trampa: tres interruptores deben estar activados a la vez, la búsqueda web global, la capacidad « búsqueda web » del modelo y el botón de la conversación en curso. Un solo olvido da una respuesta sin búsqueda, a menudo sin error visible.
Open-WebUI, AnythingLLM, LibreChat: qué interfaz elegir
Desplace la tabla
| Criterio | Open-WebUI | AnythingLLM / LibreChat |
|---|---|---|
| Backend LLM | Ollama nativo + cualquier endpoint OpenAI | OpenAI, Ollama, Azure, LM Studio |
| Gestión de usuarios | Integrada, grupos, OIDC nativo | Integrada (AnythingLLM: espacios aislados) |
| RAG | Nativo, sin configuración | Nativo, configurable (LanceDB, pgvector) |
| Estrellas GitHub | 155 000+ (licencia propia, marca protegida) | 65 000+ (MIT) / 45 000+ (MIT) |
| Caso de uso principal | Equipo con Ollama ya desplegado | RAG multi-fuente avanzado / chat multi-backend |
Solución de problemas: errores comunes
Connection refused al iniciar Open-WebUI.
Ollama aún no está listo cuando Open-WebUI intenta conectarse. Espera 20 segundos y ejecuta docker compose restart open-webui.
El streaming se interrumpe tras 60 segundos.
Tu proxy inverso aplica un timeout HTTP por defecto. Añade proxy_read_timeout 300s; en el bloque Nginx location /.
WebSocket connection failed.
Verifica que las cabeceras Upgrade y Connection se transmitan correctamente por el proxy inverso.
La autenticación SSO devuelve redirect_uri_mismatch.
La URL de callback declarada en tu proveedor de identidad no coincide con la que envía Open-WebUI. Debe ser exactamente https://openwebui.yourdomain.com/oauth/oidc/callback.
Un usuario SSO puede iniciar sesión pero no tiene acceso a ningún modelo.DEFAULT_USER_ROLE vale pending por defecto: toda cuenta nueva, SSO incluido, espera a que un administrador la active, y ENABLE_OAUTH_SIGNUP solo gobierna la creación de la cuenta. Cambia su rol a user en Panel de administración → Usuarios, o establece DEFAULT_USER_ROLE=user en las variables de entorno.
Pantalla que no responde, crypto.randomUUID is not a function en la consola del navegador.
Open-WebUI se sirve en HTTP sobre un dominio o una dirección no locales: el navegador solo ofrece esta función en un contexto seguro (HTTPS o localhost). Termina la configuración TLS del proxy inverso antes de probar las funciones de IA.
La búsqueda web no devuelve nada.
Consulta la sección dedicada más abajo: prueba SearXNG por separado antes de culpar a Open-WebUI.
Solución de problemas: la búsqueda web no devuelve nada
Síntoma. La búsqueda web está activada, pero la conversación muestra No results found from web search (un error 404 en el registro de Open-WebUI), o el modelo responde sin haber buscado.
Qué dice ese mensaje. Open-WebUI sí llegó a SearXNG, le envió la consulta y recibió una lista vacía. Un caso público lo ilustra (issue open-webui #32401, abierta el 14 de octubre de 2026 tras pasar a la 0.12.0): el autor sospechaba de la nueva versión, el equipo de mantenimiento culpó primero al modelo y luego, con el registro de SearXNG en mano, comprobó que DuckDuckGo respondía con un CAPTCHA, Brave con « Too many requests » (motor suspendido 3 minutos cada vez) y Startpage con una redirección a su CAPTCHA. Todos los motores bloqueados, es decir, cero resultados. Según el mantenimiento, esos sitios bloqueaban la dirección IP con independencia de la actualización. La issue se cerró ese mismo día sin corrección del lado de Open-WebUI, y el autor acabó eligiendo el proveedor DDGS.
El método que conviene recordar: antes de culpar a la versión o al modelo, consulta SearXNG por separado.
Diagnosticar una búsqueda web vacía
Consultar SearXNG sin Open-WebUI
Desde el VPS, ejecuta
curl -s 'http://127.0.0.1:8080/search?q=test&format=json'adaptando host y puerto a tu instalación (si SearXNG solo es accesible por la red Docker, ejecuta el comando desde un contenedor de esa red). Tres resultados posibles: un error 403 significa que faltajsonenformats; una listaresultsvacía significa que los motores fallan; una lista con resultados significa que SearXNG funciona y que el problema está en Open-WebUI o en el modelo (ver el recuadro más abajo).Leer el registro de SearXNG
docker compose logs --tail 200 searxngmuestra lo que respondió cada motor. Busca las líneas que nombran un motor (duckduckgo, brave, startpage…) con un CAPTCHA, un rechazo por exceso de peticiones o un tiempo agotado. Un motor que reaparece en cada búsqueda con el mismo error está bloqueado para la dirección IP de tu VPS, algo que ocurre con más facilidad en una dirección de centro de datos.Activar o sustituir motores
En
settings.yml, secciónengines, activa motores generalistas que no estén bloqueados: el mantenimiento de Open-WebUI cita Google, Bing, Mojeek y Qwant. Una entradaname: mojeekcondisabled: falseactiva un motor presente en los ajustes por defecto; conuse_default_settings: trueal principio del archivo, solo listas tus diferencias. Reinicia condocker compose restart searxngy repite el paso 1 hasta obtener resultados. Activa varios motores: uno solo vuelve enseguida a quedar bloqueado.Usar un proveedor con clave si la IP sigue bloqueada
Si todos los motores fallan, un proveedor por API evita el problema: Brave Search API, Tavily o Serper se eligen en la misma pantalla de administración. Para el plan gratuito de Brave, define
WEB_SEARCH_CONCURRENT_REQUESTS=1. El proveedor DDGS, que eligió el autor de la issue, no requiere clave.
¿SearXNG devuelve resultados pero el asistente nunca busca? Desde la versión 0.10.0 (finales de junio de 2026), la llamada nativa a herramientas es el modo por defecto: la búsqueda web pasa a ser una herramienta que el modelo debe invocar por sí mismo, y un modelo antiguo o pequeño la omite o escribe una llamada mal formada. Elige un modelo reciente que gestione herramientas y comprueba que Function Calling esté en Native en los parámetros avanzados del modelo; el mantenimiento describe el modo Legacy como no soportado. Si la búsqueda funciona pero las páginas no se cargan, revisa WEB_SEARCH_TRUST_ENV detrás de un proxy HTTP y luego USER_AGENT.
Seguir el uso de una instancia de equipo
Saber quién consume qué se convierte pronto en una cuestión de presupuesto cuando los desarrolladores llaman a la instancia por la API. Hoy, cuatro fuentes se complementan, cada una con un punto ciego:
Las cuatro fuentes de medida
- El panel Analytics (ajustes de administración, sección Analytics): mensajes, tokens de entrada y de salida, por modelo y por usuario, con filtro por grupo y por periodo; desde la 0.12.4, la clasificación es por tokens. Se calcula a partir del historial de mensajes guardado en la base de datos: lo que no se guarda ahí no aparece.
ENABLE_ADMIN_ANALYTICS=Falselo oculta. - La vista personal (ajustes, pestaña Usage, desde la 0.11.0 de julio de 2026): cada usuario ve su propia actividad, y nada de la de los demás.
- El registro de auditoría: desactivado por defecto (
AUDIT_LOG_LEVEL=NONE). ConAUDIT_LOG_LEVEL=METADATA, Open-WebUI escribeaudit.logen su directorio de datos (rotación a 10 MB) para las peticiones autenticadas por cabeceraAuthorizationo por cookie: las llamadas de API aparecen, por tanto, con el modelo solicitado. Para obtener también los tokens de cada respuesta (desde la 0.12.4), quita/chatdeAUDIT_EXCLUDED_PATHS, que por defecto vale/chats,/chat,/folders. Evita los nivelesREQUESTyREQUEST_RESPONSE, que registran el contenido de las conversaciones, y repite una llamada de prueba para leer la entrada generada antes de construir un recuento sobre ella. - Los registros del proxy inverso: el ángulo más simple para el volumen. Con el formato combined de Nginx,
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | headclasifica las rutas más llamadas; añade$request_timea tulog_formatpara detectar peticiones lentas. Este registro no ve ni al usuario ni los tokens, y la cabeceraAuthorizationnunca debe quedar registrada en él.
Lo que el seguimiento de uso aún no hace
La petición de un seguimiento que separe la interfaz de la API y atribuya las llamadas a cada clave está abierta en el repositorio del proyecto: issue open-webui #21675, « enh: analytics », creada el 20 de febrero de 2026 y todavía abierta el 28 de octubre de 2026, con un centenar de comentarios. El hilo cuenta que un usuario de API colocado en un grupo no aparece en Analytics, y el 14 de octubre un equipo cuyos desarrolladores usan sobre todo la API seguía pidiendo esa visibilidad. No se anuncia ninguna fecha: no planifiques nada sobre esta función.
El mantenimiento responde que un filtro, es decir, una función Python instalada en la interfaz, puede contar las peticiones, incluidas las de la API; un colaborador precisa que las rutas en passthrough se le escapan. Sitúa los límites por usuario o por grupo en la limitación de tasa, fuera del tema Analytics. Leer directamente la base SQLite webui.db sigue siendo posible sobre una copia, pero su esquema no es un contrato y cambia de una versión a otra. Un colaborador también ha publicado un plugin de cuotas de terceros: una función se ejecuta con los derechos del servidor, así que revisa su código antes de activarla.
Da a cada desarrollador su cuenta y su propia clave de API en lugar de una clave compartida: sin una identidad distinta, ninguna de las cuatro fuentes puede atribuir el uso. Si la API pasa a ser el canal principal, una pasarela delante de Ollama que cuente las llamadas en origen (LiteLLM, ya en el catálogo de ServOrbit, ofrece claves virtuales y seguimiento del gasto) es una pista que conviene probar antes de adoptarla.
Asegurar el acceso a la API de Ollama
Por defecto, Ollama escucha en 0.0.0.0:11434 dentro de su contenedor. La configuración compose.yml propuesta arriba no publica este puerto en el host — solo Open-WebUI accede a él a través de la red Docker interna. Esta es la postura correcta.
Si necesitas acceder a la API de Ollama directamente (desde un IDE, un notebook Jupyter o una aplicación externa):
1. Túnel SSH: ssh -L 11434:localhost:11434 user@tu-vps — la API es accesible localmente sin exposición pública.
2. Proxy inverso con autenticación: expón Ollama detrás de Nginx con auth_basic o un token Bearer.
Nunca publiques el puerto 11434 directamente en la interfaz pública sin autenticación: la API de Ollama no tiene protección nativa contra accesos no autorizados.
Para mantener Open-WebUI actualizado, cambia la imagen de ghcr.io/open-webui/open-webui:main a ghcr.io/open-webui/open-webui:v0.12.4 (o la última etiqueta estable) en tu compose.yml. La etiqueta :main sigue el desarrollo continuo — útil para probar nuevas funciones, menos predecible en producción. Consulta las notas de la versión en GitHub antes de cada actualización: algunas versiones han introducido migraciones de base de datos, otras cambian comportamientos por defecto (la llamada nativa a herramientas en la 0.10.0), y las notas de la 0.12.0 recomiendan actualizar pronto los despliegues de producción por sus correcciones de seguridad.
Funciones avanzadas para explorar tras el despliegue
- Pipelines y funciones: Open-WebUI permite escribir funciones Python que se intercalan en el flujo de conversación — filtros, enriquecedores de contexto, conectores a APIs externas.
- Modelos personalizados: crea 'modelos' preconfigurados (instrucciones de sistema, temperatura, contexto) y compártelos con grupos de usuarios específicos.
- Generación de imágenes: conecta Open-WebUI a una instancia local de Stable Diffusion o ComfyUI para generar imágenes directamente en el chat.
- Integración con herramientas externas: mediante el protocolo MCP (Model Context Protocol), Open-WebUI puede llamar a herramientas externas — bases de datos, APIs REST, búsqueda web.
Documentación oficial
Para la configuración avanzada y las opciones propias de la herramienta, consulta la documentación oficial de Open-WebUI. Esta guía cubre el despliegue básico y las configuraciones más habituales — los parámetros específicos de tu entorno (integración LDAP, configuración de pipelines, ajuste de embeddings) se encuentran en la documentación del proyecto.
