Open WebUI: What Self-Hosting an AI Chat Interface Actually Costs You

Open WebUI is a self-hosted web interface for talking to language models. It is the chat window, not the model — and that single distinction decides almost everything about what it costs you to run.

People find Open WebUI, see a one-line docker run, and assume the job is done in an afternoon. The container does start in about thirty seconds. What takes longer to notice is that you have just signed up to own a stateful web application: it has a database, uploaded files, user accounts, and an embedding store, and all of it lives in one volume you now have to keep alive. This is a walk through the parts that matter after the first docker run works.

Table of contents

• What Open WebUI actually is
• The four pieces you are actually deploying
• Running it with Docker
• Where the storage requirement bites
• Bundled Ollama versus a separate model backend
• Putting it behind a domain and TLS
• What this costs to run continuously
• How this fits the rest of the stack
• FAQ

What Open WebUI actually is

Open WebUI is a self-hosted frontend for language models. It gives you a chat interface, user accounts and roles, conversation history, document upload with retrieval, and a plugin surface. What it does not give you is a model. It talks to something else that does the inference.

That something else is one of two things:

• A local inference server on your own hardware, most commonly Ollama, reached over OLLAMA_BASE_URL.
• Any OpenAI-compatible HTTP endpoint, configured with a base URL and an API key.

Which one you pick is the fork in the road. The first needs a GPU and turns this into a hardware question. The second needs a modest CPU container and turns it into an ordinary web-app hosting question. Most people who search for this are quietly assuming the second and budgeting for it while reading tutorials written for the first.

The four pieces you are actually deploying

Strip away the marketing and a running Open WebUI is four things:

1. A container runtime. The official image is ghcr.io/open-webui/open-webui:main, published for the standard architectures.
2. A persistent volume mounted at /app/backend/data. This is not optional and it is not a cache.
3. An inference backend — either a local model server or a remote API endpoint.
4. A domain, a certificate, and a proxy in front that handles streaming responses correctly.

Every tutorial covers the first. Roughly half cover the second. Almost none cover the fourth, which is why the first production attempt usually ends with tokens arriving in one lump at the end instead of streaming.

Running it with Docker

The canonical start command from the project documentation looks like this:

docker run -d -p 3000:8080 \
  --add-host=host.docker.internal:host-gateway \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

If you are pointing it at a remote OpenAI-compatible endpoint instead of a local model server, you skip the host-gateway line and pass the credentials as environment variables:

docker run -d -p 3000:8080 \
  -e OPENAI_API_KEY=your_secret_key \
  -v open-webui:/app/backend/data \
  --name open-webui \
  --restart always \
  ghcr.io/open-webui/open-webui:main

The container listens on 8080 internally. The -p 3000:8080 mapping is a local-machine convenience; on a managed platform you declare the internal port and the platform owns the external one. Read the port mapping as a statement about the container, not about your public URL.

Where the storage requirement bites

The -v open-webui:/app/backend/data flag is the single most consequential character sequence in that command, and it is the one people drop when they are adapting the example to their own setup.

That directory holds the application database with your users and chat history, every file anyone has uploaded, the vector store built from those uploads, and your configuration. Delete the volume and you have not cleared a cache — you have deleted the product. There is no remote copy unless you made one.

Two practical consequences follow. First, the volume needs to be genuine persistent storage that survives a container restart and a redeploy, not a container-local layer that evaporates when the image is replaced. Second, it needs a backup, because a self-hosted tool with no backup story is a countdown rather than a deployment.

Size it generously. The database itself stays small for a long time, but document upload with retrieval turns disk into a function of how much your users paste in, and that number only goes one direction.

Bundled Ollama versus a separate model backend

The project publishes an image variant with Ollama bundled in, which is genuinely convenient and genuinely misleading about the cost. Bundling the model server into the same container does not make the model cheaper to run. It makes one container responsible for both a light web workload and a heavy inference workload, which is the wrong shape for scaling either.

The honest split:

• API-backed. Open WebUI runs as a small CPU container. Inference happens somewhere else and shows up on someone else’s bill, priced per token. Sizing the container is an ordinary web-app exercise.
• Self-hosted model. You need a GPU host with enough VRAM for the model weights you intend to load. That is a different category of purchase from web hosting, and it does not get cheaper by being in the same container as the chat interface.

