Open WebUI: A Self-Hosted, ChatGPT-Style Interface for Your Local AI!

In one of our last posts, you got a local model up and running with Ollama in a terminal.

That is great for us. It proves the machine works. It proves the model runs. It gives you that little home lab dopamine hit when the prompt comes back and you realize, "Wait, this is running on my own box."

Nice.

But nobody else in your house is going to open a terminal and type this:

ollama run qwen2.5:7b

They are not going to remember model names. They are not going to ask whether the Ollama service is listening on port 11434 or 11435 and they are definitely not going to SSH into your server because they want help writing an email.

For local AI to replace a ChatGPT subscription, it has to feel like ChatGPT.

That means:

• A clean web app
• Chat history
• User accounts
• Model switching
• Document uploads
• A login page people understand
• A normal URL like https://ai.yourdomain.com

That is where Open WebUI comes in.

Open WebUI is the standard front end for local AI. It runs in Docker, connects to the Ollama server you already set up, and turns your terminal experiment into a private AI service your household might actually use.

That last part matters. A tool nobody uses is not infrastructure. It’s a paperweight with a cooling fan.

What Open WebUI actually is

Open WebUI is a browser-based chat interface for local and remote AI models. Think of it as the missing web app for Ollama, which handles the models. It downloads them, stores them, runs them, and exposes an API. Open WebUI gives people a nice place to use those models.

The basic layout looks familiar if you have used ChatGPT, Claude, Perplexity, or any other chat tool:

• Sidebar with conversations
• Main chat window
• Prompt box at the bottom
• Model selector
• User account menu
• Admin settings
• File upload tools
• Search and folders

Under the hood, Open WebUI talks to Ollama over the network. Your browser talks to Open WebUI. Open WebUI talks to Ollama. Ollama runs the model.

Simple enough.

The path looks like this:

Your browser → Open WebUI → Ollama → local model

If you put it behind a reverse proxy, the outside shape becomes cleaner:

https://ai.yourdomain.com → Open WebUI → Ollama → local model

That is the point where local AI stops feeling like a science project and starts feeling like a service.

Why this matters

Running a model in a terminal is great for testing, but terrible for daily life. A proper front-end changes everything.

Instead of telling your family, "SSH into the server, run this command, and paste your prompt after the model loads," you just say, "Go to ai.yourdomain.com."

That shift is massive. It transforms a niche hobbyist project into a shared household utility. Suddenly, one person is using it for recipe ideas. Another is using it for homework help. And you’re still using it for writing, coding, summarizing PDFs, or asking why Docker woke up and chose violence today.

Same hardware. Better interface. Exponentially more use.

What you get with Open WebUI

Open WebUI has a lot packed into one container. Some of it you will use right away. Some of it you will ignore until later. That is fine. The important features are below.

A polished chat interface

This is the big one. Open WebUI gives you a proper chat app with;

• Conversation history
• Search
• Folders
• Streaming responses
• Markdown rendering
• Code blocks
• Model selection
• Prompt editing
• Regeneration
• File uploads

It feels close enough to paid AI tools that everyday users understand it immediately. That is the win. The model might be local, but the experience doesn't have to feel like typing a Wi-Fi password with a TV remote.

Multi-user accounts

Open WebUI is built for multiple users. The first account created automatically becomes the admin. From there, you can open up sign-ups, approve accounts, assign roles, and ensure everyone's chats remain entirely separate.

This is a game-changer for a household. Your prompts stay private. Someone else’s homework questions stay theirs. Your late-night server planning sessions stay separate from someone else's recipe ideas.

It keeps administration clean and secure, giving you total control over who gets access and what they can use.

Model switching

Open WebUI automatically pulls any models you have installed in Ollama into a clean dropdown menu. Instead of memorizing terminal commands for qwen2.5, llama3.1, or deepseek-r1, users just pick from a list.

This is incredibly useful for testing. You can feed the exact same prompt to different models and compare the results. Sometimes the smaller model is perfectly fine. Sometimes the bigger model is worth the extra processing time. And occasionally, both of them confidently hallucinate the wrong answer, reminding you that local AI is still just a tool, not a crystal ball.

