Alternativas a Open WebUI para un VPS público

Qué alternativa a Open WebUI conviene en un VPS

Las alternativas a Open WebUI casi siempre se comparan en un portátil, donde la RAM es barata y ningún servicio escucha en una dirección pública. Un VPS cambia ambos factores, y eso modifica la clasificación. Open WebUI sigue siendo la opción predeterminada adecuada en cuanto inicia sesión una segunda persona, porque incluye cuentas de usuario reales y un panel de administración. Los proyectos más ligeros ganan cuando la interfaz compite con el modelo por el último gigabyte de RAM. El precio de esa ventaja es la autenticación: no incluyen ninguna.

Todo lo que aparece a continuación procede de la documentación de cada proyecto, consultada en agosto de 2026. Los cuatro criterios son los que sólo importan cuando el servidor está accesible desde Internet.

Cuatro ejes que sólo importan con una IP pública

• Memoria junto al modelo. El servidor del modelo es el proceso que más recursos consume en el equipo. Cada megabyte que ocupa la interfaz es un megabyte que no puede utilizar el modelo.
• Autenticación. Algunos de estos proyectos tienen cuentas de usuario y roles. Otros asumen que son lo único que se ejecuta en el portátil y no incluyen ningún inicio de sesión.
• Inferencia remota. Una interfaz que sólo puede acceder a 127.0.0.1:11434 obliga a ejecutar el modelo en el mismo equipo que la interfaz.
• Mantenimiento. Un contenedor con un archivo SQLite requiere una gestión distinta de seis contenedores con MongoDB y una base de datos vectorial detrás.

Cuánta RAM deja el modelo para la interfaz

La interfaz no es el componente que más memoria consume en el servidor. El modelo sí lo es. Los tamaños de descarga publicados indican el mínimo, porque los pesos deben permanecer en memoria mientras el modelo responde. El uso real de memoria es mayor que el tamaño de descarga una vez que se asigna la caché de contexto.

[
  {
    "label": "llama3.2:3b",
    "download_gb": "2.0"
  },
  {
    "label": "qwen3:4b",
    "download_gb": "2.5"
  },
  {
    "label": "gemma3:4b",
    "download_gb": "3.3"
  },
  {
    "label": "qwen3:8b",
    "download_gb": "5.2"
  }
]

Esas son las cifras que mostraban las páginas de la biblioteca de Ollama en agosto de 2026. Son tamaños publicados, no mediciones. En un VPS de 4 GB, qwen3:4b con 2.5 GB deja menos de 1.5 GB para el sistema operativo y todo lo demás. Además, la caché de contexto consume memoria a medida que crece la conversación. qwen3:8b con 5.2 GB no cabe en ese servidor. Esta es la situación que las comparativas de portátiles nunca cubren. También es el punto en el que una interfaz de chat que ocupa unos cientos de megabytes determina si el modelo puede ejecutarse. Si está dimensionando un servidor para algo muy superior a estas etiquetas, el cálculo para un modelo 27B en un VPS que sólo usa la CPU muestra con qué rapidez la interfaz deja de ser el factor determinante.

Mida en lugar de confiar en cualquier cifra de una comparativa, incluida esta. Ejecute docker stats --no-stream una hora después de empezar a usarlo realmente, no un minuto después de iniciar el contenedor, porque la memoria importante se asigna durante el primer uso.

Open WebUI: la opción predeterminada incluso para más de un usuario

Open WebUI se ejecuta a partir de una imagen y guarda sus datos en un volumen.

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

El comando del README del proyecto publica -p 3000:8080, que escucha en todas las interfaces. El prefijo 127.0.0.1: lo mantiene en loopback. En un VPS, ese prefijo es más importante que cualquier otra cosa de la línea, porque Docker escribe sus propias reglas de iptables y un puerto publicado ignora las reglas de denegación de ufw.

Acceda a la página mediante un túnel o un proxy, descritos más abajo, y cree la primera cuenta. Esa cuenta se convierte en la administradora. Los registros posteriores se crean con el rol pending, el valor predeterminado documentado de DEFAULT_USER_ROLE, por lo que un extraño que acceda a la página aún no puede usar su modelo hasta que un administrador lo apruebe.