If you are self-hosting mainly so that prompts do not leave your infrastructure, the second path is the point and the GPU cost is the price of the requirement. If you are self-hosting for control over the interface and the user accounts, the first path gives you that for the price of a small container.

Putting it behind a domain and TLS

Open WebUI streams responses. That means the proxy in front of it has to hold a long-lived connection open and forward chunks as they arrive, rather than buffering the response and delivering it complete. On nginx the two settings that matter are disabling proxy buffering and giving the read timeout enough room for a slow generation:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection upgrade;
    proxy_set_header Host $host;
    proxy_buffering off;
    proxy_read_timeout 600s;
}

Leave buffering on and everything still works, in the sense that answers arrive. They just arrive all at once after a long silence, and every user reports the app as broken. Leave the default read timeout in place and long generations get cut off mid-sentence with no error worth reading.

The certificate is the easier half. Point the domain at the deployment, let the platform or a certificate client handle issuance and renewal, and keep the renewal automatic. A manually renewed certificate on an internal tool is a ninety-day timer nobody has set a reminder for.

What this costs to run continuously

For the API-backed path, Open WebUI is not a demanding application. It is a Python web process serving a handful of concurrent users, and it spends most of its life waiting on a network call to the inference endpoint. Memory is the constraint that shows up first, mostly from document processing, not from serving chat.

Practically: start on something in the 1GB range if a small team will be using it, and keep an eye on memory during document ingestion rather than during ordinary chat. CPU is rarely the bottleneck; the container is I/O-bound on the model call.

On RunxBuild that is a Docker service pointed at the published image, with persistent storage attached for /app/backend/data, environment variables for the endpoint credentials, a custom domain with the certificate handled, and runtime logs in the same place as the deploy logs. The general plan ladder starts at $4 for the Dev plan and $6 for Basic, with 1GB at $13 on BasicMini — the ladder is CPU and RAM, so it fits the API-backed path and not the GPU one. Autoscaling between a floor and a ceiling plan covers the case where the tool gets popular internally faster than expected.

The failure mode worth designing against is not cost. It is the volume. A container you can rebuild in thirty seconds sitting on top of a volume you cannot rebuild at all is a specific kind of trap, and the backup is the whole answer to it.

How this fits the rest of the stack

Open WebUI is a small application with a large dependency. The interface is easy; the model backend and the data volume are where the real decisions live. Decide the inference path first, because it determines whether you are buying a $6 container or a GPU host, and those are not the same conversation. Then attach real storage, back it up, and put a streaming-aware proxy in front. If you want the whole thing costed before you commit, the RunxBuild hosting calculator puts the container, the storage, and the bandwidth on one page as separate line items, which is usually enough to settle the argument about whether self-hosting is worth it for your team.

Useful related references:

• Best Open Source LLM: Pick by VRAM First, Benchmark Second
• Retool Self-Hosted: The Four Real Paths and the Costs the Pricing Page Skips
• Deploy a Docker Container for Free
• Docker services on RunxBuild
• Storage on RunxBuild

FAQ

Is Open WebUI free?

The project is open source and there is no licence fee for running it yourself. The cost is infrastructure: the container, the persistent volume, the domain, and whatever you spend on inference. Self-hosted does not mean free, it means the bill is itemised differently.

Does Open WebUI need a GPU?

Not by itself. Open WebUI is a web interface and runs happily on a CPU-only container. A GPU is needed only if you are also self-hosting the model that it talks to. Point it at a remote OpenAI-compatible endpoint and the GPU question disappears entirely.

What happens if I lose the Open WebUI data volume?

You lose every user account, every conversation, every uploaded document, and the vector store built from them. The directory mounted at /app/backend/data is the entire state of the application. Treat it as a database, back it up on a schedule, and test the restore at least once.

Why do responses arrive all at once instead of streaming?

Almost always proxy buffering. A reverse proxy in front of the container is collecting the whole response before forwarding it. Disable buffering for that location and raise the read timeout so long generations are not cut off partway through.

Can I run Open WebUI without Ollama?

Yes. Ollama is one supported backend, not a requirement. Any OpenAI-compatible HTTP endpoint works — set the base URL and API key as environment variables and the interface behaves the same. This is the path most teams actually want, because it removes the hardware question.