Open WebUI Weekend Project: Self-Host a Unified Interface for Your Local and Remote AI Models

July 20, 2026

6 min read

Django Python Local-Llms Self-Hosting Open-Webui Homelab

There's a certain satisfaction in owning your AI stack. Not in a philosophical sense, necessarily, but in the practical sense of knowing where your prompts go, what they cost, and what you can actually change when something doesn't work. Open WebUI gives you that without requiring you to write a custom front-end from scratch.

If you're already running Ollama locally, or you have a spare VPS collecting dust, this is the weekend project worth your time. Mid-2026 self-hosting roundups have been consistent on this point: Open WebUI is the recommended front-end layer when you want a usable interface on top of self-hosted models. It also fits cleanly into a broader open-source dev stack alongside tools like Langflow for pipeline prototyping, so it's not a dead-end investment.

Why Bother Self-Hosting in 2026

The short answer is that the commercial AI tooling landscape shifted in ways that made a lot of developers uncomfortable. OpenCode emerged as a terminal-based open-source alternative and picked up roughly 160,000 GitHub stars and 7.5 million monthly active users in short order. That's not a coincidence. Developers are actively looking for infrastructure they control.

A useful framing from mid-2026 self-hosting commentary: keep friction-heavy services like email in the cloud, and self-host the privacy-critical workloads, photos, local AI, things where data residency actually matters. Open WebUI targets that second category precisely. Your conversation history stays on your machine. Your API keys don't pass through a third party. If you're using it to explore Django project architecture with an LLM, nobody else sees your codebase.

What You'll Need

The setup assumes a Linux box, either a VPS (a $6-12/month instance is plenty for the UI layer) or a homelab machine. If you're running models locally via Ollama, that machine does the heavy lifting. Open WebUI just needs to reach it over the network.

Required:
- Docker and Docker Compose
- A domain name (optional but recommended if you want HTTPS)
- Ollama running on your local network or the same host, OR an OpenAI-compatible API key

Optional but useful: a Caddy or Nginx reverse proxy for TLS termination.

Containerized Deployment

The fastest path is Docker Compose. Create a working directory and drop in a compose.yml:

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

volumes:
  open-webui:

If Ollama is running on the same host, host.docker.internal routes correctly on Linux with the extra_hosts entry. If Ollama is on a separate machine on your LAN, replace that value with the actual IP.

Bring it up:

docker compose up -d

Navigate to http://your-server-ip:3000 and create your admin account. The first user gets admin access, so don't delay that step if this box is internet-facing.

Wiring Up Models

Open WebUI treats Ollama and OpenAI-compatible APIs as separate connection types, both configurable from the admin panel under Settings > Connections.

For Ollama, it picks up whatever models you've already pulled. If you haven't pulled anything yet:

ollama pull llama3.2
ollama pull codestral

For remote APIs (OpenAI, Groq, Anthropic via a compatible wrapper), add the base URL and API key in the OpenAI-compatible connections section. This is how you get a single interface that can query a local Llama model and a remote Claude endpoint depending on what the task demands, without switching between five different browser tabs.

Model selection in the chat UI is a dropdown. The experience is close enough to ChatGPT that anyone on your team can use it without a tutorial.

Basic Security Before You Expose It

If this is sitting on a public VPS, a few things before you call it done.

First, put it behind a reverse proxy with TLS. With Caddy, this is genuinely simple:

ai.yourdomain.com {
    reverse_proxy localhost:3000
}

Caddy handles cert provisioning automatically via Let's Encrypt. Swap in your domain, point DNS, restart Caddy.

Second, disable open registration. In the admin panel under Settings > General, set signup to admin-invite-only. Otherwise anyone who finds the URL can create an account.

Third, set WEBUI_SECRET_KEY as an environment variable in your Compose file. This controls session signing and you don't want the default.

environment:
  - WEBUI_SECRET_KEY=some-long-random-string-here
  - OLLAMA_BASE_URL=http://host.docker.internal:11434

That's the baseline. You're not building a bank, but these three steps move you from "definitely going to get scraped" to "reasonable for personal or small team use."

Integrating Open WebUI into a Python and Django Workflow

Once it's running, the obvious use is chatting with models. But Open WebUI exposes an OpenAI-compatible REST API at /api, which means your existing Python code can talk to it directly.

For a Django project, you might want a dev-time helper that queries your self-hosted instance instead of OpenAI's servers. Here's a minimal example using httpx:

import httpx

OPEN_WEBUI_URL = "http://localhost:3000/api"
OPEN_WEBUI_KEY = "your-open-webui-api-key"  # generated in the admin panel

def ask_local_model(prompt: str, model: str = "llama3.2") -> str:
    response = httpx.post(
        f"{OPEN_WEBUI_URL}/chat/completions",
        headers={"Authorization": f"Bearer {OPEN_WEBUI_KEY}"},
        json={
            "model": model,
            "messages": [{"role": "user", "content": prompt}],
        },
        timeout=60.0,
    )
    response.raise_for_status()
    return response.json()["choices"][0]["message"]["content"]

This is the same shape as the OpenAI Python client calls you might already have in your project. Swap the base URL and key, and you're talking to a local model. Useful for testing prompts against cheaper or faster models before committing to a more expensive API call in production.

A few patterns that have worked well in practice:

Use the web UI for exploration and prompt drafting. Once a prompt is stable, move it into code with the API.
Point a Langflow instance at the same Open WebUI API endpoint to prototype multi-step chains without rewriting Python each time.
For Django management commands that do content generation or data enrichment, inject the local model endpoint via an environment variable so you can toggle between local and remote without code changes.

What It Can't Do

Open WebUI is a front-end and API gateway. It doesn't train models, it doesn't fine-tune them, and it doesn't orchestrate complex multi-agent workflows natively. For that last part, you'd pair it with something like Langflow. The tool is also not designed to serve high-concurrency production traffic. For a team of two to five developers using it as a shared dev tool, you'll be fine. For anything customer-facing, look elsewhere.

Also: the main Docker tag tracks the latest release, which moves fast. Pin to a specific version tag in production-adjacent setups so you're not surprised by a UI change mid-sprint.

Wrapping Up

Start to finish, including reverse proxy setup and pulling a couple of models, this is a Saturday morning project. The payoff is a persistent, self-hosted AI workstation that works with whatever models you have available, keeps your data local, and exposes an API your existing Python code can already speak. Given where the AI tooling ecosystem is right now, that kind of infrastructure independence is worth more than it was a year ago.

Sources consulted: State of Self Hosting Mid-2026, Trending AI Tools 2026 for Open-Source Dev Stack, OpenCode Hits 160K GitHub Stars, Tops Coding Tools, DevTools Digest 2026-07-15