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

Qué alternativa a Open WebUI conviene usar 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 cuando inicia sesión una segunda persona, porque incluye cuentas de usuario reales y un panel de administración. Los proyectos más ligeros son mejores 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 siguiente procede de la documentación de cada proyecto, consultada en agosto de 2026. Los cuatro criterios son los que sólo aparecen cuando el servidor es 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 utiliza la interfaz es un megabyte que no puede utilizar el modelo.
• 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 la 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 más 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 nunca cubren las comparativas de portátiles. También es el punto en el que una interfaz de chat que ocupa unos cientos de megabytes determina si el modelo puede ejecutarse.

Mida el consumo 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. La memoria relevante se asigna cuando se usa el modelo por primera vez.

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

Open WebUI se ejecuta a partir de una sola imagen y guarda sus datos en un solo 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 ambos más abajo, y cree la primera cuenta. Esa cuenta se convierte en la cuenta de administrador. Los registros posteriores se crean con el rol pending, el valor predeterminado documentado de DEFAULT_USER_ROLE, por lo que 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 alrededor de 500 MB por proceso de trabajo. Definir RAG_EMBEDDING_ENGINE=ollama delega ese trabajo al 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 elevado 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 impide que la interfaz solicite una finalización al modelo mientras el usuario todavía está escribiendo.

LibreChat: multiusuario, 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. Debe elegir LibreChat cuando necesite un sistema de identidades en lugar de un simple formulario de inicio de sesión: documenta 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 ha editado 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, así que debe usar 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 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 un reinicio. 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 las peticiones de 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 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 se pasa por alto con facilidad: el navegador llama al modelo, no el servidor.

Este hecho determina dónde se pueden utilizar. El navegador debe poder 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 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. Haga este cambio sólo cuando un firewall o un proxy con autenticación ya controle quién puede acceder al puerto, porque un puerto 11434 abierto expone un servidor de modelos y los escáneres masivos llegan rápidamente a los puertos públicos nuevos. El túnel SSH de abajo 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 realiza 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.

Hollama y OrionChat pueden apuntar a cualquier endpoint que introduzca en su configuración, pero la solicitud sale de su 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 usar un endpoint remoto. Coloque la interfaz en un equipo pequeño y el modelo donde haya memoria suficiente. Este también es el momento de decidir si Ollama o vLLM debe atender las solicitudes, porque ambos se comportan de forma muy distinta cuando varias personas interactúan con el modelo al mismo tiempo. Si el servidor del modelo todavía no existe, empiece por ejecutar Ollama en un VPS y, si usa un equipo que sólo tiene CPU, consulte cómo se compara Ollama con llama.cpp antes de elegir un ejecutor.

No publique una interfaz de chat sin inicio de sesión en 0.0.0.0

La página de refuerzo de Open WebUI indica que el proyecto está "diseñado para redes privadas y de confianza, como otras infraestructuras autohospedadas, 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 esos servicios.

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

Una línea que muestre 127.0.0.1:3000 es lo que necesita. 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 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 solo usuario y para una máquina a la que nadie más pueda 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, 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 nada, por lo que nada puede escanearse. 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. El nivel de seguridad de este patrón depende de la configuración de SSH, así que combínelo con SSH con claves y un sshd reforzado.

Patrón dos: un reverse proxy que autentica antes de que la aplicación reciba la petición. Mantenga la aplicación en loopback, haga que el proxy gestione el puerto 443 y coloque el inicio de sesión único delante. Traefik gestionado mediante etiquetas de Docker Compose 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 respecto a su valor predeterminado de cuatro semanas, porque la documentación de Open WebUI indica que, sin Redis, cerrar 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 de esa página a otro nombre de host no incluye la cookie de sesión. Por ello, el proxy autenticador 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.

Elige una opción

Si lo van a usar otras personas además de usted, ejecute Open WebUI. Tiene cuentas reales, los usuarios nuevos pasan a una cola de aprobación y sus mantenedores publican recomendaciones de endurecimiento 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 en el sistema 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. La respuesta incorrecta en un VPS 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 refuerzo de seguridad 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, y la primera cuenta se convierte en administrador mientras las posteriores permanecen en pending hasta que se aprueban. Por eso 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 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 puedan abrirlo a Internet sin que lo advierta.

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

Las 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 servidor 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 regla 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 lo que 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 explican casi todos los casos. Ollama se enlaza a 127.0.0.1:11434 de forma predeterminada, por lo que un navegador en 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 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 la reciba. Configure ambas variables en una sobreescritura de systemctl edit ollama.service, o reenvíe el puerto mediante SSH y el problema desaparecerá.