You got Ollama running on your home machine. It works perfectly — for you. Then your partner tries it, your teenager wants in, and suddenly everyone’s sharing the admin account, chat histories are a mess, and you have no way to stop anyone from pulling a 70B model that takes the server down for everyone else.

The fix is Open WebUI’s built-in authentication and role-based access control. It takes about 30 minutes to configure properly. After that, every family member has their own account, their own chat history, and only the models you’ve decided they should see.

30 minutes of configuration: Docker Compose install, first-run admin creation, adding users through the pending-approval flow, locking model access down by group, and optionally wiring Tailscale so everyone reaches it from their phone.

What you need before starting

• A machine running Linux, macOS, or Windows with Docker (or Docker Desktop) installed
• At least 16 GB system RAM — 32 GB if you want to run 13B+ models while multiple people are active
• Basic terminal comfort
• 20–30 minutes

If you haven’t checked whether your hardware can handle the models your family wants to run, read how much VRAM you actually need for different Llama model sizes before continuing.

How the stack fits together

There are three layers:

Layer	What it does	Software
Inference engine	Loads models, handles generation, queues concurrent requests	Ollama
Web interface	User accounts, chat UI, model picker, admin panel	Open WebUI
Remote access (optional)	Encrypted tunnel so phones and laptops outside the home can connect	Tailscale

Ollama handles the actual GPU work. When two family members send prompts at the same time, Ollama queues requests and processes them sequentially — so neither request fails, the second one just waits a few seconds. Open WebUI sits in front of that, giving each user their own login and conversation history.

These two services run in Docker containers and talk to each other over a local network bridge. You do not need to expose any ports to the internet for the local-only setup.

Step 1: Install Open WebUI and Ollama with Docker Compose

Create a directory for the project and save this as docker-compose.yaml:

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    volumes:
      - ollama_data:/root/.ollama
    ports:
      - "11434:11434"
    restart: unless-stopped
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

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

volumes:
  ollama_data:
  open-webui_data:

Two environment variables matter for a shared setup:

• ENABLE_SIGNUP=true — allows new user registrations. You’ll flip this off after everyone has an account.
• DEFAULT_USER_ROLE=pending — every new registration goes into a holding state where the admin must manually approve them before they can do anything. This is the key setting for controlled access.

If you’re on a machine without an NVIDIA GPU, remove the deploy.resources.reservations block entirely. Ollama will run on CPU. Performance will be slow — more on alternatives at the end of this guide.

Start the stack:

docker compose up -d

Open http://localhost:3000 in your browser. You should see the Open WebUI welcome screen.

Step 2: Create the admin account

The first account created on a fresh Open WebUI instance automatically becomes the admin. Open the UI and register normally — use an email address and a real password you won’t forget.

After you complete registration, Open WebUI automatically disables new sign-ups. The signup page disappears for anyone who visits the URL. This is intentional behavior: the moment an admin exists, the system assumes you want to control who gets in.

You are now logged in as the only user, with full admin access. You can see this by clicking your avatar in the bottom left, then navigating to Admin Panel.

Step 3: Add family members

You have two options for getting additional users into the system.

Option A: Re-enable signup, have them register, then disable it again

In Admin Panel → Settings → General, toggle “Enable New Sign Ups” on. Share the URL with whoever needs an account. After they register, their account sits in Pending status — they’ll see a message that their account is awaiting approval, but nothing else.

Back in Admin Panel → Users, you’ll see each pending account. Click the role indicator next to their name and cycle it from Pending → User. They can now log in.

Once everyone has registered, go back to Admin Panel → Settings → General and toggle signup off again.

Option B: Let them register directly from the URL when signup is open

This is the same flow but you time it: tell family members to go register at a specific time, then you lock it after.

Either way, the pending-approval step is what protects you. If someone stumbles onto your home server’s URL and creates an account while signup is briefly open, they’re stuck at Pending until you approve them.

Useful admin shortcuts:

• Admin Panel → Users shows all accounts, their roles, and last activity
• Click a user row to see their details and force-logout if needed
• You can delete accounts or reset passwords from this panel

Step 4: Set up groups and model access controls

Open WebUI 0.6.x added granular group-based permissions. For a family server, this matters when you want different people to have access to different models — or different features.

A practical example: you want kids’ accounts to have access to smaller, faster models but not your fine-tuned or uncensored models, and no access to image generation.

Create a group:

Admin Panel → Users → Groups → New Group

Name it something like “Family” or “Kids.” In the group settings, you can configure:

• Which features are enabled for group members (image generation, RAG file uploads, tool use, code execution)
• Which models they can see

Restrict model visibility:

Navigate to Workspace → Models. For any model you want to limit, click the settings icon and change its visibility from Public to Private or Restricted, then explicitly add which groups or users can access it.

Important behavior to know: Open WebUI permissions are additive. If a user belongs to two groups, they get the union of both groups’ permissions. If Group A allows image generation and Group B does not, a user in both groups will have image generation. Design groups without overlap if you want strict separation.

Default permissions apply to all users regardless of group membership. Configure these at Admin Panel → Users → Groups → Default Permissions. A safe default for a family server: disable code execution and external tool use, enable chat and basic file uploads.

