Open WebUI alternative wey good for VPS na which?

Which Open WebUI alternative dey belong for VPS

People almost always compare Open WebUI alternatives for laptop, where RAM cheap and nothing dey listen on public address. VPS change both facts, and this one change the ranking. Open WebUI remain the correct default as soon as a second person log in, because e ship with real user accounts and admin panel. The lighter projects win when the interface dey compete with the model for the last gigabyte of RAM. The price for this advantage na authentication: dem no get any.

Everything below come from each project own documentation, wey dem read for August 2026. The four axes na the ones wey only show once the box fit reach internet.

Four axes wey only matter for public IP

• Memory beside the model. The model server na the process wey dey cost pass for the box. Every megabyte wey the interface hold na megabyte wey the model no fit use.
• Authentication. Some of these projects get user accounts and roles. Others assume say na only dem dey run for your laptop, and dem no get login at all.
• Remote inference. UI wey fit only reach 127.0.0.1:11434 go force the model to dey for the same box with the interface.
• Upkeep. One container wey get SQLite file na different work from six containers wey get MongoDB and vector database behind dem.

How much RAM the model dey leave for the interface

The interface no be the biggest thing for the server. Na the model be that. Published download sizes give you the minimum, because the weights must dey resident while the model dey answer, and real memory use dey higher than the download size once the context cache don allocate.

[
  {
    "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"
  }
]

Na the figures wey the Ollama library pages print for August 2026. Dem na published sizes, no be measurements. For a 4 GB VPS, qwen3:4b for 2.5 GB go leave less than 1.5 GB for the operating system and everything else, and the context cache go take part of that space as the conversation dey grow. qwen3:8b for 5.2 GB no fit run for that server at all. Na this situation laptop roundups no dey cover, and na here chat interface wey dey hold a few hundred megabytes fit decide whether the model go run. If you dey size a server for something well above these tags, the calculation for a 27B model on a CPU-only VPS show how fast the interface stop to be the number wey dey decide anything.

Measure am instead of trusting any number for a roundup, including this one. Run docker stats --no-stream one hour into real use, no be one minute after the container start, because the memory wey matter dey allocate when you use am for the first time.

Open WebUI: still be the default for more than one user

Open WebUI dey run from one image and e dey keep im data for one volume.

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

The command for the project README dey publish -p 3000:8080, wey dey listen on every interface. The 127.0.0.1: prefix keep am for loopback. For VPS, that prefix matter pass anything else for the line, because Docker dey write im own iptables rules and published port dey ignore your ufw deny rules.

Reach the page through tunnel or proxy, as dem describe below, then create the first account. That account become the administrator. Later signups dey get role pending, wey na the documented default of DEFAULT_USER_ROLE, so stranger wey reach the page still no fit use your model until admin approve am.

Open WebUI dey use more memory than the projects below because e dey do more things, and im performance page name the parts wey dey cost memory. The default embedding engine dey load sentence-transformers model inside the container, documented at around 500 MB for each worker process. Setting RAG_EMBEDDING_ENGINE=ollama hand that work over to the model server wey you already dey run. AUDIO_STT_ENGINE=webapi stop am from loading local speech-to-text model. For SQLite when DATABASE_POOL_SIZE no set, the pool dey fall back to large internal size, and each connection dey grow im own page cache and memory map. So for small box, set DATABASE_POOL_SIZE=8 and DATABASE_SQLITE_PRAGMA_MMAP_SIZE=0. ENABLE_AUTOCOMPLETE_GENERATION=False stop the interface from asking the model for completion while user still dey type.

LibreChat: multi-user, with a stack behind am

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

The interface dey answer for port 3080. LibreChat na the one to check when you need identity system instead of ordinary login box: e document LDAP and OAuth2 logins, and e package admin panel for users and roles. This capability come with one stack.

[
  {
    "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"
  }
]

The default compose file dey start 6 services: api, admin panel, MongoDB, Meilisearch, pgvector, RAG API. None of dem be the model. MongoDB and pgvector each need memory for demself, and for 4 GB box, na memory wey the model need be this one.

Upgrades na git operation, and na this part people dey get wrong.

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