Open WebUI consume más memoria que los proyectos siguientes porque hace más cosas, y su propia página de rendimiento identifica los componentes responsables de ese consumo. El motor de embeddings predeterminado carga un modelo de sentence-transformers dentro del contenedor, con un consumo documentado de unos 500 MB por proceso de trabajo. Establecer RAG_EMBEDDING_ENGINE=ollama delega esa tarea en el servidor de modelos que ya ejecuta. AUDIO_STT_ENGINE=webapi evita cargar un modelo local de conversión de voz a texto. En SQLite, si DATABASE_POOL_SIZE no está establecido, el pool recurre a un tamaño interno grande y cada conexión crea su propia caché de páginas y su propio mapa de memoria, por lo que en un equipo pequeño establezca DATABASE_POOL_SIZE=8 y DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False evita que la interfaz solicite una finalización al modelo mientras el usuario todavía está escribiendo.

LibreChat: varios usuarios, con una pila detrás

git clone https://github.com/danny-avila/LibreChat.git
cd LibreChat
cp .env.example .env
docker compose up -d

La interfaz responde en el puerto 3080. LibreChat es la opción adecuada cuando necesita un sistema de identidades en lugar de un simple formulario de inicio de sesión: documenta los inicios de sesión mediante LDAP y OAuth2, e incluye un panel de administración para usuarios y roles. Esta capacidad requiere una pila de servicios.

[
  {
    "label": "OrionChat",
    "containers": 0,
    "notes": "static files, served by a web server you already run"
  },
  {
    "label": "Hollama",
    "containers": 1,
    "notes": "one container serving a browser app"
  },
  {
    "label": "Open WebUI",
    "containers": 1,
    "notes": "application and SQLite in one image"
  },
  {
    "label": "LibreChat",
    "containers": 6,
    "notes": "api, admin panel, MongoDB, Meilisearch, pgvector, RAG API"
  }
]

El archivo compose predeterminado inicia 6 servicios: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. Ninguno de ellos es el modelo. MongoDB y pgvector necesitan memoria propia, y en un equipo con 4 GB esa es memoria que necesita el modelo.

Las actualizaciones se realizan mediante una operación de git, que es la parte que suele hacerse mal.

docker compose down
git pull
docker compose pull
docker compose up -d

git pull se detiene con un conflicto si editó el archivo versionado docker-compose.yml, y la actualización queda aplicada sólo parcialmente. Coloque sus cambios en docker-compose.override.yml, que el proyecto proporciona para este fin, y mantenga los secretos en .env. Ambos archivos no están versionados, por lo que git pull no los modifica.

Configure LibreChat para usar su propio servidor de modelos mediante un endpoint personalizado en librechat.yaml.

endpoints:
  custom:
    - name: "Ollama"
      apiKey: "ollama"
      baseURL: "http://model-host:11434/v1/"
      models:
        default: ["llama3.2"]
        fetch: true
      titleConvo: true
      titleModel: "current_model"
      modelDisplayLabel: "Ollama"

Sustituya model-host por la dirección del equipo que ejecuta Ollama. El campo apiKey debe estar presente aunque Ollama ignore su valor, por lo que puede usar un marcador de posición. Si LibreChat se ejecuta en Docker y Ollama se ejecuta en el mismo equipo, localhost dentro del contenedor hace referencia al propio contenedor; use host.docker.internal en su lugar.

Hollama y OrionChat: el navegador hace el trabajo

Hollama sirve una aplicación web desde un contenedor pequeño. Las conversaciones se almacenan en el navegador, no en el servidor.

docker run -d --restart unless-stopped -p 127.0.0.1:4173:4173 --name hollama ghcr.io/fmaclen/hollama:latest

La versión de este comando incluida en el README usa --rm, que elimina el contenedor cuando se detiene. Por eso la interfaz no vuelve a estar disponible después de reiniciar. Detrás de un reverse proxy, añada -e VITE_ALLOWED_HOSTS='chat.example.com', porque la imagen sólo permite el host localhost y responde a cualquier otro nombre de host con un error de host bloqueado en lugar de mostrar la aplicación.

OrionChat va más allá y no tiene ningún componente en el servidor. Clone el repositorio y sirva la carpeta con el servidor web que ya utiliza, o abra index.html desde el disco. Las claves de API se almacenan en localStorage del navegador, el historial de conversaciones permanece en el navegador y la aplicación elimina las conversaciones más antiguas cuando el número supera 512.

Ninguno de los dos proyectos tiene inicio de sesión, porque ninguno tiene un servidor que pueda validarlo. En un portátil, esto no supone un problema. En un VPS, significa que la página nunca debe publicarse en 0.0.0.0. También implica algo que es fácil pasar por alto: el navegador llama al modelo, no el servidor.

Este hecho determina dónde se pueden utilizar. El navegador debe conectarse directamente a Ollama, por lo que Ollama debe escuchar en una dirección distinta de loopback. Además, Ollama no tiene ningún tipo de autenticación. De aquí se derivan dos reglas del navegador. Una página servida mediante HTTPS no puede llamar a un endpoint HTTP sin cifrar, y la consola muestra Mixed Content: The page at 'https://chat.example.com/' was loaded over HTTPS, but requested an insecure resource 'http://203.0.113.10:11434/api/tags'. This request has been blocked.. Las llamadas a cualquier otro origen se rechazan con has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource hasta que permita ese origen.