Step 5: Pull models for your family

With the stack running, open a terminal and pull the models you want available:

docker exec ollama ollama pull llama3.2:3b
docker exec ollama ollama pull llama3.1:8b
docker exec ollama ollama pull qwen2.5:14b

The 3B model is fast and works well for casual questions on almost any hardware. The 8B hits a practical sweet spot for most home lab setups. The 14B is good if you have 16+ GB VRAM or fast enough system RAM.

Once pulled, models appear automatically in Open WebUI’s model picker for users who have access to them. You don’t need to restart anything.

For guidance on which models make sense for your specific hardware tier, see best local AI models by VRAM tier.

Step 6: Remote access with Tailscale (optional but recommended)

The setup above works perfectly inside your home network. Anyone on the same Wi-Fi can reach http://192.168.x.x:3000. But if family members want to use the server from their phones when away from home — or if you want access from a work laptop — you need a way to reach it without opening ports to the internet.

Tailscale is the clean solution. It creates an encrypted WireGuard mesh between all your devices. Your home server gets a stable hostname like my-server.tail1234.ts.net. Devices with Tailscale installed can reach it from anywhere as if they were on your home network.

Server setup:

1. Install Tailscale on your home server: curl -fsSL https://tailscale.com/install.sh | sh
2. Run sudo tailscale up and authenticate via the link it shows
3. Your server gets a 100.x.x.x IP and a .ts.net hostname

Client setup:

Install the Tailscale app on each phone or laptop (free for personal use). Sign in with the same Tailscale account. That device can now reach your server at http://100.x.x.x:3000.

Authentication note: Tailscale Serve can act as a reverse proxy in front of Open WebUI and automatically pass the logged-in Tailscale user’s email to Open WebUI for SSO. This is covered in Open WebUI’s official Tailscale tutorial if you want to simplify the login flow further. For a family setup, the simpler approach is just using Tailscale for the network tunnel and letting Open WebUI handle its own login — two layers of auth, no configuration required.

Do not open port 3000 on your router’s firewall. Tailscale handles all external access privately. If you’re running Tailscale, there’s no reason to forward any ports.

Keeping the stack updated

Open WebUI ships updates roughly weekly. To update:

docker compose pull
docker compose up -d

Your user data, chat history, and models are stored in Docker volumes (open-webui_data and ollama_data), so they survive the container rebuild.

Check the Open WebUI releases page before major updates — occasionally a release changes behavior around auth or permissions.

Honest take: what actually works and what’s clunky

The multi-user system works well once configured. Each user gets isolated chat history by default. Admins can see a usage log. The model access controls are genuinely useful for keeping heavy models away from casual users who’d accidentally saturate the queue.

What’s clunky: the pending-approval flow requires re-enabling signup, having users register, then disabling it — there’s no invite link system. For a family of four this takes five minutes; for anything larger it becomes tedious. An alternative is to use OAuth/OIDC with Google or GitHub so users authenticate via an existing account, which removes the need to manage Open WebUI passwords entirely.

The other friction point is Ollama’s sequential request handling. If your teenager kicks off a 30-second generation with a 70B model, everyone else waits. The fix is running smaller models as the default and reserving the large ones for explicit use. The best CPU for AI workstations guide covers how system RAM speeds up model switching, which helps here.

What if you don’t have a local GPU?

CPU-only inference on Ollama is usable for 3B and 7B models — but generation slows noticeably without a GPU, and a shared server where multiple people are sending prompts simultaneously will feel sluggish. Anything larger than 13B gets impractical for shared use without dedicated GPU memory.

If the hardware isn’t there yet, the practical alternative is running the family server against a cloud GPU backend instead of a local Ollama instance. Open WebUI supports OpenAI-compatible endpoints — you can point it at a RunPod serverless endpoint running Llama 3.1 8B or similar, and your family gets the same polished multi-user interface with cloud GPU speed. You pay per token rather than upfront hardware cost, which keeps costs low for casual family use.

The hardware math for when local wins over cloud is covered in detail in Llama 3.3 70B at Home: Real Hardware Cost vs Cloud API Math.

Summary checklist

Task	Done
Docker Compose file with DEFAULT_USER_ROLE=pending	✓
First registration = admin account	✓
Re-enable signup → family registers → disable again	✓
Approve pending users in Admin Panel	✓
Create groups + restrict model visibility	✓
Pull models for the family	✓
Tailscale for remote access (optional)	✓

The full setup takes under an hour on a machine that already has Docker. The result is a shared AI server where each family member has a proper account, their own history, and only sees the models you’ve approved.

Sources

• Multi-User Setup — Open WebUI Docs
• Roles — Open WebUI Docs
• Permissions — Open WebUI Docs
• Groups — Open WebUI Docs
• Environment Variable Configuration — Open WebUI Docs
• Quick Start — Open WebUI Docs
• Tailscale Tutorial — Open WebUI Docs
• Hardening Open WebUI — Open WebUI Docs
• Self-host a local AI stack and access it from anywhere — Tailscale Blog
• Open WebUI Releases — GitHub

Last updated May 9, 2026. Software versions and default behaviors change; verify against official docs before deploying.