Side-by-side comparisons

Open WebUI allows you to run the same prompt across multiple models simultaneously. This is more useful than it sounds. If you are debating whether a larger model is worth the extra RAM, run them side-by-side and compare:

• Output quality and reasoning
• Response speed
• Formatting and hallucinations
• Practical utility for your specific tasks

Benchmarks are fine, but your use case is the only metric that matters. If a 7B model handles your household questions just as well as a 32B model, you don't need to chase a massive GPU upgrade. That realization alone just saved you $800. Probably not you specifically, but definitely someone.

Document chat

Document chat is the feature that finally gets non-technical people interested in local AI. You can upload a PDF, a text file, or a massive manual and just start asking questions about it.

• What does this insurance policy say about sewer backup?
• Summarize this appliance manual in plain English.
• Where does this document mention warranty coverage?
• What maintenance does this furnace manual recommend?

This is where a home lab goes from a hobby to a practical household tool. Your family probably doesn't care that you're running a quantized model through Ollama. They will care that they can upload a PDF of the dishwasher manual and instantly ask why an angry little red light is blinking.

Open WebUI handles these requests through a built-in feature called RAG (Retrieval-Augmented Generation). In plain English: the app searches your document, grabs the relevant paragraphs, and feeds them to the AI so it can give you an accurate, contextual answer.

It isn't magic. Bad scans, weird formatting, or complex tables can still trip it up. But for household policies, appliance manuals, and long reference documents, it is more than useful enough to earn its keep.

Knowledge collections

Open WebUI can also organize your files into specific knowledge collections, which is where a household AI gets really interesting.

You could create a collection called "House Documents" and fill it with the following:

• Appliance, furnace, and water softener manuals
• Home insurance policies and warranty PDFs
• Vehicle maintenance and home network notes
• Emergency shutoff locations and garbage schedules

Next, you create a custom model preset called House Helper and attach that collection to it. Now, your local AI can answer highly specific household questions:

• Where is the main water shutoff?
• What filter size does the furnace use?
• What does our insurance policy say about hail damage?

This is the exact use case that makes the rest of the house understand why you built this setup. You didn't build it just because it’s cool. You built it because it’s genuinely useful.

Custom model presets

Open WebUI lets you create custom model presets. A preset usually combines a base model, a system prompt, optional knowledge sources, and specific behaviour settings. Think of it as one model wearing different work boots for different jobs.

You might create:

• House Helper: A practical assistant loaded with your household documents to answer everyday questions.
• Homework Coach: A tutor programmed to explain the steps rather than just giving away the answers.
• Recipe Helper: A kitchen assistant that asks what ingredients you actually have before suggesting a meal.
• Blog Drafter: A writing assistant tuned to match your preferred voice, structure, and formatting.
• Tech Support Goblin: A troubleshooting assistant strictly instructed to ask for error logs before inventing nonsense. (This one should be mandatory.)

The best part is that these presets don't require separate downloads. One base model can power all of these different personalities, saving disk space, RAM, and your patience.

Web search integration

Depending on your configuration, Open WebUI can connect to web search tools. This is incredibly useful because it allows the model to look up current information instead of relying strictly on its training data.

But you have to be careful. Local AI is only private as long as it stays local. The moment you start connecting web searches, external APIs, or remote model providers, some of your data is going to leave the box.

That doesn't mean you should avoid the feature; it just means you need to understand what you're plugging into. For a shared family AI, I highly recommend starting without a web search. Get the core, local experience running smoothly first, and only introduce search when you actually need it.

Boring setup first. Fancy knives later. cough cough (Firecrawl) ← Free tier available.

Voice input and read-aloud

Open WebUI can also support voice input and text-to-speech features, depending on your browser and configuration. There are two things to keep in mind here:

First, browsers are incredibly picky about microphone access. Most modern browsers require an HTTPS connection for voice input to work at all. That means hitting the microphone button likely won't work on your local IP address: http://your-server:3000

