Cómo alojar OpenUI en un VPS

OpenUI está pensado para los desarrolladores front-end y los diseñadores que quieren convertir una idea («un formulario de inicio de sesión con un botón azul y una opción de contraseña olvidada») en código HTML/Tailwind/React funcional, renderizado al instante en el navegador. En lugar de depender de un servicio en línea con límites de generación y riesgos de privacidad, alojarlo en su VPS le da un endpoint permanente, compartible mediante un enlace interno, donde cada uno puede prototipar sin instalación local. Punto clave: OpenUI necesita un LLM para generar el código — usted lo apunta o bien a un modelo externo mediante clave API (OpenAI, Anthropic, Mistral…), o bien a un Ollama local que corre en el mismo VPS, lo que mantiene toda la cadena en casa. El renderizado en tiempo real de los componentes acelera enormemente las iteraciones de maquetado.

OpenUI en sí mismo es ligero: la aplicación (backend Python + front) cabe en un VPS de 2 vCPU y 2 a 4 GB de RAM si utiliza una clave API externa para el modelo. Si quiere mantenerlo todo en local con Ollama en la misma máquina, dimensione según el modelo objetivo: calcule entonces de 8 a 16 GB de RAM adicionales para un modelo 7B cuantizado (ej. Qwen2.5-Coder-7B-Q4), y hasta 32 GB para un 13B. Prevea unos cuantos GB de disco para las imágenes Docker (y más si almacena modelos de Ollama — cada modelo pesa entre 4 y 8 GB). En cuanto al software: Ubuntu 22.04, Docker y Docker Compose, una clave API de modelo (u Ollama instalado), git y un subdominio configurado del tipo ui.midominio.com apuntando a su VPS.

Aquí tiene una configuración mínima de nginx para exponer OpenUI con Basic Auth y HTTPS. Cree /etc/nginx/sites-available/openui con: un upstream openui_backend apuntando a 127.0.0.1:7878, y un bloque server escuchando en el puerto 443 con su certificado (Let's Encrypt mediante Certbot o DNS-01). En el bloque location /, añada proxy_pass http://openui_backend, proxy_http_version 1.1, las cabeceras Upgrade y Connection para WebSocket (OpenUI usa conexiones persistentes para el renderizado en tiempo real), y auth_basic con un fichero .htpasswd generado por htpasswd -c /etc/nginx/.htpasswd user. Añada un segundo bloque server en el puerto 80 que redirija con un 301 a HTTPS. Active el sitio con ln -s en sites-enabled y recargue nginx. Recuerde bloquear el puerto 7878 directamente: ufw deny 7878 para que ningún acceso no autenticado sea posible saltándose el proxy.

La confusión es frecuente en las búsquedas y los debates: OpenUI (de Wandb/W&B) y Open WebUI son dos proyectos distintos con usos muy diferentes. OpenUI genera código de componentes de interfaz de usuario a partir de una descripción textual — es una herramienta de prototipado y generación de código front-end. Open WebUI es una interfaz de chat web para interactuar con LLM (Ollama, OpenAI…), similar a lo que ofrece ChatGPT pero autoalojado. En resumen: si quiere crear componentes de UI mediante descripción, use OpenUI. Si quiere una interfaz de chat para sus modelos locales, use Open WebUI. Ambos pueden coexistir en el mismo VPS y compartir el mismo backend de Ollama — se complementan sin competir.

Para una cadena completamente soberana, haga convivir OpenUI y Ollama en el mismo docker-compose.yml sobre una red Docker interna. Defina dos servicios: ollama (imagen ollama/ollama) y openui (imagen construida desde ./backend). Añada una red personalizada ai_net y adjunte ambos servicios a ella. En las variables de entorno de OpenUI, apunte el backend a http://ollama:11434 — el DNS de Docker resuelve el nombre del servicio automáticamente sin exponer nunca Ollama a Internet. En cuanto a la calidad de generación, un modelo orientado a código (Qwen2.5-Coder, CodeLlama) da componentes Tailwind/React mucho mejores que un modelo generalista del mismo tamaño. Pruebe varios y quédese con aquel cuyo renderizado sea más fiel a sus prompts. Para activar la persistencia de sesiones y preferencias de usuario, monte un volumen Docker en el directorio de datos de OpenUI (/app/.openui) con el fin de conservar la configuración entre reinicios.

OpenUI reconoce varias variables de entorno útiles para un despliegue seguro. OPENAI_API_KEY: clave para modelos compatibles con OpenAI (OpenAI, Mistral, Groq…). ANTHROPIC_API_KEY: para los modelos Claude de Anthropic. OLLAMA_HOST: URL del backend de Ollama (ej. http://ollama:11434 en Docker Compose). HOST y PORT: dirección de escucha interna (deje 0.0.0.0:7878 detrás del proxy). Nunca almacene sus claves API en texto plano en docker-compose.yml: use un fichero .env (añadido a .gitignore) o un gestor de secretos. Como la autenticación nativa de OpenUI es limitada, prefiera la Basic Auth de nginx para un acceso restringido al equipo, o un proxy de identidad (Authelia, Authentik) si necesita SSO y registros de acceso por usuario.

Estos son los problemas más frecuentes al desplegar OpenUI en un VPS. Puerto 7878 inaccesible: compruebe que el firewall permita el puerto temporalmente para las pruebas (ufw allow 7878) o pruebe desde el propio VPS con curl http://localhost:7878. Error de conexión al modelo: verifique que la variable de entorno de la clave API está correctamente inyectada (docker compose exec openui env | grep API). Si usa Ollama local, compruebe que está en marcha y accesible (curl http://localhost:11434/api/tags). Fallo del build de Docker: asegúrese de construir desde la carpeta backend/, no desde la raíz del repositorio. Vista previa vacía tras la generación: OpenUI usa WebSocket para el renderizado en tiempo real — verifique que su configuración de nginx pase las cabeceras Upgrade: websocket y Connection: Upgrade. Memoria insuficiente con Ollama: si el contenedor es eliminado (OOMKilled), reduzca el tamaño del modelo (pase a un 3B o un 7B cuantizado Q4) o aumente la RAM de su VPS.