How to self-host a ChatGPT alternative

Open WebUI is an interface. The model behind it generates the text, and wherever that model runs is where your prompts are sent. A self-hosted interface pointed at a hosted API still sends every prompt to that provider. Sometimes that is what you want. Decide on purpose.

For a pilot, Ollama on the same machine is the shortest path: prompts never leave the box. For a shared team, a vLLM server on a GPU machine handles many users better. For tasks the data class allows, you can add a hosted model later through a gateway. Write the choice into your acceptable-use note so users know which data may go where.

On Linux, the Ollama documentation gives a one-line installer, and the service runs under systemd. Pull a model, run it once to see that it works, then test the API. The Ollama quickstart uses gemma4:e2b as its example, which is a small model suited to a first test. Pick a larger one later once you know how much memory you have; our guide to running LLMs locally covers sizing.

By default Ollama listens on 127.0.0.1 port 11434. That is the right default; you will change it in the next step only if you need to.

Open WebUI will run in a container, and the container cannot see 127.0.0.1 on the host. The Open WebUI troubleshooting page gives three fixes for the common "server connection error": run the container with --network=host, set OLLAMA_HOST=0.0.0.0 so Ollama accepts connections beyond localhost, or use host.docker.internal as the hostname. The quick-start command already adds --add-host=host.docker.internal:host-gateway for that third route.

The Ollama FAQ shows how to set the variable for a systemd service: edit the service with systemctl edit ollama.service, add the environment line, then reload and restart. Be careful with what this does. Ollama has no login. Listening on 0.0.0.0 makes it answer anyone who can reach port 11434, so block that port at the firewall for everything except the Docker network.

If you would rather avoid this step entirely, Open WebUI publishes an image with Ollama bundled in (the :ollama tag). It is simpler, but it ties the model and the interface together in one container, which is harder to scale and upgrade separately.

Generate a secret key first. The Open WebUI documentation says the key must persist: without it, every time the container is recreated everyone is logged out. Then run the container.

This is the default command from the Open WebUI quick start with three changes. The port binds to 127.0.0.1 so nothing is exposed until your proxy is ready. OLLAMA_BASE_URL points at the host through host.docker.internal. And you should replace :main with a specific version tag for anything beyond a trial; the docs say :main is a rolling tag, and the update page warns it "can include breaking changes without warning". Look up the current release tag on the project's releases page and use that.

The open-webui volume holds your chats, users and settings. The documentation puts it bluntly: never run without it.

Browse to http://localhost:3000 and sign up. The Open WebUI roles documentation says the very first account on a fresh installation is automatically given the Admin role. That makes the first sign-up an important moment: do it yourself, straight after the container starts, before anyone else knows the address.

Later sign-ups get the Pending role by default, which has no access until an admin approves it. The environment reference lists DEFAULT_USER_ROLE with options pending, user and admin, and a default of pending, and ENABLE_SIGNUP for toggling account creation. One quirk catches people out. Settings marked as persistent config apply from the environment only on the first launch; after that the value stored in the database wins. So to change sign-up behaviour later, use the admin settings in the interface, or set ENABLE_PERSISTENT_CONFIG to False and accept that changes made in the UI will then not be saved.

If you will use single sign-on, plan it now. The reference documents ENABLE_OAUTH_SIGNUP (default False) and notes that OPENID_PROVIDER_URL should be set for the Google and Microsoft sign-in options, otherwise logout may not work. Follow the provider-specific section in the environment reference for the rest of the variables.

Ollama models appear on their own once OLLAMA_BASE_URL is right. For anything else, the Open WebUI documentation says adding a provider is "as simple as entering a URL and API key" in Settings, Admin, Connections. For an OpenAI-compatible server such as vLLM, the base URL ends in /v1.

You can also set these by environment variable. OPENAI_API_BASE_URL defaults to https://api.openai.com/v1, and OPENAI_API_KEY holds the key. Take that default seriously. If someone puts a hosted key in there, prompts go to that provider, so decide who may add connections, and keep provider keys in one place under an owner. A gateway in front of all model traffic is the clean answer once you have more than one backend; see how to set up an LLM gateway.

Test with a sentence that contains nothing sensitive, then check on the model server that the request arrived there. That is how you prove where prompts actually go.

Open WebUI separates roles (Admin, User, Pending) from groups and permissions. Roles set the baseline trust level. Groups organise users and grant additional permissions or shared access to resources, and permissions are granular feature flags such as whether a user can delete chats or use web search. The model is additive: users start with their default rights and group membership adds capabilities. So keep the default role minimal and grant more through groups.

Admin access to other people's conversations is not automatic. The documentation says that the ENABLE_ADMIN_CHAT_ACCESS=False variable can stop admins viewing user chats. Decide your position on this before you tell staff the tool is private, and tell them what you chose. If your policy needs administrators to review conversations, say so in the acceptable-use note instead of leaving people to assume.

Finally, write a short note for users that says which data classes may be entered, which models are connected and where they run, how long chats are kept, and who to ask for help. A one-page note does more for privacy than most settings.

Browsers and password managers behave properly only over HTTPS, and sign-in tokens should not cross a network in clear text. Caddy keeps this short: it provisions certificates automatically for a public domain name. The Caddy quick start shows a site address followed by a reverse_proxy line, then caddy run from the same directory. Caddy's documentation also states that its proxy supports WebSocket connections, which chat interfaces use for streaming.

If the server has no public DNS name, automatic certificates will not work. Use an internal certificate authority or your organisation's existing proxy and certificate process instead. Whatever you use, open the firewall for the proxy port only, and leave port 3000 bound to 127.0.0.1 as in step 4.

Back up before every upgrade. The Open WebUI update page warns that database migrations are one-way: rolling back to an older version will not undo them, so the only safe rollback is to restore from a backup taken before the update. It gives a backup command that archives the volume with a throwaway container.

The update itself is: remove the container, pull the image, run the same command again. Your data persists in the volume. Pin the version tag so that "update" means a version you chose, tested on a copy first if the interface matters to many people.

Test the restore once. A backup that has never been restored is a guess.