git pull go stop with conflict if you edit the tracked docker-compose.yml, then the upgrade go remain half applied. Put your changes for docker-compose.override.yml, wey the project provide for this purpose, and keep secrets for .env. Both files no dey tracked, so git pull go leave dem alone.

Point LibreChat to your own model server with custom endpoint for 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"

Replace model-host with the address of the box wey dey run Ollama. The apiKey field must dey there even though Ollama no dey use the value, so placeholder dey okay. If LibreChat dey run for Docker and Ollama dey run for the same machine, localhost inside the container mean the container itself, so use host.docker.internal there instead.

Hollama and OrionChat: browser dey do the work

Hollama dey serve one browser application from one small container. Chats dey for your browser storage, no be for server.

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

The README version of this command dey use --rm. This one dey delete the container when e stop, so the interface no go come back after reboot. If reverse proxy dey in front, add -e VITE_ALLOWED_HOSTS='chat.example.com', because the image dey allow only host localhost. For any other hostname, e go return blocked-host error instead of the app.

OrionChat dey go further, and e no get server component at all. Clone the repository, then serve the folder with the web server wey you already dey run, or open index.html from disk. API keys dey stored for browser's localStorage. Chat history dey remain for browser, and the app dey delete the oldest chats once the count pass 512.

Neither project get login, because neither one get server wey fit check login. For laptop, this one no be problem. For VPS, e mean say you must never publish the page on 0.0.0.0. E also mean one thing wey easy to miss: na browser dey call the model, no be server.

This fact decide where you fit use these two. Your browser must reach Ollama directly, so Ollama must listen beyond loopback. Ollama no get authentication of any kind. Two browser rules follow from this. Page wey HTTPS serve no fit call plain HTTP endpoint. Console go print 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.. Any call to another origin go get refused with has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource until you allow that origin.

Ollama documented method to change either setting na systemd override.

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 suppose now print 0.0.0.0:11434 for where e print 127.0.0.1:11434 before. Make this change only when firewall or authenticating proxy already dey control who fit reach the port. Open 11434 na open model server, and mass scanners dey reach new public port quickly. The SSH tunnel below avoid the whole matter: page go then run on a localhost origin, wey Ollama dey permit by default, and the port no go leave the box.

E fit each one use remote Ollama or vLLM endpoint

Open WebUI fit, and na server side dem dey make the connection. OLLAMA_BASE_URL=http://model-host:11434 dey point am to Ollama. For vLLM or any other OpenAI-compatible server, set OPENAI_API_BASE_URL=http://model-host:8000/v1 with non-empty OPENAI_API_KEY, and keep the /v1 suffix, because e dey required. OPENAI_API_BASE_URLS fit accept several backends wey semicolons separate.

LibreChat fit too, through the baseURL of the custom endpoint wey we show above. That request still comot from the server, so browser rule no apply. The same base URL and the same placeholder key go work outside chat window too. Na everything wey you need to point coding agent to the model wey you don already host.

Hollama and OrionChat fit point to any endpoint wey you type for their settings, but the request go comot from your browser. Everything for the section above apply to dem, and no other thing for here.

The most useful thing wey remote endpoint give you na to separate interface from model. Put interface for small box, and put model where memory dey. This na also the time to decide whether Ollama or vLLM suppose serve the requests, because the two behave very differently when several people dey talk to the model at the same time. If model server never dey, start by running Ollama for VPS, and for CPU-only box, read how Ollama compare with llama.cpp before you choose runner.

Never publish a chat UI with no login on 0.0.0.0

Open WebUI hardening page talk say the project “build for private, trusted networks, like other self-hosted infrastructure such as databases, container registries, and CI servers”, and e tell you make you put am behind VPN or reverse proxy wey get authentication. Project wey no get login at all deserve at least the same protection.

Check wetin dey listen before you trust anything.

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

Line wey read 127.0.0.1:3000 na wetin you want. Line wey read 0.0.0.0:3000 mean say your chat interface dey public internet. From your own machine, curl -sI http://YOUR.VPS.IP:3000 wey dey answer HTTP/1.1 200 OK talk the same thing more directly.

