Open WebUI paso a paso: abre tu IA local desde el navegador

Desplegar Open WebUI y conectarlo a Ollama sin publicar servicios internos

Open WebUI es una aplicación multiusuario. Aunque la primera prueba se ejecute en un único equipo, conviene separar su interfaz, su almacenamiento y el servidor de modelos. El navegador se conecta a Open WebUI; Open WebUI se conecta a Ollama por una red interna; Ollama no necesita quedar expuesto a los usuarios.

Navegador → HTTPS → Open WebUI → red interna → Ollama → GPU
                         ↓
                 usuarios, chats y conocimiento

docker run -d \
  -p 127.0.0.1:3000:8080 \
  -v open-webui:/app/backend/data \
  --name open-webui \
  ghcr.io/open-webui/open-webui:main

1. Arranca Ollama y comprueba su API. Haz la prueba desde el host o contenedor que ejecutará Open WebUI, no solo desde tu terminal personal.
2. Crea un volumen persistente. Usuarios, configuración y conversaciones no deben depender de la capa efímera del contenedor.
3. Fija la URL de Ollama. En contenedores, localhost apunta al propio contenedor; utiliza el nombre interno o la dirección permitida.
4. Crea la primera cuenta administrativa. Hazlo antes de abrir el servicio a otros usuarios y desactiva el alta libre si no corresponde.
5. Prueba un modelo pequeño. Verifica respuesta, streaming, contexto y errores antes de añadir proveedores o herramientas.
6. Publica mediante HTTPS. No expongas directamente el puerto de desarrollo a Internet.
7. Documenta la versión y copia. Antes de actualizar, conserva base de datos, configuración y un procedimiento de reversión.

No utilices la etiqueta flotante de una imagen en un entorno crítico. Fija una versión probada, revisa cambios y actualiza primero una instancia de ensayo.

Primer administrador, altas, modelos y conexiones

La configuración de conexión a Ollama o a otros proveedores es de instancia y afecta a los usuarios que puedan acceder a esos modelos. No mezcles una prueba personal con claves de producción. Decide desde el principio quién administra proveedores, quién crea conocimiento y quién solo conversa.

Conectar Ollama cuando ambos están en Docker

Coloca los contenedores en una red interna y utiliza el nombre del servicio. Publica Open WebUI al proxy; Ollama puede quedar sin puerto público. Si Ollama está en el host, habilita solo la ruta necesaria y comprueba firewall. Cambiar OLLAMA_HOST a todas las interfaces no añade autenticación.

Confirmar que la petición sigue siendo local

Selecciona un modelo descargado localmente, desactiva conexiones no utilizadas y observa los registros de Ollama mientras respondes. Una interfaz local puede conectarse a un proveedor externo si está configurado; la ubicación de la página no demuestra la ubicación de la inferencia.

Construir roles y grupos desde el mínimo privilegio

Open WebUI distingue roles y permisos granulares. Utilízalos como una capa de aplicación, pero conserva las autorizaciones de datos también en el sistema de origen y en el proceso de recuperación. Un grupo de interfaz no debe ser la única protección de un repositorio sensible.

1. Enumera capacidades: chat, subir archivos, compartir, crear conocimiento, usar herramientas y administrar.
2. Asigna cada capacidad a un rol o grupo, no a personas de forma improvisada.
3. Prueba altas, cambios de grupo y bajas.
4. Comprueba que enlaces compartidos no atraviesan permisos.
5. Revisa periódicamente cuentas, sesiones y recursos públicos.

El estado «pendiente» es útil para impedir acceso hasta la aprobación. También debes definir cómo se revocan sesiones cuando una persona cambia de función o abandona la organización.

Crear una colección útil, probar recuperación y ajustar el contexto

La función de conocimiento permite adjuntar documentos y recuperar fragmentos durante el chat. Para una prueba, empieza con pocos archivos bien estructurados. Para empresa, aplica el método completo de RAG con permisos y evaluación.

