Alternativas a Open WebUI para un VPS con IP pública

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 tienen 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 resultan relevantes cuando el servidor es accesible desde Internet.

Cuatro aspectos 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 utiliza la interfaz es un megabyte que el modelo no puede utilizar.
• Autenticación. Algunos de estos proyectos tienen cuentas de usuario y roles. Otros dan por hecho 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 administració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í. 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 asignada 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 parte de esa memoria a medida que crece la conversación. Por eso el num_ctx que configure es una decisión de memoria tanto como de calidad. qwen3:8b con 5.2 GB no cabe en ese servidor. Esta es la situación que nunca cubren las comparativas de portátiles. En este caso, una interfaz de chat que ocupa unos cientos de megabytes puede determinar si el modelo se ejecuta. Si está dimensionando un servidor para algo muy superior a estas etiquetas, el cálculo para un modelo 27B en un VPS que usa sólo CPU muestra lo rápido que la interfaz deja de ser el factor determinante.

Mida el uso 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 de forma real, no un minuto después de iniciar el contenedor, porque la memoria relevante se asigna en el primer uso. Ollama también libera los pesos tras cinco minutos de inactividad. Por tanto, una lectura tomada entre conversaciones subestima el pico. El mensaje siguiente vuelve a pagar toda la carga, a menos que mantenga el modelo residente con keep_alive.

Open WebUI: sigue siendo la opción predeterminada 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 importa más que cualquier otra parte 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 administrador. Los registros posteriores se crean con el rol pending, el valor predeterminado documentado de DEFAULT_USER_ROLE. Por tanto, un desconocido que acceda a la página todavía no puede usar su modelo hasta que un administrador lo apruebe.

Open WebUI consume más memoria que los proyectos siguientes porque ofrece más funciones, 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 aproximadamente 500 MB por proceso de trabajo. Definir 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á definido, el pool usa un tamaño interno grande y cada conexión crea su propia caché de páginas y su propio mapa de memoria. Por tanto, en un equipo pequeño defina 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.

[
  {
    "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 el modelo no puede usar.

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 docker-compose.yml versionado, 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 guarde 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 en el mismo equipo, localhost dentro del contenedor hace referencia al propio contenedor, así que 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. Los chats 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 del README de este comando usa --rm. Esta opción elimina el contenedor cuando se detiene, por lo que la interfaz no vuelve a estar disponible después de un reinicio. Detrás de un proxy inverso, añada -e VITE_ALLOWED_HOSTS='chat.example.com', porque la imagen sólo permite el host localhost y responde a cualquier otra solicitud de hostname 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 chats permanece en el navegador y la aplicación elimina los chats más antiguos 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 acceder directamente a Ollama, por lo que Ollama debe escuchar en algo más que la interfaz de loopback, y 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 se 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. Aplique 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 abierto y los escáneres masivos encuentran rápidamente un puerto público nuevo. El túnel SSH que se muestra abajo evita todo este 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 realiza en el servidor. OLLAMA_BASE_URL=http://model-host:11434 lo dirige a Ollama. Para vLLM o cualquier otro servidor compatible con OpenAI, establezca 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 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, lo que basta para dirigir un agente de programación al modelo que ya aloja.

Hollama y OrionChat pueden apuntar a cualquier endpoint que escriba 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 caso 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 disponible. Este es también el momento de decidir si Ollama o vLLM debe atender las solicitudes, porque ambos se comportan de forma muy distinta 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, en un equipo que sólo use CPU, consulte cómo se compara Ollama con llama.cpp antes de elegir un runner.

Nunca publique una interfaz de chat sin inicio de sesió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 autoalojadas, por ejemplo bases de datos, registros de contenedores y servidores de CI», y recomienda colocarlo detrás de una VPN o de un proxy inverso con autenticación. Un proyecto sin ningún inicio de sesión merece como mínimo el mismo tratamiento.

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

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 su 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 lo confirma de forma aún más directa.

Desactivar el inicio de sesión de Open WebUI con WEBUI_AUTH=False es una configuración para un solo usuario en una máquina a la que nadie más puede acceder. Además, no se aplica a una instalación que ya tenga cuentas; 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, reenvíe lo que necesite 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. Para Hollama u OrionChat, reenvíe el puerto del modelo en el mismo comando con -L 11434:127.0.0.1:11434 y mantenga Ollama en loopback. Este patrón sólo es tan seguro como su configuración de SSH, así que combínelo con SSH con claves y un sshd reforzado.

Patrón dos: un proxy inverso que autentica antes de que la aplicación reciba la petición. Mantenga la aplicación en loopback, deje que el proxy gestione el puerto 443 y coloque el inicio de sesión único delante. 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), configure 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, y 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. Encamine 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 hardening que puede seguir. Si necesita LDAP o un panel de administración, ejecute LibreChat y confirme con docker stats que sus seis servicios, además del modelo, caben realmente antes de depender de él. Si sólo lo usará una persona en un equipo pequeño donde el modelo ya consume la mayor parte de la RAM, sirva Hollama u OrionChat mediante un túnel SSH y deje que el navegador mantenga 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 hardening lo describe 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: la primera cuenta se convierte en administradora y las posteriores permanecen pending hasta que se aprueban. Por tanto, es mucho más seguro que una interfaz sin inicio de sesión. Aun así, colóquelo detrás de un proxy inverso con TLS y, cuando sea posible, use inicio de sesión único. Publique el puerto del contenedor como 127.0.0.1:3000:8080 para que las reglas iptables propias de Docker no lo expongan a Internet sin que usted lo advierta.

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

Las alternativas basadas en 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 equipo con docker stats --no-stream, porque cambian según las funciones que active.

¿Pueden estas interfaces de chat usar un servidor 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 API no vacía. Hollama y OrionChat también pueden apuntar a cualquier ubicación, pero la petición procede de su navegador. Por tanto, el endpoint también debe ser accesible desde el navegador.

¿Por qué mi interfaz de chat del navegador no puede conectarse a Ollama?

Dos causas cubren casi todos los casos. Ollama se enlaza a 127.0.0.1:11434 de forma predeterminada, por lo que un navegador de otro equipo nunca puede conectarse 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 se incluya 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 pueda recibirla. Configure ambas variables en un override de systemctl edit ollama.service o reenvíe el puerto mediante SSH para eliminar el problema.