What you actually need

Open WebUI itself is light. It is a Python app with a SQLite database by default, and it idles well under 1 GB of RAM. The model is the expensive part. On a CPU-only server the model has to fit in RAM next to the OS and Open WebUI, and it will be slow compared to a GPU. Realistic numbers from the Ollama library pages:

• llama3.2:1b is about 1.3 GB
• llama3.2:3b is about 2.0 GB
• qwen3:4b is about 2.5 GB
• gemma3:4b is about 3.4 GB
• qwen3:8b is about 5.2 GB
• gemma3:12b is about 8.2 GB

A rough rule that has held up for us: take the model file size, add 1 to 2 GB for context and Open WebUI, add the OS. So a 4 GB VPS is comfortable with a 1B or 3B model, an 8 GB box can run a 4B model or squeeze in an 8B one, and anything bigger wants 16 GB. More cores help token speed; 2 vCPU works, 4 feels noticeably better. Expect a few tokens per second on small models, not ChatGPT speed.

Sources: https://ollama.com/library/llama3.2, https://ollama.com/library/qwen3, https://ollama.com/library/gemma3

Option A: Ollama on the host, Open WebUI in Docker

This is the setup we recommend, because you can update each piece on its own.

Install Ollama with the official script (https://docs.ollama.com/linux):

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.2:3b
ollama run llama3.2:3b "say hi"

Ollama now runs as a systemd service and listens on 127.0.0.1:11434. That address is the first trap. A Docker container can't reach the host's 127.0.0.1, because inside the container localhost means the container itself.

You have two ways around it. The first is to run Open WebUI on the host network, which is the fix the Open WebUI troubleshooting page gives (https://docs.openwebui.com/troubleshooting/connection-error/):

docker run -d --network=host \
  -v open-webui:/app/backend/data \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:main

With --network=host the port mapping goes away and the UI is on port 8080, not 3000. People miss that and think it didn't start.

The second way keeps normal Docker networking and uses host.docker.internal, which is what the quick start does (https://docs.openwebui.com/getting-started/quick-start/):

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

For this one, Ollama has to listen on more than loopback, because host.docker.internal resolves to the Docker bridge address. The Ollama FAQ (https://docs.ollama.com/faq) says to do it through systemd:

sudo systemctl edit ollama.service
# add under [Service]:
# Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl daemon-reload
sudo systemctl restart ollama

Now the important part. 0.0.0.0 means every interface, including the public one. Ollama has no authentication. If your VPS has no firewall, you've just published a free, open model endpoint to the internet. Block it:

sudo ufw allow OpenSSH
sudo ufw deny 11434/tcp
sudo ufw enable

Ollama runs on the host, so ufw does cover it. (The well-known "Docker bypasses ufw" problem applies to ports that containers publish, like Open WebUI's 3000, so don't rely on ufw for those either.) An even tighter option is to bind Ollama to the Docker bridge IP only, often OLLAMA_HOST=172.17.0.1:11434 (check with ip addr show docker0), or to stick with the host-network option above.

Option B: the bundled image

If you just want one container, Open WebUI ships an image with Ollama inside. The CPU-only command from the quick start is:

docker run -d -p 3000:8080 \
  -v ollama:/root/.ollama \
  -v open-webui:/app/backend/data \
  --name open-webui --restart always \
  ghcr.io/open-webui/open-webui:ollama

It is the quickest way to try things. The downside is that Ollama and Open WebUI update together, and model files live in the ollama volume, so don't delete it when you recreate the container.

First login and pulling models

Open http://your-server:3000 (or :8080 for host networking). The first account you create becomes the admin, so do this right away rather than leaving a fresh instance open on a public IP. You can pull models from Admin Settings, or from the shell with ollama pull. Both end up in the same place.

Pitfalls we see a lot

1. "Ollama connection failed" in the UI. Nine times out of ten it's the localhost problem above. Test from inside the container: docker exec -it open-webui curl -s http://host.docker.internal:11434/api/tags. If that fails, it's networking, not Open WebUI.
2. The box freezes when you load a model. The model didn't fit. Linux starts swapping or the OOM killer takes out something random. Use a smaller model, or a lower quantization tag.
3. Sessions log out after every restart. Set a fixed WEBUI_SECRET_KEY so the key doesn't change between container recreations (see https://docs.openwebui.com/reference/env-configuration/).
4. Upgrading with :main. The updating docs (https://docs.openwebui.com/getting-started/updating/) suggest pinning a version tag like :v0.x.y in production and backing up the open-webui volume first. Database migrations run on start and don't always roll back cleanly.
5. Mixing local and API models. Small CPU models are fine for drafts, summaries and private notes. For hard reasoning, add an OpenAI-compatible connection in the admin settings and keep both in one UI. That mix is what makes a small VPS genuinely useful.

Where this leaves you

You now have a private chat UI talking to a local model, on a box that costs a few dollars a month, with Ollama not exposed to the world. From here the usual next steps are a reverse proxy with TLS, backups of the data volume, and a pinned image tag.

If you'd rather skip the server work, this is what we do at AIHostBox (https://aihostbox.com/apps/open-webui/). We set up Open WebUI on its own single-tenant CPU server for you, put it on your domain with TLS, back it up nightly and keep it patched, starting at $5.99/mo (see pricing) for 2 GB RAM and 1 vCPU. If you get stuck on something like the Ollama networking above, you can just ask us; we've done this setup many times and we're happy to walk you through it. Want to run local models on the same box? Pick a bigger plan, since the RAM math above still applies.

Open WebUI has become the default "private ChatGPT" front end. The project has over 150k GitHub stars, and v0.12.4 shipped on October 25 (releases). It's one container that talks to any OpenAI-compatible API or to Ollama. That makes it easy to start, and later you have to decide where it lives.

This post compares four realistic options for a person or a small team that wants Open WebUI on the internet, logging in with their own accounts and using an API key from OpenAI, Anthropic, OpenRouter or similar. Running models on your own GPU at home is a different question, and for that a home server usually wins.

What Open WebUI actually needs

Open WebUI is lighter than people expect when you use a remote API, because the model isn't on your box. The container, its SQLite or Postgres database, and uploaded files fit in 1-2 GB of RAM for a handful of users. RAG with local embedding models, local speech-to-text, or bundled Ollama is what pushes it to 4-8 GB or more.

It stores everything under /app/backend/data unless you point DATABASE_URL at Postgres (docs). Whatever host you pick, that directory (or that database) is the thing you have to back up.

One licensing note that matters for agencies: since 2025, Open WebUI's license doesn't let you remove or change its branding unless you have 50 or fewer end users in a rolling 30 days, written permission, or an enterprise license (license). No host can give you a "white-label" Open WebUI past that limit.

Option 1: Railway

Railway bills by usage. The Hobby plan is $5/month and includes $5 of usage. Beyond that, memory is about $10 per GB-month, CPU about $20 per vCPU-month, volumes $0.15 per GB-month, and egress $0.05/GB, all billed per second (pricing, plan docs). The free tier gives $1 of credit a month, caps services at 0.5 GB of RAM, and doesn't allow custom domains, so it's for trying things out only.

Several community templates exist. One example is "OpenWebUI [Updated Oct '26]", which runs ghcr.io/open-webui/open-webui:main (template). There are also variants with Postgres and Redis (template).

Rough cost: if your instance idles around 0.7-1 GB of RAM with little CPU, memory alone is roughly $7-10 a month. With Hobby's $5 included, a light single-user setup lands near $5-10. These are estimates from unit prices. Railway shows actual usage in the dashboard, so watch it for a week.

Where Railway is better: you get a nice deploy experience, GitHub-based deploys, and it's easy to add Postgres or Redis next to the app. If you already run other projects on Railway, putting Open WebUI there is reasonable.

Watch out for:

• Templates are community-maintained, and :main is a moving tag. Updates happen when you redeploy, and nobody checks the release notes for you.
• Backups of the volume are your job. Check what your plan includes.
• Usage billing is great when idle and less predictable when someone uploads a pile of PDFs.

Option 2: Elestio

Elestio deploys open-source apps on a dedicated VM at a cloud provider you choose (Hetzner, DigitalOcean, Vultr, Linode, Scaleway, OVH and others) and manages updates and backups. General managed plans start at $11/month (pricing). Its Open WebUI listing starts at $30/month, because it sits in the AI category and comes set up with Ollama by default (Open WebUI on Elestio).

Support level 1 is included: email support with a 3-day response target and 7 days of backup retention. Faster support costs $50 or $200 a month. There's a 3-day trial (card required), and billing is hourly through credits.

Where Elestio is better:

• Provider and region choice. If you need a specific cloud or region, Elestio can do it.
• A long catalog. If you want Open WebUI plus many unrelated apps under one dashboard, that's convenient.
• Ollama comes with it, if you actually want a CPU Ollama next to the UI.

Watch out for: $30 is a lot if you only need the UI and a remote API key. Bring-your-own-VM is cheaper (from $5/month plus your VM), but then you're partly back to running the server yourself.

Option 3: DIY on a VPS

This is still the cheapest way to run Open WebUI, and the most educational. At Hetzner Cloud, a cost-optimized CX23 (2 vCPU, 4 GB RAM, 40 GB NVMe) lists at €5.99/month before VAT. Availability of that line varies by location, and it showed as unavailable when I checked. The CX33 (4 vCPU, 8 GB) is €8.99 (Hetzner Cloud). Add Docker, Caddy or Traefik for TLS, and the official container, and you're done in an evening.

Something in between: PikaPods runs Open WebUI as a small managed pod "from $6.8/month" (PikaPods). It's a good deal if you don't need to tune much.

Where DIY is better:

• It's cheapest per GB of RAM, and you have full control.
• You can run other things on the same box.
• If you already have a homelab, a reverse proxy and backups set up, Open WebUI is just another container. Paying anyone to host it makes little sense.

What you're signing up for:

• OS patching and Docker updates.
• Reading Open WebUI release notes before you pull. The project moves fast and migrations sometimes need care.
• TLS, a firewall, and making sure open signup is off (in recent versions the first account becomes admin).
• An off-box backup that you've actually tried restoring.

None of that is hard, but it never stops. The usual way DIY fails isn't the setup. It's the box nobody has touched in eight months.

Option 4: Managed Open WebUI (AIHostBox)

This is the option I work on, so read this section with that in mind.

AIHostBox runs Open WebUI on a single-tenant CPU server (not a shared container host). You bring your own API key, and there's no markup on tokens. Plans:

• Starter: 1 vCPU / 2 GB, $5.99/month
• Plus: 2 vCPU / 4 GB, $9.99
• Pro: 3 vCPU / 8 GB, $16.99

It's month to month with no setup fee (Open WebUI on AIHostBox, pricing). It's the official container backed by Postgres, with public signup off by default and new users set to "pending" until you approve them. Backups run nightly to off-box storage. The stated patch targets are 24 hours for critical and 72 hours for high-severity issues (security). OAuth/OIDC and LDAP can be configured. Open WebUI's branding stays as it is (see the license note above).

Where it fits: a small team or a consultant who wants a working, locked-down instance with backups, at roughly what a VPS costs, and doesn't want to own the patching.

Where it doesn't:

• If you want local models, AIHostBox is CPU only. Ollama on CPU works for small models but is slow, and a GPU box at home or a GPU cloud will beat it.
• It's a small company (GGameHost LLC, Wyoming, US). If you need a specific EU region or a big provider's compliance paperwork, Elestio's provider choice or a hyperscaler fits better.
• If you enjoy running servers, Option 3 is cheaper and you'll learn more.

Summary

If you're comfortable with Linux, a €6 VPS is hard to beat. If you'd rather never think about the server, either pay Elestio for flexibility or a smaller managed host for price. Whichever you pick, back up /app/backend/data or your Postgres database, and turn off open signup.

This post is the routine we use. Nothing clever, just the steps that make an upgrade reversible.

Why this week matters: v0.12.4

v0.12.4 came out on 25 October. Its release notes include this line:

This release contains security fixes. We strongly recommend updating all deployments as soon as possible to have the latest security fixes in place. These fixes are not listed in this changelog; we will publish the security advisories for them immediately following CVE assignment.

Holding back details until CVEs are assigned is the responsible way to disclose. The practical side effect is that you can't read the advisory and decide whether you're affected. You just update. So if you're on anything older than 0.12.4, this is the week to have a clean upgrade routine.

Release notes: https://github.com/open-webui/open-webui/releases Advisories (once published): https://github.com/open-webui/open-webui/security

Step 1: stop using :main in production

A lot of compose files still look like this:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main

:main moves whenever the project pushes. Your container upgrades whenever it's recreated, not when you decide. Pin a version instead:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:v0.12.4
    volumes:
      - open-webui:/app/backend/data
    environment:
      - WEBUI_SECRET_KEY=${WEBUI_SECRET_KEY}
    ports:
      - "3000:8080"
    restart: unless-stopped

volumes:
  open-webui:

Two things in there besides the tag:

• The volume. Everything that matters lives in /app/backend/data: the SQLite database (webui.db) if you haven't moved to Postgres, uploaded files, and the default Chroma vector index. Lose that and you've lost users, chats and knowledge bases.
• WEBUI_SECRET_KEY set explicitly. If it isn't fixed, a recreated container can sign sessions with a new key and everyone gets logged out. Not data loss, but it looks like it to your users.

Now an upgrade is a one-line diff in git, and a rollback is the same diff reversed.

Step 2: back up before every upgrade, not "nightly, probably"

For the SQLite setup, stop the container so the database isn't mid-write, then tar the volume:

docker compose stop open-webui

docker run --rm \
  -v open-webui:/data:ro \
  -v "$PWD/backups":/backup \
  alpine tar czf /backup/open-webui-$(date +%F-%H%M).tar.gz -C /data .

docker compose start open-webui

If you've moved users and chats to Postgres (DATABASE_URL), you need two things: a database dump and the volume, because uploads and the vector index still sit in /app/backend/data.

docker compose exec -T postgres pg_dump -U openwebui -Fc openwebui \
  > backups/openwebui-$(date +%F-%H%M).dump

Then tar the volume as above. A database without the files gives you chats with broken attachments. Files without the database give you nothing useful.

Copy both somewhere that isn't the same disk. A backup on the box you're upgrading protects you from a bad migration, not from a dead disk.

Test the restore once. Spin up the old tag against a copy of the volume on another port and log in. Ten minutes, once, and you'll know the backup is real.

Step 3: upgrade and watch the migrations

Open WebUI applies its schema migrations automatically when the new version starts. That's convenient, and it's also the moment to pay attention.

# edit the tag in compose, e.g. v0.12.3 -> v0.12.4
docker compose pull open-webui
docker compose up -d open-webui
docker compose logs -f open-webui

What to look for in the logs:

• Migration lines running and finishing, then the server reporting it's listening on 8080.
• No tracebacks during startup. A migration that fails halfway is the case where your backup matters.
• On a big SQLite database, migrations can take a while. Don't restart the container because the page is slow to come up. Watch the log.

Then do a quick smoke test: log in, open an old chat, send a message to each configured provider, and open one knowledge base.

Step 4: know what a rollback actually is

Migrations go forward. Starting an older image against a database that a newer version already migrated may fail, or worse, half work. So a real rollback is:

1. Stop the container.
2. Restore the volume (and the Postgres dump) from the backup you took in step 2.
3. Put the old tag back in compose.
4. Start it.

This is why the backup has to be taken right before the upgrade. A backup from last night loses today's chats.

Step 5: skip versions carefully

If you're several releases behind, read the release notes for every version in between, not just the latest. Breaking changes and required env var changes are usually called out there. Going straight to the newest tag is generally fine, but you want to know what you're jumping over.

The short version

• Pin v0.12.4, not :main.
• Fix WEBUI_SECRET_KEY.
• Stop, back up the volume (plus pg_dump if on Postgres), copy it off the box.
• Pull, start, read the logs until it's listening.
• Roll back by restoring data, not just by changing the tag.

We do exactly this for the managed Open WebUI instances we run, with the backup going off-box before each pull. But none of it needs us: it's a compose file, a tar command and ten minutes of reading logs.