But it will behave perfectly once it is running safely behind your reverse proxy: [https://ai.yourdomain.com](https://ai.yourdomain.com)

Second, voice features are exactly what make an application feel less like a server project and more like a household tool. If a family member can open the page on their phone, tap the microphone, and just speak a question, adoption goes way up.

People like useful things. They tolerate your infrastructure only when it stops looking like infrastructure.

OpenAI-compatible API

Open WebUI can also expose an API that behaves exactly like the OpenAI API. That means external tools or apps expecting a standard OpenAI endpoint can simply be pointed at your local setup instead.

This isn't the feature you show the family. But for you, it is where things get incredibly exciting. It means your local AI can suddenly become the backend engine for your automations, custom scripts, and internal home lab tools.

The progression always starts simply: basic browser chat. Then it grows into something bigger: a fully private AI API for your home network.

That is where things get fun. Careful fun, but fun.

The basic setup

The basic setup process assumes you already have Ollama up and running from our previous post. To connect the two, your Ollama service needs to be reachable from Docker at an address like: http://ollama:11434 or http://<ip-address>:11434

If you are running Open WebUI and Ollama in the same Docker Compose file, you can just use the service name ollama as the hostname. That is simply Docker's internal DNS quietly doing its job.

One Docker Compose block

Add Open WebUI right beside your Ollama service in your Compose file:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - ./open-webui:/app/backend/data

Then start it up: docker compose up -d

And open it in your browser: http://your-server:3000

Crucial note: The very first account created automatically becomes the admin account. Do that before you share the link with anyone else. This is not the place to discover that your teenager is now the system administrator of the family AI just because they clicked faster than you.

A fuller Compose example with Ollama

If you want Open WebUI and Ollama in the same Compose file, it might look like this:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    volumes:
      - ./ollama:/root/.ollama
    ports:
      - "11434:11434"
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    depends_on:
      - ollama
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - ./open-webui:/app/backend/data

That is the simple, complete version. A few quick notes on how this works:

• ./ollama: This is where Ollama stores your downloaded models so you don't lose them when the container restarts.
• ./open-webui: This stores all your users, chat histories, and application settings.
• OLLAMA_BASE_URL=http://ollama:11434: This tells Open WebUI exactly where to find the Ollama service on Docker's internal network.
• 3000:8080: This means you visit Open WebUI on port 3000, while the container listens internally on port 8080.

If you plan to use a reverse proxy later, you can remove the published 3000 port and expose Open WebUI exclusively through your proxy network. But for your first setup, publishing port 3000 is perfectly fine.

First login

After the container starts, open your browser to: http://your-server:3000

Create your account. Just a reminder: the first account you create will automatically become the admin. Use a real password—not password, not admin123, and definitely not the Wi-Fi password written on the fridge.

Once you are logged in, verify the interface to ensure Open WebUI sees your Ollama models. If the list is empty because you haven't downloaded a model yet, jump into your terminal and pull one:

ollama pull qwen2.5:7b Or: ollama pull llama3.1:8b

Finally, refresh Open WebUI and verify the model dropdown. Your new model should be waiting for you.

Three first-evening settings to touch

Once it is running, do not spend the entire night spelunking through every setting.

Touch these three first.

1. Signups

Decide how user registration should work. For a household setup, requiring admin approval is usually the best route. Family members can create accounts, but you have to approve them before they get access. Open signups might be fine on a private LAN, but approval keeps things clean—especially if guests, kids, or random devices find the page. The question is simple: do you want anyone on the network to create an account, or do you want control? Choose control.

2. Default model

Pick a default model that is good enough for general use. For most home labs, the 7B to 8B range is the sweet spot (qwen2.5:7b, llama3.1:8b, or mistral:7b). Your hardware dictates the best choice. A tiny model is fast but might lack depth, while a massive model is brilliant but so slow that people will abandon it. For a family AI, responsiveness is everything. Nobody wants to wait 90 seconds for a recipe suggestion unless the recipe includes winning lottery numbers. Start with a snappy, mid-sized model and scale up later if your hardware allows.

3. Name and logo

This feature sounds purely cosmetic, but it isn't. If the interface says "Open WebUI," your family just sees another one of your server projects. If it says "Home AI," "Smith AI," or "BinaryTech AI"—complete with a clean, minimalist logo—it starts feeling like a legitimate household tool. Branding isn't just vanity; it tells non-technical users what the thing is actually for. Give it a name that makes sense for your house.

Put it behind a reverse proxy

Open WebUI is infinitely better behind a proper hostname. Instead of handing out [http://192.168.1.50:3000], give them [https://ai.yourdomain.com].

This simple change accomplishes four things:

• It gives people a URL they can actually remember.
• It eliminates ugly browser security warnings.
• It unlocks browser features that strictly require HTTPS, like voice input.
• It matches the clean, professional architecture of the rest of your home lab.

If you followed the previous post on setting up a reverse proxy, the result is exactly where that effort pays off.

For Caddy, the route might be as simple as:

Plaintext

ai.example.com {
    reverse_proxy open-webui:8080
}

For Nginx Proxy Manager, configure it like this:

• Domain: ai.example.com
• Forward hostname/IP: open-webui
• Forward port: 8080
• SSL: Enabled
• Force SSL: Enabled

For Traefik, just add these labels to your Open WebUI service:

YAML

labels:
  - traefik.enable=true
  - traefik.http.routers.open-webui.rule=Host(`ai.example.com`)
  - traefik.http.routers.open-webui.entrypoints=websecure
  - traefik.http.routers.open-webui.tls.certresolver=cloudflare
  - traefik.http.services.open-webui.loadbalancer.server.port=8080

Use whatever proxy you prefer. The goal is the same: a clean hostname, secure HTTPS, and no weird ports for normal users.

A better Docker network layout

If you are using a reverse proxy, you should put Open WebUI on your proxy network and isolate Ollama.

Here is an example YAML:

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - ./open-webui:/app/backend/data
    networks:
      - ai
      - proxy
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    volumes:
      - ./ollama:/root/.ollama
    networks:
      - ai
networks:
  ai:
  proxy:
    external: true

In this setup:

• Open WebUI can talk to Ollama over the private ai network.
• The reverse proxy can talk to Open WebUI over the external proxy network.
• Ollama itself is completely isolated from the proxy and your LAN.

This is a much cleaner architecture. Open WebUI is the application people actually interact with. Ollama is just the engine behind it—and engines don't need to sit in the living room.

What to test after setup

Before you announce to the house that "the AI is live," run through a quick set of tests.

• Check the containers: Run docker ps to ensure both open-webui and ollama are actually running.
• Check the logs: Run docker logs open-webui --tail=100 and look for any obvious connection errors.
• Verify the connection: If your model list in Open WebUI is empty, it probably isn't reaching Ollama. The most common culprit? Using localhost when you meant the Docker service name. Inside a container, localhost means the container itself, not your host machine. Use http://ollama:11434, not http://localhost:11434. Docker networking is perfectly logical once it clicks, but until then, it is a small haunted forest.
• Send a test prompt: Ask it to write a three-line summary of what Open WebUI does and confirm you get a streamed answer.
• Test document chat: Upload a short PDF or text file and ask what it is about. Do not start with a 500-page scanned manual from 1997. That is not a test. That is a trap.
• Test from a phone: Open the site from a mobile device on your Wi-Fi. This instantly flags practical problems like broken DNS, reverse proxy issues, or a UI that is too slow.

If it works smoothly on a phone, you are much closer to something the household will actually use.

Good first model choices

Model choice depends entirely on your hardware—specifically your RAM and GPU. For a general household assistant, prioritize models that are fast enough to feel conversational.

Here are some reliable starting points:

• qwen2.5:7b
• llama3.1:8b
• mistral:7b
• phi3:mini

If your machine is modest, start with the smaller models. If you have a decent GPU or plenty of RAM, aim for the 7B or 8B range.

Remember the goal: your model doesn't need to be smart enough to win internet arguments. It just needs to answer household questions, summarize documents, and draft messages without taking a coffee break between tokens. Speed matters. The best model is simply the one that people actually keep using.

Setting expectations for the family

Setting expectations for the family is important: a slick web interface does not make a weak model smart. Open WebUI makes local AI pleasant to use, but it cannot make a tiny model magically understand everything. If you run a 3B model, expect 3B behaviour. It will be quick, but it might also confidently tell you that your dishwasher is powered by a small internal weather system.

Set expectations with your household early on about what the AI can and cannot do:

• It can draft text and summarize documents.
• It can explain concepts and help you brainstorm.
• It can be completely wrong.
• It should never be trusted blindly for medical, legal, financial, or safety-critical advice.

For kids, establish a clear ground rule: use it to learn, not to skip thinking. This is where a homework coaching tool excels—it should explain steps and ask guiding questions rather than just handing over the final answers. That makes it a better household tool and a much better parenting move.

Privacy: what stays local and what does not

The biggest reason to run local AI is privacy. If you stick strictly to Open WebUI and Ollama, your prompts and documents never leave your machine. That is the entire appeal.

But privacy is fragile—it depends entirely on what you connect. If you start adding web search APIs, remote model providers, cloud storage, or external image generation tools, your data is leaving the house. That trade-off may be acceptable for you, but don't pretend the system is still fully local once it is wired to five different cloud services.

For a household setup, I highly recommend starting strict:

• Open WebUI + Ollama only
• Local users
• Local documents
• Zero external tools

Start fully isolated, and add outside integrations deliberately. Don't turn your privacy project into a data sprinkler by accident.

Backups matter

Open WebUI stores all of its critical data inside its assigned volume. This includes your user profiles, application settings, chat histories, uploaded documents, knowledge bases, and custom presets.

If your configuration maps the data like this:

volumes:
  - ./open-webui:/app/backend/data

Then your primary target is that local folder: ./open-webui. If you lose that directory, you lose the entire state of your application.

You can also back up your Ollama model folder (./ollama) if you want to avoid re-downloading large files later. While models can easily be pulled down again from the library, your WebUI data is personal, unique, and deeply annoying to recreate from scratch.

Your minimum disaster-recovery checklist should include:

• docker-compose.yml
• Your .env environment file (with secrets scrubbed)
• The ./open-webui data folder
• A quick note listing the models you use
• Any custom prompts, system presets, or reverse proxy configurations

This task is easily the least glamorous part of running a home server. But it is the exact kind of boring task that completely saves you when a drive inevitably misbehaves.

Updates: do not live on the bleeding edge unless you enjoy bleeding

Open WebUI develops at a breakneck pace. That is fantastic for rapid improvements, but it can be deeply annoying when familiar menus and settings unexpectedly rearrange themselves.

If your configuration uses image: ghcr.io/open-webui/open-webui:main, you are tracking the absolute newest release. That might be fine for a solo home lab experiment, but once your family starts relying on the tool, stability matters. Consider pinning a specific version tag (like image: ghcr.io/open-webui/open-webui:vX.Y.Z) instead of blindly pulling whatever is newest.

My practical advice for keeping the peace:

• Do not update every day.
• Do not ignore updates forever.
• Update monthly-ish.
• Read the release notes if the service matters to you.
• Always back up before pulling a new image.

Honest trade-offs

Open WebUI is excellent, but it is not perfect.

It moves fast

Features shift around constantly. A tutorial written just six months ago might show a setting that has already moved or changed names. This is normal for active open-source projects, but it can be deeply irritating when you are trying to follow along. If you value your sanity, pin a version tag in your Docker file.

The model is still the model

A beautiful interface doesn't magically make a small model smarter. If the answer quality is bad, the fix usually isn't hidden in a settings menu. You likely need a better model, a better prompt, more RAM, GPU acceleration, or simply lower expectations. Sometimes the model is just too small for what you are asking it to do.

Document chat has limits

The built-in document chat is incredibly useful, but it isn't a flawless research assistant. It will struggle with massive PDFs, scanned documents with bad OCR, complex tables, handwritten notes, and mixed layouts. Use it for general understanding and practical household documents. Do not use it as the absolute source of truth for contracts, legal documents, or insurance disputes—anything where one hallucinated sentence could cost you real money.

It becomes important once people use it

The exact moment your household starts relying on Open WebUI, it ceases to be an experiment and becomes a production service. That means you need to back it up, monitor it, keep it updated, and establish a rollback plan. You can no longer randomly break things on a Tuesday night just to see what happens.

This is the ultimate curse of useful infrastructure. Once people actually like it, you are officially tech support.

Common problems and fixes

Open WebUI does not show any models If your dropdown is empty, check these likely causes:

• Ollama isn't running.
• Open WebUI cannot reach Ollama (wrong OLLAMA_BASE_URL or mismatched Docker networks).
• No models have been downloaded yet.

Verify Ollama is active with docker ps | grep ollama. If it's running, pull a model using ollama pull qwen2.5:7b. If it's still blank, dig into the connection errors: docker logs open-webui --tail=100.

The Localhost Trap Inside a container, localhost means that specific container, not your host machine. If you tell Open WebUI to look for Ollama at http://localhost:11434, it is looking inside itself. Unless they are bundled together, use the internal service name: http://ollama:11434.

The app works by IP but not by hostname This points to a DNS or reverse proxy issue. First, verify your domain routes correctly using nslookup ai.example.com or dig ai.example.com.

If DNS is fine, check your proxy target. Open WebUI listens internally on port 8080. Your proxy needs to forward traffic to open-webui:8080, not open-webui:3000. Port 3000 is only the external mapping for your host; inside the Docker network, the container expects 8080. That distinction matters.

Voice does not work Use HTTPS. Most modern browsers strictly block microphone access on plain HTTP pages. This is exactly why you put Open WebUI behind a secure reverse proxy like [https://ai.example.com](https://ai.example.com).

It feels slow If your text generation is crawling, look for these culprits:

• The model is too large for your hardware.
• The system is running on CPU only instead of using your GPU.
• The server is low on RAM or handling too many concurrent users.

Try a smaller model first. You should also check system usage using htop and watch your containers with docker stats. If your RAM is pinned and the machine is heavily swapping to disk, the model isn't thinking—it is drowning.

A practical first-week plan

Do not try to build the perfect AI platform in one night. Do this instead:

• Night 1: Install and Test - Start Open WebUI and immediately create your admin account to lock down the system. Connect it to Ollama, pull a solid mid-sized model, and send a few test prompts. Finally, upload a single, small document to verify retrieval works.
• Night 2: Put it Behind HTTPS - Add your reverse proxy route and assign it a clean, memorable hostname. Test the interface from both a laptop and a mobile phone on your Wi-Fi, and confirm that voice input works now that you have a secure HTTPS layer.
• Night 3: Add Household Accounts - Configure your user registration settings (admin approval is strongly recommended). Pick your snappy default model, swap out the generic branding with a custom name and a clean icon, and show the family where to log in.
• Night 4: Build Your First Preset - Create a simple custom preset called something like House Helper. Give it a straightforward, grounded system prompt:

"You are a practical household assistant. Answer in plain English. If you are unsure, say so. For uploaded documents, quote or reference the relevant section when possible. Do not guess safety-critical information."

Attach a small, useful household document collection to give it immediate utility.

• Night 5: Watch What People Actually Use - Don't guess what your family wants; watch how they actually interact with it. Maybe nobody cares about voice, or maybe document chat becomes the killer feature. The kids might only use it for homework tracking, or everyone might completely ignore it except you. That is still a perfectly valid outcome—just a slightly less glorious one. Build entirely around actual usage.

The bottom line

Ollama makes local AI possible. Open WebUI makes it livable.

Adding this single Docker container turns a terminal-only model into a private, multi-user AI service complete with chat history, model switching, document chat, custom presets, and a familiar web interface. That is the exact boundary between saying "I can run a model locally" and saying "We have a private AI app at home." That second one is what really matters. If your goal is to replace a cloud AI subscription, Open WebUI is the component that makes the switch feel like an upgrade instead of a sacrifice.

To get there, start simple:

• Open WebUI + Ollama
• One solid model
• One clean hostname
• HTTPS through your reverse proxy
• A couple of practical presets

From there, let the household tell you what it is actually good for. And yes—give it a name. The moment your family starts saying "Ask House AI" instead of "What is that weird server thing again?" you have officially won. What did you name your household AI, and did anyone besides you actually use it? That is the real benchmark.