La forma documentada de Ollama para cambiar cualquiera de estos ajustes es utilizar una anulación de systemd.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_ORIGINS=https://chat.example.com"

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo ss -lntp | grep 11434

ss ahora debería mostrar 0.0.0.0:11434, donde antes mostraba 127.0.0.1:11434. Realice este cambio sólo cuando un firewall o un proxy con autenticación controle quién puede acceder al puerto, porque un 11434 abierto equivale a un servidor de modelos expuesto y los escáneres masivos alcanzan rápidamente un puerto público nuevo. El túnel SSH siguiente evita todo el problema: la página se ejecuta entonces en un origen localhost, que Ollama permite de forma predeterminada, y el puerto nunca sale del equipo.

¿Puede cada uno usar un endpoint remoto de Ollama o vLLM?

Open WebUI puede hacerlo, y la conexión se establece en el servidor. OLLAMA_BASE_URL=http://model-host:11434 lo dirige a Ollama. Para vLLM o cualquier otro servidor compatible con OpenAI, configure OPENAI_API_BASE_URL=http://model-host:8000/v1 con un OPENAI_API_KEY no vacío y conserve el sufijo /v1, que es obligatorio. OPENAI_API_BASE_URLS acepta varios backends separados por punto y coma.

LibreChat puede hacerlo mediante el baseURL del endpoint personalizado mostrado arriba. Esa solicitud también sale del servidor, por lo que no se aplica ninguna regla del navegador. La misma URL base y la misma clave de marcador de posición funcionan fuera de una ventana de chat. Eso basta para dirigir un agente de programación al modelo que ya aloja.

Hollama y OrionChat pueden apuntar a cualquier endpoint que introduzca en su configuración, pero la solicitud sale del navegador. Todo lo indicado en la sección anterior se aplica a ellos y a ningún otro componente de esta sección.

Separar la interfaz del modelo es la principal ventaja de un endpoint remoto. Coloque la interfaz en un equipo pequeño y el modelo donde haya memoria suficiente. Este es también el momento de decidir si Ollama o vLLM debe atender las solicitudes, porque su comportamiento cambia mucho cuando varias personas usan el modelo al mismo tiempo. Si todavía no existe el servidor del modelo, empiece por ejecutar Ollama en un VPS y, si el equipo sólo usa CPU, lea cómo se compara Ollama con llama.cpp antes de elegir un runner.

No publique una interfaz de chat sin autenticación en 0.0.0.0

La página de refuerzo de seguridad de Open WebUI indica que el proyecto está «diseñado para redes privadas y de confianza, como otras infraestructuras autoadministradas, por ejemplo bases de datos, registros de contenedores y servidores de CI», y recomienda colocarlo detrás de una VPN o de un reverse proxy con autenticación. Un proyecto sin ningún inicio de sesión requiere, como mínimo, el mismo tratamiento.

Compruebe qué está escuchando antes de confiar en cualquiera de estos servicios.

sudo ss -lntp | grep -E ':(3000|3080|4173|11434)'

Una línea que muestre 127.0.0.1:3000 es lo que busca. Una línea que muestre 0.0.0.0:3000 significa que la interfaz de chat está en Internet pública. Desde su propia máquina, que curl -sI http://YOUR.VPS.IP:3000 responda a HTTP/1.1 200 OK indica lo mismo de forma más directa.

Desactivar el inicio de sesión de Open WebUI con WEBUI_AUTH=False es una configuración para un único usuario y para una máquina a la que nadie más puede acceder. Además, no se aplica a una instalación que ya tenga cuentas. En ese caso, muestra el mensaje You can't turn off authentication because there are existing users.

Patrón uno: enlazar con loopback y acceder mediante SSH. Publique todos los puertos en 127.0.0.1. Después, reenvíe el puerto necesario con ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com y abra http://localhost:3000 en su portátil. No se publica ningún puerto, por lo que no se puede escanear ninguno. En Hollama u OrionChat, reenvíe el puerto del modelo en el mismo comando con -L 11434:127.0.0.1:11434 y deje Ollama enlazado a loopback. La seguridad de este patrón depende de la configuración de SSH. Combínelo con SSH con claves y un sshd reforzado.

