Open WebUI Multi-User Setup 2026: Auth, User Roles, and Model Access Controls

This article was originally published on runaihome.com

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