Cómo autoalojar Open WebUI en 2026: endpoints de modelos, almacenamiento y seguridad

Trata Open WebUI como un sistema pequeño, no como una imagen de Docker. El objetivo de cara al usuario de Open WebUI es claro: una interfaz de chat para endpoints de modelos locales y compatibles con OpenAI; el despliegue solo es aceptable cuando puedes conectar un endpoint de modelo remoto, transmitir una respuesta de chat, subir un documento, ejecutar una recuperación y volver a abrir la conversación después de reiniciar.

Esta distinción permite detectar el fallo que los operadores encuentran después de las pruebas locales: OLLAMA_BASE_URL apunta a localhost dentro del contenedor de WebUI. También hace que el plan de copias de seguridad y actualizaciones sea lo bastante específico como para probarlo.

Elige la topología mínima viable de Open WebUI

Empieza por el namespace de red de Open WebUI: su listener web usa el puerto 8080, no un puerto del host copiado de un tutorial para portátil. El contrato de red de Open WebUI es una API compatible con OpenAI o un servicio de Ollama accesible. Mantén los endpoints privados en DNS interno, permite únicamente las llamadas salientes necesarias y asigna a Open WebUI una credencial de servicio con permisos limitados.

Una vez cumplido el requisito, ejecuta el escenario completo —conectar un endpoint de modelo remoto, transmitir una respuesta de chat, subir un documento, ejecutar una recuperación y volver a abrir la conversación después de reiniciar—. Registra logs y mediciones de latencia del modelo, streams simultáneos, trabajos de embeddings, tamaño de los archivos subidos y crecimiento del índice vectorial. Esta evidencia se convierte en la primera arquitectura conocida como válida y permite probar posteriores cambios entre el cómputo de Dockup y un servidor conectado.

TLS es fácil; las URL generadas no

La emisión de TLS es solo la mitad de la ruta de Open WebUI. Haz que el endpoint del modelo sea accesible desde la red del contenedor. Envía el tráfico internamente al puerto 8080 y reenvía el esquema externo para que las URL generadas y las cookies seguras sigan siendo coherentes.

Usa el escenario completo de Open WebUI desde una red limpia, no solo la página raíz. Un error 502 o un fallo de certificado se puede aislar con la configuración automática del dominio y TLS. Si el tráfico llega al proceso y OLLAMA_BASE_URL apunta a localhost dentro del contenedor de WebUI, diagnostica esa condición en el punto donde se produce en lugar de encadenar redirecciones.

Inicia Open WebUI sin ocultar los elementos importantes

Mantén la invocación inicial de Open WebUI lo bastante reproducible como para revisarla en un pull request.

docker run -d \
  --name open-webui \
  --restart unless-stopped \
  -p 127.0.0.1:8080:8080 \
  -v open-webui-data:/app/backend/data \
  -e WEBUI_SECRET_KEY=replace-with-a-long-random-value \
  ghcr.io/open-webui/open-webui:main

No dependas de latest cuando ya existan datos reales. Guarda el digest utilizado, el usuario del contenedor y los permisos del punto de montaje. Sigue el log de la aplicación durante una prueba completa —conectar un endpoint de modelo remoto, transmitir una respuesta de chat, subir un documento, ejecutar una recuperación y volver a abrir la conversación después de reiniciar— y anota cualquier migración antes de poner la ruta detrás de tráfico de producción.

Actualiza Open WebUI sin hacer suposiciones

Un health check inactivo dice muy poco sobre Open WebUI. Supervisa la latencia del modelo, los streams simultáneos, los trabajos de embeddings, el tamaño de los archivos subidos y el crecimiento del índice vectorial; después, genera alertas sobre el síntoma que experimentan los usuarios: el fallo de la acción «conectar un endpoint de modelo remoto, transmitir una respuesta de chat, subir un documento, ejecutar una recuperación y volver a abrir la conversación después de reiniciar». Mantén el liveness local y económico; deja que el readiness informe de las migraciones o la inicialización sin provocar una tormenta de reinicios.

El área de riesgo de una actualización es que las migraciones de base de datos, los backends de recuperación y la configuración de los endpoints de modelos pueden cambiar de forma independiente del frontend de chat. Lee las notas de la versión, crea una snapshot del estado, despliega la versión objetivo sobre una copia restaurada y repite la acción de aceptación. Si OLLAMA_BASE_URL apunta a localhost dentro del contenedor de WebUI, correlaciona la solicitud del cliente con el primer log relevante de la aplicación en lugar de eliminar datos o añadir redirecciones a ciegas.

Cinco comprobaciones más sólidas que la salud del contenedor

No conviertas el tráfico del primer usuario en la prueba de aceptación de Open WebUI. Prepara un estado de ejemplo inocuo y ejecuta la acción completa «conectar un endpoint de modelo remoto, transmitir una respuesta de chat, subir un documento, ejecutar una recuperación y volver a abrir la conversación después de reiniciar». Anota la URL pública exacta, el resultado, la referencia de la imagen y el intervalo de logs asociados a la ejecución.