1. Crea una colección por finalidad. No mezcles manuales públicos, políticas internas y documentos restringidos.
2. Sube una muestra limpia. Comprueba que el texto, tablas y títulos se han extraído correctamente.
3. Selecciona un modelo de embeddings. Registra cuál se usa; cambiarlo puede exigir reindexar.
4. Añade metadatos y propietario. Identifica versión y vigencia fuera del nombre del archivo.
5. Prueba la búsqueda. Formula preguntas con respuesta, sin respuesta y con términos exactos.
6. Revisa los fragmentos recuperados. Antes de juzgar al modelo, confirma que recibió la evidencia.
7. Ajusta contexto. Un contexto demasiado pequeño puede recortar fragmentos; uno excesivo consume memoria y prefill.
8. Exige citas y abstención. El usuario necesita comprobar de dónde procede la respuesta.

Ollama y el contexto: configura una ventana suficiente para instrucciones, historial y fragmentos. Aumentarla consume más memoria; mide la configuración efectiva y no solo el máximo de la familia.

Cuándo no utilizar el modo de documento rápido

Si existen permisos por usuario, muchas versiones, actualización continua o requisitos de auditoría, utiliza una canalización RAG administrada. El chat con archivos es adecuado para una prueba individual; no sustituye gobierno documental.

Añadir capacidades sin convertir cada conversación en una ejecución privilegiada

Open WebUI puede integrar herramientas, funciones y conexiones externas. Cada extensión amplía la superficie de ataque y el recorrido de los datos. El modelo propone utilizarla; la aplicación y el servicio remoto deben aplicar permisos.

• Finalidad concreta y propietario
• Entradas y salidas tipadas
• Dominios o recursos permitidos
• Credencial de mínimo privilegio
• Tiempo máximo, cuota y límite de pasos
• Aprobación para acciones relevantes
• Registro y procedimiento de desactivación

Los protocolos de herramientas facilitan conexión, pero no hacen segura una herramienta. Revisa el servidor, los comandos expuestos y su autenticación. No permitas una terminal general, acceso al sistema de archivos completo o peticiones arbitrarias desde una instancia multiusuario.

Proteger identidad, red, datos y ciclo de actualización

Variables de seguridad que debes decidir antes de abrir usuarios

Fija estos valores en la versión que hayas probado y confirma su valor efectivo en el panel de administración. Algunas opciones son persistentes y un valor guardado en la base puede prevalecer sobre el entorno después del primer arranque.

WEBUI_URL=https://ia.intranet.ejemplo
ENABLE_SIGNUP=False
ENABLE_PASSWORD_VALIDATION=True
WEBUI_SESSION_COOKIE_SECURE=True
WEBUI_SESSION_COOKIE_SAME_SITE=strict
JWT_EXPIRES_IN=24h
CORS_ALLOW_ORIGIN=https://ia.intranet.ejemplo

• URL y CORS: declara únicamente los orígenes reales. No mantengas * cuando la instancia tiene usuarios o herramientas.
• Cookies: exige Secure sobre HTTPS. Si utilizas OAuth u OIDC, prueba el callback; SameSite=strict puede impedirlo y puede ser necesario lax.
• Sesiones: evita tokens sin caducidad. Sin un backend de revocación compartido, cerrar sesión o cambiar la contraseña puede no invalidar inmediatamente un token ya emitido; acorta su vida y evalúa Redis para producción.
• Clave de firma: conserva WEBUI_SECRET_KEY entre reinicios y réplicas. Rotarla invalida sesiones, por lo que necesita un procedimiento.
• Altas: comprueba el estado efectivo de ENABLE_SIGNUP y prueba una cuenta nueva desde una sesión privada.

Limita cabeceras de proxy, tamaño de subida, tiempo de petición y tipos de archivo. Analiza archivos antes de procesarlos y ejecuta la aplicación con un usuario sin privilegios. Las copias deben incluir datos persistentes y configuración, no solo la imagen del contenedor.

Resolver conexión, contexto y rendimiento siguiendo una secuencia

Mide Open WebUI y el servidor de modelos por separado. Una interfaz rápida no reduce el tiempo de inferencia; una GPU libre no corrige una base de datos lenta. Registra latencia de aplicación, cola, carga, prefill y generación.