A local model running in a terminal is useful for scripting but poor for actual conversation — no history, no document uploads, no sharing with your team. A web frontend fixes that while keeping everything on your hardware.
Two projects dominate, and they solve different problems. Picking the wrong one means either fighting a model loader you did not need or missing features you did.
Open WebUI vs text-generation-webui
| Open WebUI | text-generation-webui | |
|---|---|---|
| Role | Frontend for an existing backend | Frontend + inference engine |
| Backend | Ollama or any OpenAI-compatible API | Built-in loaders (llama.cpp, Transformers, ExLlama) |
| Multi-user | Yes — accounts and roles | Not really |
| Document chat (RAG) | Built in | Via extensions |
| Model format flexibility | Whatever the backend supports | Very broad |
| Best for | A shared, polished chat service | Experimenting with loaders and quantizations |
For most people the answer is Open WebUI in front of Ollama: user accounts, conversation history, and document chat, with model management handled by Ollama. Choose text-generation-webui when the point is testing model formats and loaders rather than daily chat.
Open WebUI with Ollama
The container route is the least fragile, since Open WebUI moves quickly. Assuming Ollama is already running on the host:
$ docker run -d --name open-webui \
--add-host=host.docker.internal:host-gateway \
-e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
-v open-webui:/app/backend/data \
-p 127.0.0.1:3000:8080 \
--restart unless-stopped \
ghcr.io/open-webui/open-webui:main
# Open http://localhost:3000 — the FIRST account created becomes admin
Create the admin account immediately — the first registration gets administrator rights. Do that before the port is reachable by anyone else.
The volume holds everything — accounts, chat history, and settings live in open-webui:/app/backend/data. Back it up; losing it loses all conversations.
Bound to localhost on purpose — expose it through a reverse proxy with TLS rather than binding the container to 0.0.0.0.
To connect a different backend — vLLM or llama-server — point Open WebUI at its OpenAI-compatible endpoint instead of the Ollama URL. Both work, and you can register several.
text-generation-webui
This is the tool for trying loaders: the same UI can run a GGUF file through llama.cpp, a safetensors model through Transformers, or a quantized model through ExLlama, and let you compare them.
$ git clone https://github.com/oobabooga/text-generation-webui
$ cd text-generation-webui
# The launcher creates its own environment and installs dependencies
$ ./start_linux.sh
# UI on http://127.0.0.1:7860
Place model files in models/ — a .gguf file directly, or a directory of safetensors for the Transformers loader. Then choose a loader on the Model tab:
| Loader | Format | Notes |
|---|---|---|
| llama.cpp | GGUF | CPU/GPU split; works on any hardware |
| Transformers | safetensors | Full or bitsandbytes-quantized; see our quantization guide |
| ExLlama | Quantized GPU formats | Fast, GPU-only, needs the model to fit VRAM |
# Enable the OpenAI-compatible API alongside the UI
$ ./start_linux.sh --api
# API on port 5000, e.g. http://127.0.0.1:5000/v1/chat/completions
Running It as a Service
# /etc/systemd/system/textgen.service
[Unit]
Description=text-generation-webui
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=aiuser
WorkingDirectory=/opt/text-generation-webui
ExecStart=/opt/text-generation-webui/start_linux.sh --api
Restart=on-failure
RestartSec=15
# A runaway model load should not take the host down
MemoryMax=24G
[Install]
WantedBy=multi-user.target
$ sudo systemctl daemon-reload
$ sudo systemctl enable --now textgen
$ journalctl -u textgen -f
For AMD hardware, add the environment to the unit — for example Environment="HSA_OVERRIDE_GFX_VERSION=11.0.0" — and put the service user in the render and video groups, per our ROCm guide.
Exposing It Safely
Both tools can load models and, through extensions, execute code. Neither should sit directly on a network you do not control.
server {
listen 443 ssl;
server_name chat.example.com;
ssl_certificate /etc/letsencrypt/live/chat.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/chat.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
# Streaming responses need these
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_buffering off;
proxy_read_timeout 600;
}
}
proxy_buffering off — without it nginx buffers the streamed response and tokens arrive in bursts at the end instead of appearing as they generate.
Generous read timeout — long generations exceed the default and get cut off mid-answer.
Open WebUI has real auth — text-generation-webui does not have equivalent multi-user access control — put authentication in the proxy if more than one person can reach it.
Troubleshooting
Open WebUI shows no models — it cannot reach Ollama. From inside the container, confirm the base URL resolves — on Linux host.docker.internal requires the --add-host flag shown above.
Responses appear all at once — proxy buffering. Set proxy_buffering off.
Generation stops mid-answer behind a proxy — the proxy read timeout is too low for the response length.
Model fails to load in text-generation-webui — usually a loader/format mismatch — GGUF needs the llama.cpp loader, safetensors needs Transformers or ExLlama.
Out of memory on load — reduce GPU layers, lower the context length, or pick a smaller quantization.
Lost all chat history — the Open WebUI volume was removed. Only the named volume persists; treat it as a database and back it up.
Slow first response every time — the model is being unloaded between requests. Raise OLLAMA_KEEP_ALIVE on the Ollama side.
Frequently Asked Questions
What is the difference between Open WebUI and text-generation-webui?
Open WebUI is only a frontend — it needs a backend such as Ollama or any OpenAI-compatible server — and adds user accounts, chat history, and document chat. text-generation-webui includes its own inference loaders and is better for experimenting with model formats, but has no real multi-user support.
Which self-hosted ChatGPT alternative should I run on Linux?
Open WebUI in front of Ollama for most cases: it gives a polished multi-user chat service while Ollama handles models. Choose text-generation-webui when your goal is comparing loaders and quantization formats rather than daily conversation.
Why does my self-hosted chat UI show no available models?
The frontend cannot reach its backend. In Docker on Linux, reaching a host service needs --add-host=host.docker.internal:host-gateway and the backend URL set accordingly. Verify the endpoint responds from inside the container.
Why do responses arrive all at once instead of streaming?
The reverse proxy is buffering. Set proxy_buffering off in the nginx location block, and use proxy_http_version 1.1 with the upgrade headers so streamed tokens pass through as they are generated.
Is it safe to expose a local LLM web UI to the internet?
Only behind TLS and authentication. These tools can load models and, through extensions, run code, so treat access as trusted-users-only. Bind them to localhost and require a credential at the reverse proxy.