If you've ever run ollama run llama3.1 in a terminal and thought "this works, but I'd rather not live in a command line," you're the reader this guide is for. Open WebUI wraps your local AI models in a browser interface that looks and feels a lot like ChatGPT, except everything stays on your own hardware.
This tutorial walks through installing Open WebUI in its own LXC container on Proxmox VE, separate from Ollama. That's not an accident. Keeping the two apart means you can restart, back up, or resize one without touching the other, and it mirrors how most homelab setups actually end up looking after the first few months.
What You Will Learn
By the end of this guide you'll have a working Open WebUI instance running in its own unprivileged LXC container, talking to an Ollama instance over your local network. Specifically, you'll learn how to:
- Create a right-sized LXC container for Open WebUI on Proxmox VE
- Install Open WebUI with pip inside a Debian 12 container
- Set it up as a proper systemd service that survives reboots
- Point it at an existing Ollama server running elsewhere on your network
- Fix the handful of errors that trip up almost everyone on their first install
What Is Open WebUI?
Open WebUI is a self-hosted web interface for talking to large language models (LLMs). Think of it as the front end, while something like Ollama is the engine doing the actual work of loading a model and generating text. Open WebUI doesn't run models itself — it connects to a backend (Ollama, or any OpenAI-compatible API) and gives you a browser-based chat window on top of it.
It supports multiple users with logins, keeps chat history, lets you switch between models mid-conversation, and can do retrieval-augmented generation (RAG) — a fancy way of saying it can read your own documents and answer questions using them, instead of relying only on what the model already knows.
None of that requires an internet connection once it's set up. That's the whole appeal for a lot of homelab users: a private, local alternative to ChatGPT that doesn't send your prompts anywhere.
Why Would You Use It?
Ollama on its own is genuinely useful, but the command line gets old fast, especially if anyone else in the house wants to use it. A few reasons people add Open WebUI on top:
- A real chat interface. Conversation history, model switching, and a text box beat retyping
ollama runevery time. - Multi-user access. You can create separate logins so your household or team isn't sharing one shell session.
- It works from any device on your network. Phone, tablet, laptop — anything with a browser, no SSH client required.
- Document chat (RAG). Upload a PDF or a folder of notes and ask questions about the contents.
Running it in its own LXC container instead of bolting it onto the Ollama box keeps the two services independent. If Open WebUI has a bad update, you roll back one container. Your model server keeps running the whole time.
Prerequisites
Before you start, make sure you have:
- Proxmox VE 8.x or later, with a Debian 12 (bookworm) container template downloaded (Datacenter → Storage → local → CT Templates)
- An Ollama server already running and reachable, whether that's in a separate LXC container, a VM, or another machine on your network — if you haven't set this up yet, install Ollama first
- At least 2 vCPU cores and 2 GB of RAM free for the new container (4 GB is more comfortable if you'll add document uploads)
- 8 GB of free disk space on whatever storage pool you're using for container disks
- Root or sudo access to the Proxmox host shell
You don't need a GPU for this container. Open WebUI itself is just a Python web app — the GPU-hungry work happens on the Ollama side.
Step-by-Step Tutorial
Step 1: Create the LXC container
From the Proxmox web interface, click Create CT in the top-right corner. Work through the wizard with these settings:
- CT ID: pick anything unused — this guide uses 216
- Hostname: something like
open-webui - Template: debian-12-standard
- Disk: 8 GB is enough to start; you can grow it later with
pct resize - CPU: 2 cores
- Memory: 2048 MB, with swap left at the default
- Network: bridge to
vmbr0, DHCP is fine for a homelab, or set a static IP if you'd rather it not move around
Leave the container unprivileged unless you have a specific reason not to. There's no hardware passthrough involved here, so there's nothing an unprivileged container can't do for this job.
Start the container once it's created — select it in the left-hand tree, then click Start.
Step 2: Get a shell and update the system
Click the container, then Console, and log in as root. Or SSH in if you already set that up. Either way, start with:
apt update && apt upgrade -yThis pulls the current package lists and applies any pending updates. On a fresh template it usually takes a minute or two.
Step 3: Install Python and the build tools Open WebUI needs
Debian 12 ships with Python 3.11 by default, which happens to be exactly what Open WebUI's documentation recommends. You still need pip and a couple of supporting packages:
apt install -y python3-pip python3-venv build-essential curlpython3-venv lets you create an isolated Python environment so Open WebUI's dependencies don't get tangled up with anything else on the system. build-essential covers the C compiler some Python packages need when they install.
Step 4: Create a virtual environment and install Open WebUI
Set up a dedicated folder and virtual environment:
mkdir -p /opt/open-webui
python3 -m venv /opt/open-webui/venv
source /opt/open-webui/venv/bin/activateNow install the package itself:
pip install --upgrade pip
pip install open-webuiThis step is the one that takes the longest — five to ten minutes on a typical homelab CPU, since pip has to pull down a fair number of Python packages. Don't panic if the terminal sits quietly for a while during this part; it's normal.
Step 5: Do a first test run
Before wiring up a systemd service, confirm it actually starts:
export OLLAMA_BASE_URL=http://192.168.1.50:11434
open-webui serve --host 0.0.0.0 --port 8080Replace 192.168.1.50 with the actual IP address of your Ollama container. Once you see a line mentioning Uvicorn running on port 8080, open a browser and go to http://<container-ip>:8080. You should get a setup screen asking you to create the first admin account — that account becomes the site owner, so use a real email and a password you'll remember.
Press Ctrl+C to stop it once you've confirmed the page loads. The next step makes it start automatically instead.
Step 6: Set up a systemd service
Running Open WebUI in a foreground terminal is fine for testing, but it won't survive a reboot or a closed SSH session. Create a service file:
nano /etc/systemd/system/open-webui.servicePaste in the following, adjusting the Ollama IP address to match your setup:
[Unit]
Description=Open WebUI
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
Environment=OLLAMA_BASE_URL=http://192.168.1.50:11434
Environment=DATA_DIR=/opt/open-webui/data
ExecStart=/opt/open-webui/venv/bin/open-webui serve --host 0.0.0.0 --port 8080
Restart=on-failure
RestartSec=5
WorkingDirectory=/opt/open-webui
[Install]
WantedBy=multi-user.targetSave and exit (in nano, that's Ctrl+O, Enter, then Ctrl+X). Now enable and start it:
systemctl daemon-reload
systemctl enable --now open-webuiCheck that it actually came up cleanly:
systemctl status open-webuiYou're looking for active (running) in green. If it says failed instead, jump down to the Troubleshooting section before doing anything else.
Step 7: Log in and connect a model
Go back to http://<container-ip>:8080 in a browser. Log in with the admin account you created earlier. Click the model selector at the top of the chat window — if Ollama is reachable, any models you've already pulled (like llama3.1 or mistral) should show up automatically. If the list is empty, double-check the OLLAMA_BASE_URL value in the service file and that the Ollama container's firewall isn't blocking port 11434.
Commands Explained
| Command | What it does |
|---|---|
python3 -m venv /opt/open-webui/venv | Creates an isolated Python environment so Open WebUI's dependencies stay separate from system packages |
pip install open-webui | Downloads and installs the Open WebUI package and everything it depends on |
open-webui serve --host 0.0.0.0 --port 8080 | Starts the web server, listening on all network interfaces so it's reachable from other devices |
systemctl enable --now open-webui | Turns the service on immediately and sets it to start automatically on every future boot |
systemctl status open-webui | Shows whether the service is currently running, and prints the last few log lines if it isn't |
journalctl -u open-webui -f | Streams live logs from the service, useful for watching what happens during a login or a failed connection |
Common Errors
"Address already in use" on port 8080. Something else in the container is already bound to that port, or you have a leftover test session still running from Step 5. Run ss -tlnp | grep 8080 to see what's holding it, or just pick a different port in both the service file and your browser URL.
The model list is empty even though Ollama is running. This is almost always the OLLAMA_BASE_URL value. It needs to be the container's IP address, not localhost — Open WebUI and Ollama are in separate containers, so localhost only points back at itself. Also confirm you can reach it directly with curl http://192.168.1.50:11434 from inside the Open WebUI container.
ModuleNotFoundError when starting manually. You forgot to activate the virtual environment first, or the systemd service is pointing at the system Python instead of /opt/open-webui/venv/bin/open-webui. Check the ExecStart line in the service file.
pip install hangs or fails on a slow connection. Some of Open WebUI's dependencies are large. If it times out, rerun the same pip install open-webui command — pip resumes from what it already downloaded rather than starting over.
Troubleshooting
If systemctl status open-webui shows failed, don't guess — read the actual error:
journalctl -u open-webui -n 50 --no-pagerMost first-run failures fall into one of three buckets. A typo in the ExecStart path is the most common — copy-paste the service file rather than retyping it. A permissions issue on /opt/open-webui/data is the second, usually because the directory got created by a different user during testing; running chown -R root:root /opt/open-webui fixes that in most single-user setups. And a network problem reaching Ollama is the third, which shows up as timeouts rather than a crash — check that both containers are on the same bridge and that nothing in the Proxmox firewall is blocking port 11434 between them.
If the page loads but chat requests just spin forever, it's almost always Ollama-side: either the model hasn't finished loading into memory yet, or the Ollama container doesn't have enough RAM for the model you picked. Try a smaller model first to confirm the plumbing works, then scale up.
Best Practices
Keep Open WebUI and your model runner in separate containers, even though it's tempting to combine them into one. Updates land on different schedules, and you don't want a broken pip upgrade taking down your only access to the models.
Back up the /opt/open-webui/data directory before major updates. It holds your chat history, uploaded documents, and user accounts — losing it means starting over from a blank slate.
Don't expose port 8080 directly to the internet. If you want remote access, put it behind a reverse proxy with its own authentication layer, or use something like Tailscale or WireGuard to reach your homelab without opening ports at all.
Set a real password on the first admin account you create. It's easy to skip this during testing and forget to change it later, and that account has full control over user management once other people start logging in.
Frequently Asked Questions
Do I need a GPU for this container?
No. Open WebUI is just the web interface. Only the container or machine actually running the model needs GPU acceleration.
Can Open WebUI run without Ollama?
Yes, it can connect to any OpenAI-compatible API, including cloud services, by adding a connection under Admin Settings → Connections. This guide focuses on Ollama since that's the most common local setup.
How much RAM does Open WebUI itself need?
Under load it typically sits around 300 to 500 MB. The 2 GB allocated in this guide leaves comfortable headroom, especially if you enable document uploads later.
Should I run this in a VM instead of an LXC container?
LXC is the better fit here. It starts faster, uses less overhead, and Open WebUI has no hardware access requirements that would need a full VM.
Can multiple people use the same Open WebUI instance?
Yes. Each person can have their own login with separate chat history, and you can set role-based permissions from the admin panel.
Conclusion
You now have a private, browser-based chat interface running on your own network, backed by whatever models you're already running in Ollama. It's a small container with a modest footprint, but it changes how usable your local AI setup actually feels day to day — no more remembering CLI flags just to ask a question.
From here, worth exploring next: connecting a second Ollama instance for redundancy, enabling document uploads for RAG, or setting up a reverse proxy so you can reach it cleanly from outside your home network.