Sustituye el contenedor y repite la prueba sin reconstruir los datos. Después, recupera el servicio en un host vacío; la condición de recuperación es que vuelvan las cuentas, los chats, los archivos y las colecciones de recuperación, y que la instancia restaurada pueda acceder al mismo endpoint de modelo. Observa la latencia del modelo, los streams simultáneos, los trabajos de embeddings, el tamaño de los archivos subidos y el crecimiento del índice vectorial en cada pasada, y define una alerta en torno a la degradación de la transacción, no de las métricas del contenedor inactivo.

Una última comprobación debe fallar deliberadamente: deniega temporalmente a la identidad de prueba el acceso a una API compatible con OpenAI o a un servicio de Ollama accesible. Verifica que el mensaje resultante de Open WebUI identifique el límite relevante en lugar de provocar la eliminación de datos o un reinicio infinito. Restablece la condición válida y confirma que la misma transacción de ejemplo se completa correctamente. Incluye esta breve prueba en la checklist de versiones.

Encuentra cada byte persistente de Open WebUI

En Open WebUI, la seguridad ante un redeploy empieza por los usuarios, los chats, los archivos, los datos vectoriales y la configuración de la aplicación. Monta /app/backend/data antes del bootstrap, escribe datos de ejemplo inocuos y sustituye el contenedor para demostrar que esa ruta es realmente persistente. Prueba la ruta sustituyendo el contenedor mientras existan datos de ejemplo inocuos; esto permite detectar los mounts apuntados un directorio demasiado arriba o demasiado abajo.

Después, prueba la recuperación ante desastres en un host vacío. Cuando sea necesario, usa una exportación de base de datos coherente con la aplicación y verifica que vuelvan las cuentas, los chats, los archivos y las colecciones de recuperación, y que la instancia restaurada pueda acceder al mismo endpoint de modelo. La guía de copias de seguridad de bases de datos con restauración probada ofrece un objetivo más sólido que limitarse a comprobar que se ha creado un archivo de archivo.

No le des a Open WebUI todo el host

Un despliegue seguro de Open WebUI empieza por eliminar autoridad. Evita dejar abierto el registro o usar un WEBUI_SECRET_KEY efímero; en su lugar, desactiva el registro público salvo que sea intencionado, conserva un secreto estable de WebUI y limita la administración de modelos a usuarios de confianza.

Trata WEBUI_SECRET_KEY según su función en Open WebUI: mantén los valores sensibles fuera de Git, documenta los efectos de la rotación y no sustituyas un ejemplo público en producción. Restringe las rutas administrativas, usa DNS privado para las dependencias y revisa cada bind mount. Cuando los logs se envíen a un sistema centralizado, filtra los secretos y el contenido privado antes de que salgan del servidor.

Usa Dockup para la capa de plataforma

Dockup elimina el trabajo manual de reverse proxy y gestión del ciclo de vida alrededor de Open WebUI. El servicio recibe una ruta HTTPS estable al puerto 8080, configuración inyectada y almacenamiento persistente durante las sustituciones. Un servidor del cliente conectado sigue el mismo modelo que el cómputo alojado en Dockup.

Después del lanzamiento, cumple el contrato de la aplicación: haz que el endpoint del modelo sea accesible desde la red del contenedor, conecta y prueba una API compatible con OpenAI o un servicio de Ollama accesible, y ejecuta esta prueba: conectar un endpoint de modelo remoto, transmitir una respuesta de chat, subir un documento, ejecutar una recuperación y volver a abrir la conversación después de reiniciar. Así, la experiencia de un clic sigue siendo útil sin ocultar los detalles que hacen que Open WebUI sea recuperable y seguro.

Preguntas frecuentes

¿Qué necesita Open WebUI para un despliegue de producción?

Enruta el contenedor de Open WebUI a través de un único origen HTTPS usando el puerto 8080. El requisito de red de soporte es una API compatible con OpenAI o un servicio de Ollama accesible. No des por listo Open WebUI hasta que puedas conectar un endpoint de modelo remoto, transmitir una respuesta de chat, subir un documento, ejecutar una recuperación y volver a abrir la conversación después de reiniciar.

¿Qué datos de Open WebUI deben incluirse en una copia de seguridad?

Haz persistente /app/backend/data e incluye usuarios, chats, archivos, datos vectoriales y la configuración de la aplicación en el mismo manifiesto de recuperación. Una restauración limpia de Open WebUI solo se completa cuando vuelven las cuentas, los chats, los archivos y las colecciones de recuperación, y la instancia restaurada puede acceder al mismo endpoint de modelo.

¿Open WebUI necesita HTTPS detrás de un reverse proxy?

Usa HTTPS para el origen público de Open WebUI y mantén el puerto 8080 en la ruta interna. Aplica correctamente la configuración de Open WebUI: haz que el endpoint del modelo sea accesible desde la red del contenedor. En Open WebUI, HTTPS protege las credenciales o el contenido del usuario durante el tránsito y mantiene coherente el comportamiento del cliente sensible al origen.

¿Cómo se debe probar una actualización de Open WebUI?

Restaura el estado actual de Open WebUI en un despliegue aislado, aplica la versión candidata y repite su transacción de aceptación. Presta especial atención porque las migraciones de base de datos, los backends de recuperación y la configuración de los endpoints de modelos pueden cambiar de forma independiente del frontend de chat. Conserva la imagen anterior de Open WebUI hasta comprender los límites de migración de datos y rollback.