Open WebUI es una ventana tipo ChatGPT que instalas en tu propio servidor. Tu equipo entra con su usuario, conversa con un modelo de IA, sube documentos y le pregunta sobre ellos. Las conversaciones se guardan en tu máquina, no en la de un tercero. Lo que no trae es el modelo: eso lo pone Ollama (u otro servicio compatible), y Open WebUI es la cara que ve la gente. Aquí lo montamos con Docker, con dominio y HTTPS, y vemos cómo copiarlo y actualizarlo sin perder datos.
Revisado en septiembre de 2026. Open WebUI cambia a menudo: cada comando lleva enlace a su documentación oficial, y si algo no cuadra, manda la fuente.
Qué es Open WebUI (y qué no es)
Conviene separar dos piezas que se suelen confundir. El modelo es el que "piensa": un fichero de varios gigas que necesita memoria de la tarjeta gráfica (la VRAM) para responder rápido. El servidor de modelos es el programa que carga ese fichero y responde a las preguntas, y el más usado para esto es Ollama. Open WebUI es la tercera pieza: la interfaz. Una web con usuarios, historial, carpetas y subida de archivos que le pasa las preguntas al servidor de modelos y te enseña las respuestas.
Esa separación es buena noticia. Open WebUI se conecta a Ollama, pero también a cualquier API compatible con la de OpenAI, según su lista de funciones. Puedes cambiar o añadir modelos sin que tu equipo cambie de ventana.
Y también es una advertencia: Open WebUI no hace que el modelo sea mejor ni más rápido. Si el servidor no tiene memoria suficiente para el modelo que eliges, la ventana será muy bonita y la respuesta tardará. Eso se decide antes, y lo tienes en cuánta VRAM necesita cada modelo.
Qué le da a tu equipo
Lo útil en una empresa no es el chat, sino lo que lo rodea:
| Función | Qué significa en el día a día |
|---|---|
| Usuarios y roles | Cada persona entra con su cuenta. Hay administradores, usuarios normales y cuentas "pendientes" que aún no pueden entrar |
| Historial por persona | Cada uno ve sus conversaciones, organizadas en carpetas y etiquetas. Los demás usuarios no las ven (el administrador sí puede: lo vemos en las limitaciones) |
| Documentos | Subes un PDF y le preguntas. O montas una base de conocimiento (varios documentos juntos) y la citas en el chat con # |
| Varios modelos | Eliges el modelo en cada conversación, e incluso comparas dos respuestas lado a lado |
| Grupos y permisos | Decides qué modelos y qué bases de conocimiento ve cada grupo |
Las bases de conocimiento están descritas en la documentación de Knowledge: subes los ficheros, los asocias a un modelo o a una conversación y preguntas. Por dentro trocea el documento y busca los trozos relevantes antes de preguntar al modelo (a eso lo llaman RAG).
Antes de empezar: qué necesitas
Esta guía da por hecho tres cosas. Primero, un servidor Linux con Docker instalado (Docker es el programa que ejecuta "contenedores": cajas cerradas con una aplicación y todo lo que necesita). Segundo, Ollama instalado en esa misma máquina y con al menos un modelo descargado; si aún no lo tienes, sigue cómo instalar Ollama en un servidor y vuelve aquí. Tercero, un dominio o subdominio que puedas apuntar al servidor, por ejemplo chat.tuempresa.es.
Un punto de seguridad antes de tocar nada. Ollama no trae usuarios ni contraseñas: quien llegue a su puerto puede usarlo. En enero de 2026, SentinelOne y Censys encontraron unas 175.000 máquinas con Ollama abiertas a internet en 130 países. Por eso el esquema de esta guía es Ollama cerrado, escuchando solo dentro de la máquina, y Open WebUI delante con sus cuentas. Según la FAQ de Ollama, por defecto escucha en 127.0.0.1, que es justo lo que queremos. Déjalo así.
Instalación con Docker, paso a paso
1. Genera una clave fija
Open WebUI firma las sesiones de tus usuarios con una clave secreta. La guía de inicio oficial avisa: si no la fijas, cada vez que recrees el contenedor (y lo harás en cada actualización) se cierra la sesión de todo el mundo. Genérala una vez y guárdala donde guardes las contraseñas de la empresa:
openssl rand -hex 322. Arranca el contenedor
Este es el comando de la guía oficial para conectar con un Ollama en la misma máquina, con un único cambio nuestro: 127.0.0.1: delante del puerto.
docker run -d -p 127.0.0.1:3000:8080 \
--add-host=host.docker.internal:host-gateway \
-v open-webui:/app/backend/data \
-e WEBUI_SECRET_KEY=tu-clave-generada \
--name open-webui --restart always \
ghcr.io/open-webui/open-webui:mainQué hace cada parte:
| Parte | Para qué sirve |
|---|---|
-p 127.0.0.1:3000:8080 | Publica la web en el puerto 3000, pero solo para la propia máquina. Sin el 127.0.0.1, Docker la deja abierta a internet |
--add-host=...host-gateway | Permite al contenedor llegar a los servicios de la máquina anfitriona, donde está Ollama |
-v open-webui:/app/backend/data | Guarda todos los datos en un volumen llamado open-webui, fuera del contenedor. Es lo que copiarás |
-e WEBUI_SECRET_KEY=... | La clave del paso anterior |
--restart always | Si el servidor se reinicia, Open WebUI vuelve a arrancar solo |
:main | La versión que se va publicando. Más abajo verás por qué conviene fijar una concreta |
El 127.0.0.1 no es un capricho. La documentación de Docker dice que publicar un puerto es inseguro por defecto porque queda accesible desde fuera. Y hay un detalle que pilla a mucha gente: los puertos que publica Docker se saltan las reglas de ufw, el cortafuegos habitual de Ubuntu.
Si tu servidor tiene tarjeta NVIDIA, no necesitas la imagen :cuda de Open WebUI para esto. La GPU la usa Ollama, que es quien ejecuta el modelo.
3. Si no aparece ningún modelo
Es el tropiezo más común. Ollama escucha en 127.0.0.1 de la máquina, y para el contenedor eso es otra dirección: no lo ve. La página de errores de conexión da dos salidas. La primera es hacer que Ollama escuche en todas las interfaces con OLLAMA_HOST=0.0.0.0, pero eso lo expone a la red y te obliga a cerrarlo bien con el cortafuegos. La segunda, que es la que preferimos, es que el contenedor comparta la red de la máquina:
docker rm -f open-webui
docker run -d --network=host \
-v open-webui:/app/backend/data \
-e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
-e WEBUI_SECRET_KEY=tu-clave-generada \
--name open-webui --restart always \
ghcr.io/open-webui/open-webui:mainAsí Ollama sigue cerrado donde estaba. El cambio es que Open WebUI pasa a escuchar en el puerto 8080 de la máquina (no en el 3000), y ahora sí depende del cortafuegos: con esta variante Docker no publica puertos, así que ufw sí aplica. Deja entrar solo SSH, 80 y 443, y el 8080 cerrado desde fuera.
El primer usuario es el administrador
Abre la web (más abajo le ponemos dominio; para la primera prueba puedes usar un túnel SSH hasta el puerto) y regístrate. La primera cuenta que se crea en una instalación nueva es la de administrador, con control total, según la documentación de roles. Hazlo tú, en el momento, y con una contraseña larga. Si dejas la instalación a medias con el registro abierto, el primero que llegue se queda con ella.
Los tres roles son:
- Administrador: ve y configura todo.
- Usuario: usa el chat con los permisos que le des, directamente o por su grupo.
- Pendiente: tiene cuenta, pero no puede hacer nada hasta que un administrador lo active.
Dar de alta al equipo y controlar el registro
Tienes dos formas de meter a la gente. La más controlada: crear tú las cuentas desde el panel de administración, en la lista de usuarios, y pasarle a cada uno su acceso. La otra: dejar que se registren y aprobarlos.
La guía de endurecimiento de Open WebUI recomienda mantener el registro cerrado tras el primer usuario. Y en la referencia de variables, el rol que recibe una cuenta nueva (DEFAULT_USER_ROLE) es pending por defecto. Traducido: aunque alguien consiga registrarse, entra "en espera" y no ve nada hasta que tú lo apruebas. No lo cambies a user en una instalación abierta a internet.
Comprueba ambas cosas en los ajustes generales del panel de administración nada más instalar. Ojo con un detalle de esa misma referencia: varios ajustes se leen de las variables solo en el primer arranque y luego se guardan en la base de datos. Si cambias una variable después y no ves efecto, es por eso; se cambia desde el panel.
Con el equipo dentro, crea grupos (por ejemplo "Administración" y "Comercial") y decide qué modelos y qué bases de conocimiento ve cada grupo. Es lo que más se olvida.
Un dominio con HTTPS delante, no un puerto abierto
Open WebUI no cifra la conexión por sí mismo. La guía de endurecimiento lo dice claro: va detrás de un proxy inverso que se encarga del HTTPS. Un proxy inverso es un programa que recibe las visitas en tu dominio, con su certificado, y se las pasa por dentro a la aplicación.
Con Caddy, que pide y renueva el certificado solo, basta con esto en su fichero de configuración (el Caddyfile), siguiendo su guía de proxy inverso:
chat.tuempresa.es {
reverse_proxy 127.0.0.1:3000
}Si usaste la variante con --network=host, cambia el 3000 por 8080. Para que funcione, el dominio tiene que apuntar a la IP del servidor y los puertos 80 y 443 tienen que estar abiertos. Open WebUI usa WebSockets (una conexión que se queda abierta para ir mostrando la respuesta según se escribe), y el reverse_proxy de Caddy los pasa sin configurar nada. Si usas Nginx, tienes que reenviar tú las cabeceras Upgrade y Connection, como indica la página de errores de conexión.
Con el HTTPS ya delante, la guía de endurecimiento recomienda además activar WEBUI_SESSION_COOKIE_SECURE=true, para que el navegador solo mande la sesión por conexión cifrada. Se añade como otro -e al comando de arranque.
Dónde viven los datos y cómo copiarlos
Todo lo importante está en el volumen open-webui, que dentro del contenedor es la carpeta /app/backend/data. Según la guía de endurecimiento, ahí están la base de datos (usuarios, conversaciones, ajustes), los ficheros subidos y los complementos. El contenedor en sí no guarda nada que no puedas volver a descargar. El volumen, sí.
Una copia sencilla, adaptando el método que da la documentación de volúmenes de Docker:
docker stop open-webui
docker run --rm -v open-webui:/data -v "$(pwd)":/backup ubuntu \
tar czf /backup/open-webui-copia.tar.gz -C /data .
docker start open-webuiParamos el contenedor un momento para que la base de datos no se copie a medio escribir. Y tres reglas que la guía de endurecimiento también da: copia con regularidad, guarda la copia fuera de ese servidor y prueba de vez en cuando que se restaura.
Tus modelos de Ollama no van en este volumen. No pasa nada: se vuelven a descargar. Lo irrecuperable son las conversaciones, las cuentas y los documentos.
Actualizar sin perder nada
Como los datos están en el volumen, actualizar es tirar el contenedor y crear otro con la versión nueva, apuntando al mismo volumen. La guía oficial lo hace así:
docker pull ghcr.io/open-webui/open-webui:main
docker rm -f open-webuiDespués lanzas exactamente el mismo docker run que usaste, con la misma WEBUI_SECRET_KEY. Si cambias la clave, todo el equipo tendrá que volver a entrar. Si te olvidas del -v open-webui:/app/backend/data, arrancará una instalación vacía y parecerá que lo has perdido todo (el volumen sigue ahí, pero el susto es real).
Dos consejos. Guarda el comando de arranque en un fichero del servidor, para no reconstruirlo de memoria. Y en producción, la guía oficial recomienda fijar una versión concreta (:vX.Y.Z) en lugar de :main, que cambia continuamente. Así actualizas cuando tú decides, después de hacer copia, y no cada vez que alguien reinicia.
Limitaciones honestas
Lo que sube el equipo se queda en tu servidor, y eso obliga a decidir quién ve qué. Es la ventaja de todo esto, porque las conversaciones no salen a un proveedor externo. Pero ahora el proveedor eres tú. Si alguien crea una base de conocimiento con las nóminas y se la asigna a un modelo que ve toda la empresa, el modelo responderá con esas nóminas a quien pregunte. La herramienta tiene grupos y permisos; configurarlos bien es trabajo tuyo. Y hay algo que conviene contar al equipo: según la referencia de variables, por defecto un administrador puede ver las conversaciones de los demás desde su panel (ENABLE_ADMIN_CHAT_ACCESS) y exportarlas (ENABLE_ADMIN_EXPORT). Puedes desactivarlo con esas dos variables a False. Decídelo y díselo a la gente antes de que empiecen a escribir.
Tener la IA en casa tampoco te exime de pensar qué metes en ella. La AEPD publicó en noviembre de 2025 su política interna de uso de IA generativa, y sus preguntas sirven de criterio aunque no te obliguen: si el proveedor entrena con tus conversaciones, dónde se guardan, cuánto tiempo y si su personal las revisa. Con Open WebUI y Ollama en tu servidor, esas respuestas las das tú, y conviene tenerlas por escrito. Para el uso diario, repasa qué datos no compartir con una IA.
Los documentos grandes piden más máquina. Para preguntar a un PDF, Open WebUI lo procesa, lo trocea y calcula una representación numérica de cada trozo, y luego el modelo tiene que leer los trozos elegidos. Muchos documentos, o muy largos, piden más memoria RAM, más disco y más memoria gráfica para el contexto. El modo que mete el documento entero sin trocear existe, pero con modelos pequeños se queda corto de contexto enseguida. Empieza con pocos documentos y mira cómo responde la máquina.
Y la calidad de las respuestas la pone el modelo, no la interfaz. Un modelo pequeño en Open WebUI sigue siendo un modelo pequeño.
Lo que esta guía no te cuenta
Instalarlo es la parte corta. Lo que viene después decide si el equipo lo sigue usando dentro de seis meses:
- Actualizar sin romper. No solo Open WebUI. Si el servidor tiene GPU NVIDIA y se actualizan los controladores automáticamente, es habitual que Ollama deje de usar la tarjeta y aparezca el error
Failed to initialize NVML: Driver/library version mismatch. Según el soporte de NVIDIA, lo habitual es que se resuelva reiniciando, pero mientras tanto el modelo tira de procesador y todo va lentísimo. Hay que controlar cuándo se actualiza el controlador. - Cerrarlo a internet. Ollama escuchando solo dentro, Open WebUI detrás del proxy, registro cerrado y cortafuegos revisado. Y comprobarlo desde fuera, no suponerlo.
- Vigilar que responde. Que la web cargue no significa que el modelo conteste. Una sonda que haga una pregunta de verdad cada pocos minutos te avisa antes que el equipo.
- Copias. Programadas, fuera del servidor y probadas. El comando de arriba es el principio, no el sistema.
- Disco. Modelos, documentos, versiones viejas de imágenes de Docker. El disco se llena solo y en silencio.
Nada de esto es difícil, pero todo es constante. Si prefieres no encargarte tú, lo montamos y lo mantenemos nosotros en un servidor con GPU: Ollama, Open WebUI, el dominio, las copias y las actualizaciones, con un equipo que responde cuando algo falla.
Artículos relacionados
- Cómo instalar Ollama en un servidor
- Cuánta VRAM necesitas para un modelo de IA
- Qué datos de tu empresa no deberías compartir con una IA
¿Prefieres no encargarte tú?
Montamos tu IA en un servidor con GPU, la dejamos funcionando y la mantenemos nosotros.
