How-to
Your team's AI chat on your own server, in about three hours
Open WebUI is a self-hosted chat front end that points at local Ollama models or any OpenAI-compatible API, so a per-seat subscription becomes one server plus metered tokens. The install is about three hours: container, provider key, signup closed, proxy, prompts, rule sheet. Skip it if nobody on staff patches servers.
The front end is the part you are paying per seat for, and it is the part you can own. Open WebUI is a self-hosted chat interface that talks to local models through Ollama and to any OpenAI-compatible API, so the subscription becomes a server bill plus metered tokens.
The arithmetic to run first
Do this before you install anything.
- Seats you would buy, times your per-seat monthly price, times twelve months. That is the number to beat.
- Against it: one small server per month, metered token spend for how much your team actually chats, and your own hours for setup and patching.
- Light chat across a dozen or more heads usually favours metered. Four people hammering it all day usually does not. That is my opinion, your invoice decides.
Three hours, step by step
Every time below is my estimate, not a measured run.
Decide where it runs, about 20 minutes
A VPS you already pay for, or a spare machine in the office. Everything Open WebUI keeps lives in one data directory, so your backup is one volume, not a database migration.
Bring the container up, about 15 minutes
The install command in the Open WebUI README maps host port 3000 to the container's 8080 and mounts a named volume at /app/backend/data:
docker run -d -p 3000:8080 \
-v open-webui:/app/backend/data \
--name open-webui --restart always \
ghcr.io/open-webui/open-webui:main
There is a pip path as well, and the README pins Python 3.11 for it. Docker is the quieter option on a shared box.
Point it at a provider, about 25 minutes
Pass OPENAI_API_KEY to the container and the model list fills from your provider. The same field takes any OpenAI-compatible endpoint, which is how you route a cheap model for internal drafting and a stronger one for client-facing work.
Close the door, about 30 minutes
The first account you create is the admin. New sign-ups land in the pending role with zero access until an admin promotes them, and open signup is on by default, so switch it off once your staff are in. For an unattended first boot, set WEBUI_ADMIN_EMAIL with WEBUI_ADMIN_PASSWORD and signup is disabled for you (env reference).
One thing to get right: group permissions are additive. A user in two groups gets the union, and a deny does not exist. Build one group per function and grant upward from a thin default.
Put it behind a proxy, about 45 minutes
nginx or Caddy on a subdomain with a certificate. Do not hang the container port straight on the internet.
Seed prompts and the rule sheet, about 30 minutes
Three or four saved prompts for the jobs your team does daily, one knowledge folder of your real documents, and a one-page sheet: what may be pasted in, what may not, who to ask, where the chats live.
That is about three hours. The ongoing cost is patching, and patching never finishes.
Who should do this, and who should not
| If this is true | Then |
|---|---|
| Someone on staff already patches a server | Self-host, and keep the subscription one more month in parallel |
| The work is mostly drafting and summarising | Self-host, and route the cheap model by default |
| Your text cannot leave the building | Self-host with a local model only, not a hosted API |
| Nobody owns infrastructure | Keep paying per seat and spend the hours elsewhere |
Limitations
- Privacy moves, it does not disappear. Point the API field at a hosted vendor and your text still reaches that vendor. Only a local model keeps it in the building.
- An admin can read user chats unless you set ENABLE_ADMIN_CHAT_ACCESS to false, which is worth deciding before staff start typing.
- Single sign-on is configuration work, not a checkbox. I have not set up an SSO flow here, so treat that as unscoped.
- Upgrades and backups are yours. Container tags move, and the data volume is the thing that must survive.
- The current codebase carries the Open WebUI License with a requirement to preserve the Open WebUI branding, so read it before you put your own logo on top.
My take
If you already pay per seat and your staff mostly want drafting, summarising and a place to ask questions about your own documents, this is a good afternoon of work. If you have nobody who patches servers, the subscription is cheaper than the outage. I have not run this deployment myself, so the timings are a plan, not a benchmark. More build notes are at tarunsai.com/blog.
Questions people ask
Can I keep using a vendor's model through it?
Yes. The README's API field takes any OpenAI-compatible endpoint, so you keep the model and change only who owns the interface and the user accounts. Your text still reaches that vendor, so the privacy gain is partial unless you run a local model.
Will my staff notice the difference?
The chat, the history and file upload are all there. What you give up is the vendor's newest extras in the week they ship. Three or four saved prompts and one knowledge folder of your own documents close most of the gap.
What server do I need?
I have not benchmarked it. If you point at a hosted API, the container is only a front end and a small VPS is usually enough. Running a local model through Ollama is a different machine and a different budget.
Have a process like this leaking time or leads?Thirty minutes, no deck, and you leave with a plan.
Book a call