To turn off Open WebUI login with WEBUI_AUTH=False na single-user setting for machine wey nobody else fit reach. E still no go apply to installation wey don get accounts already, with message You can't turn off authentication because there are existing users.

Pattern one: bind to loopback and reach am over SSH. Publish every port on 127.0.0.1, then forward wetin you need: ssh -N -L 3000:127.0.0.1:3000 you@vps.example.com, and open http://localhost:3000 for your laptop. Nothing dey published, so nothing fit scan am. For Hollama or OrionChat, forward the model port for the same command with -L 11434:127.0.0.1:11434 and leave Ollama on loopback. This pattern only strong as your SSH setup, so join am with key-only SSH and hardened sshd.

Pattern two: reverse proxy wey authenticate before app see the request. Keep the app on loopback, make the proxy own port 443, and put single sign-on for front. Traefik wey Docker Compose labels dey drive with Authentik as identity provider give every app for the machine one login and one certificate. With Open WebUI behind TLS (transport layer security), set WEBUI_SESSION_COOKIE_SECURE=true and WEBUI_SESSION_COOKIE_SAME_SITE=strict. Reduce JWT_EXPIRES_IN from the default four weeks too, because Open WebUI document say without Redis, sign-out no invalidate the token: e remain usable until e expire by itself.

Pattern two no fit protect browser-only projects. Proxy wey dey in front of the page no protect the model endpoint, and fetch from that page go another hostname no carry your session cookie, so authenticating proxy wey dey in front of Ollama answer with redirect to login form and the chat fail. Either route the model endpoint under the same hostname as the page, or use pattern one.

Wetin to pick

If na other people go use am, run Open WebUI. E get real accounts, new users go enter approval queue, and the maintainers publish hardening guidance wey you fit follow. If you need LDAP or an admin panel, run LibreChat, and confirm with docker stats say its six services plus your model fit run properly before you depend on am. If na one person dey use small box where the model don already take most of the RAM, serve Hollama or OrionChat through an SSH tunnel and make the browser hold the state. For VPS, wrong answer na to publish any of dem on 0.0.0.0 without login in front.

FAQ

Open WebUI safe to expose directly on public IP?

Its hardening page describe am as software for private, trusted networks, for the same category as database or CI server. E get real accounts, and the first account become administrator while later ones remain pending until person approve dem, so e safer well-well pass UI wey no get login. Still put am behind reverse proxy with TLS and, where you fit, single sign-on. Publish the container port as 127.0.0.1:3000:8080 so Docker own iptables rules no go open am to internet without you knowing.

Which Open WebUI alternative dey use the least RAM for VPS?

The browser-based ones, Hollama and OrionChat, because na client dey run the application. The server only send static files, and OrionChat no need application container at all. Open WebUI keep Python process, database and, by default, local embedding model for memory, and documentation put am around 500 MB per worker for the embedding model alone. Confirm the numbers for your own box with docker stats --no-stream, because dem dey change based on the features wey you turn on.

These chat UIs fit use Ollama server for another host?

Open WebUI and LibreChat fit, and na their server dey make the connection, so browser rule no apply. Set OLLAMA_BASE_URL for Open WebUI, or baseURL inside custom endpoint for LibreChat. For vLLM or another OpenAI-compatible server, use OPENAI_API_BASE_URL with /v1 suffix and non-empty API key. Hollama and OrionChat fit also point anywhere, but na your browser dey send the request, so the endpoint must dey reachable from your browser too.

Why my browser chat UI no fit reach Ollama?

Two causes cover almost every case. Ollama dey bind to 127.0.0.1:11434 by default, so browser for another machine no go reach am until OLLAMA_HOST change. And Ollama only accept cross-origin requests from localhost, so e go reject page wey your own domain serve with No 'Access-Control-Allow-Origin' header is present on the requested resource until you list that origin inside OLLAMA_ORIGINS. If the page dey use HTTPS and the endpoint dey use HTTP, browser go block the call as mixed content before Ollama even see am. Set both variables inside systemctl edit ollama.service override, or forward the port through SSH and the problem go disappear.