Which Open WebUI alternative fit VPS best?

Which Open WebUI alternative dey fit VPS

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

Everything for here 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 axis wey matter only for public IP

• Memory beside the model. Model server na the process wey dey use plenty resources for the machine. Every megabyte wey the interface hold na one megabyte wey 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 reach only 127.0.0.1:11434 go force model to dey for the same machine with the interface.
• Upkeep. One container with SQLite file na different work from six containers with 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 box. 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 after 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 show for August 2026. Dem na published sizes, no be measurements. For 4 GB VPS, qwen3:4b at 2.5 GB go leave less than 1.5 GB for the operating system and everything else. The context cache go also use more memory as conversation dey grow. Na why the num_ctx wey you set be memory decision as much as quality decision. qwen3:8b at 5.2 GB no fit run for that box at all. Na this kind situation laptop roundups no dey cover. Chat interface wey hold few hundred megabytes fit decide whether the model go run. If you dey size box for something well above these tags, the arithmetic for 27B model for CPU-only VPS show how quickly the interface stop to be the number wey decide anything.

Measure instead of trusting any number for roundup, including this one. Run docker stats --no-stream one hour after real use don start, no be one minute after the container start, because the memory wey matter dey allocate when you first use am. Ollama also release the weights after five minutes of idle time. So, reading wey you take between conversations go understate the peak. The next message go load everything again unless you keep the model resident with keep_alive.

Open WebUI: still the default for more than one user

Open WebUI na 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 publishes -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 every other thing 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 we describe below, then create the first account. That account become the administrator. Later signups dey get role pending, wey be the documented default of DEFAULT_USER_ROLE. So, stranger wey reach the page still no fit use your model until admin approve dem.

Open WebUI dey use more memory than the projects below because e dey do more work, and im own performance page name the parts wey dey cost memory. The default embedding engine load sentence-transformers model inside the container, and the documentation talk say e dey use 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. Each connection then 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, wey get 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 only login box: e document LDAP and OAuth2 logins, and e package admin panel for users and roles. This capability dey come with 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 na the model. MongoDB and pgvector each need memory for demself, and for 4 GB box, na memory wey the model need.

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 apply halfway. 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. Chat dey live 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. E dey delete the container when e stop, so interface no go come back after reboot. If reverse proxy dey front, add -e VITE_ALLOWED_HOSTS='chat.example.com', because the image allow only host localhost and e dey answer request for any other hostname with blocked-host error instead of the app.

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

Neither project get login, because neither get server wey fit check am. 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 on more than 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 dey 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 where e printed 127.0.0.1:11434 before. Only make this change when firewall or authenticating proxy already dey control who fit reach the port, because open 11434 mean 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 allow by default, and the port no go leave the box.

Each one fit 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 go 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 na requirement. OPENAI_API_BASE_URLS fit accept several backends wey semicolons separate.

LibreChat fit do am through the baseURL for the custom endpoint wey we show above. That request still dey leave the server, so browser rule no apply. The same base URL and same placeholder key fit work outside chat window too. Na only this you need to point coding agent to the model wey you already host.

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

The most useful benefit of remote endpoint na to separate interface from model. Put the interface for small box, and put the 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 once. If model server never exist, start by running Ollama on a 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 “na 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, if curl -sI http://YOUR.VPS.IP:3000 answer HTTP/1.1 200 OK, e 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 also no go apply to installation wey already get accounts, 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 inside 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 app for loopback, make proxy own port 443, and put single sign-on for front. Traefik wey Docker Compose labels 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. Make JWT_EXPIRES_IN shorter than the four-week default too, because Open WebUI document say without Redis, sign-out no invalidate the token: e go remain usable until e expire by itself.

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

Wey one 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 admin panel, run LibreChat, then use docker stats confirm say the six services plus your model fit run well 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 SSH tunnel and make browser hold the state. For VPS, the wrong answer na to publish any of dem for 0.0.0.0 without login in front.

FAQ

Open WebUI safe to expose directly for public IP?

Open WebUI hardening page describe am software for private, trusted networks, like database or CI server. E get real accounts, and the first account become administrator, while later accounts 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, if 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 the application dey run for the client. Server only dey 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. Documentation put the embedding model alone around 500 MB per worker. 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 the /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 dey cover almost every case. Ollama dey bind 127.0.0.1:11434 by default, so browser for another machine no go reach am until OLLAMA_HOST change. Ollama also dey accept cross-origin requests from localhost only, 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 page use HTTPS and endpoint 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.