Patrón dos: un reverse proxy que autentica la petición antes de que llegue a la aplicación. Mantenga la aplicación en loopback, haga que el proxy gestione el puerto 443 y coloque el inicio de sesión único delante de la aplicación. Traefik gestionado mediante etiquetas de Docker Compose junto con Authentik como proveedor de identidad proporciona a todas las aplicaciones del servidor un único inicio de sesión y un único certificado. Con Open WebUI detrás de TLS (seguridad de la capa de transporte), establezca WEBUI_SESSION_COOKIE_SECURE=true y WEBUI_SESSION_COOKIE_SAME_SITE=strict. Reduzca también JWT_EXPIRES_IN desde su valor predeterminado de cuatro semanas, porque la documentación de Open WebUI indica que, sin Redis, cerrar la sesión no invalida el token: sigue siendo utilizable hasta que caduca por sí solo.

El patrón dos no protege los proyectos que sólo funcionan en el navegador. Un proxy delante de la página no protege el endpoint del modelo. Además, una petición fetch desde esa página a otro nombre de host no incluye la cookie de sesión. Por eso, el proxy con autenticación situado delante de Ollama responde con una redirección a un formulario de inicio de sesión y el chat falla. Enrute el endpoint del modelo bajo el mismo nombre de host que la página o use el patrón uno.

Qué opción elegir

Si lo va a usar alguien más, ejecute Open WebUI. Tiene cuentas reales, los usuarios nuevos pasan a una cola de aprobación y sus mantenedores publican recomendaciones de refuerzo que puede seguir. Si necesita LDAP o un panel de administración, ejecute LibreChat y confirme con docker stats que sus seis servicios y el modelo caben realmente antes de depender de él. Si es una sola persona en un equipo pequeño donde el modelo ya ocupa la mayor parte de la RAM, sirva Hollama u OrionChat mediante un túnel SSH y deje que el navegador conserve el estado. En un VPS, la respuesta incorrecta es publicar cualquiera de ellos en 0.0.0.0 sin autenticación delante.

FAQ

¿Es seguro exponer Open WebUI directamente en una IP pública?

Su propia página de protección describe el producto como software para redes privadas y de confianza, en la misma categoría que una base de datos o un servidor de CI. Tiene cuentas reales, y la primera cuenta se convierte en administrador, mientras que las posteriores permanecen pending hasta que se aprueban. Por tanto, es mucho más seguro que una interfaz sin autenticación. Aun así, colóquelo detrás de un reverse proxy con TLS y, cuando sea posible, use single sign-on. Publique el puerto del contenedor como 127.0.0.1:3000:8080 para impedir que las reglas iptables propias de Docker lo expongan a Internet sin que usted lo advierta.

¿Qué alternativa a Open WebUI usa menos RAM en una VPS?

Las que se ejecutan en el navegador, Hollama y OrionChat, porque la aplicación se ejecuta en el cliente. El servidor sólo envía archivos estáticos, y OrionChat no necesita ningún contenedor de aplicación. Open WebUI mantiene en memoria un proceso de Python, una base de datos y, de forma predeterminada, un modelo local de embeddings. La documentación indica unos 500 MB por worker sólo para el modelo de embeddings. Confirme las cifras en su propio sistema con docker stats --no-stream, porque varían según las funciones que active.

¿Estas interfaces de chat pueden usar un servidor de Ollama en otro host?

Open WebUI y LibreChat pueden hacerlo, y la conexión la realiza su servidor, por lo que no se aplica ninguna restricción del navegador. Configure OLLAMA_BASE_URL para Open WebUI o baseURL en un endpoint personalizado de LibreChat. Para vLLM u otro servidor compatible con OpenAI, use OPENAI_API_BASE_URL con el sufijo /v1 y una clave de API no vacía. Hollama y OrionChat también pueden apuntar a cualquier ubicación, pero la petición se origina en el navegador. Por tanto, el endpoint también debe ser accesible desde el navegador.

¿Por qué la interfaz de chat del navegador no puede acceder a Ollama?

Dos causas explican casi todos los casos. Ollama se enlaza a 127.0.0.1:11434 de forma predeterminada, por lo que un navegador de otra máquina nunca puede acceder a él hasta que cambie OLLAMA_HOST. Además, Ollama sólo acepta peticiones de origen cruzado desde localhost. Por eso, rechaza una página servida desde su propio dominio con No 'Access-Control-Allow-Origin' header is present on the requested resource hasta que ese origen figure en OLLAMA_ORIGINS. Si la página usa HTTPS y el endpoint usa HTTP, el navegador bloquea la petición como contenido mixto antes de que Ollama llegue a recibirla. Configure ambas variables en una sobrescritura de systemctl edit ollama.service o reenvíe el puerto mediante SSH para resolver el problema.