A Self-Hosted Assistant Your Team Can Use Safely

T02-L04 · Chat & assistants · Level 4 Integrator · 20-minute read, plus 120 minutes of doing

Everyone wants the chat, nobody asked who can reach it

In a lab it starts with a good idea. Lena, a postdoc in an eight-person structural biology group, wants an assistant for drafting methods, cleaning up Python scripts and summarising papers, including unpublished work. The institute offers no assistant of its own, and its rules keep unpublished results out of cloud chatbots. The group has a workstation with a large graphics card under a desk. On Tuesday she has a chat interface with a local model running on it. On Wednesday a colleague asks if he can use it from his office. On Thursday someone suggests "just opening the port".

In a company it looks different and ends the same way. Jonas is the quality manager at a twenty-person medical device supplier. Six people in quality draft SOP changes and answer customer questionnaires. He wants one assistant for them, with one set of rules, instead of six private chatbot accounts. There is no graphics card in the building, so the model will come from a provider through an API key. His managing director asks one question: "Who else can see what we type into it?"

Both of them are about to run a service for other people. This book shows you how to start it on one machine, where every prompt goes, and what has to be true before a colleague logs in.

You are at Level 4 Integrator: the group's real systems and data are in the loop. A mistake here doesn't spoil one chat. It exposes every chat of every colleague, runs up a bill on the company's key, or opens the machine it runs on to people it was never meant for.

After this you can

• Run Open WebUI through Heidelberg AI Desk and connect it to a model: a local one in Ollama or LM Studio, or a provider through an API key.
• Say where every prompt goes for the model you connected, and what Open WebUI keeps on your machine.
• Decide who may reach the assistant, how people get an account, and which data classes it may see.
• Set up accounts so new people wait for your approval and only named people can administer it.
• Name what has to change before a team uses it from other computers, and which books cover the server part.

Before you start

• Books: T11-L03 · Local AI apps your colleagues can rely on for Heidelberg AI Desk, volumes and backups. T02-L03 · Build a Shared Assistant Your Team Can Test and Take Over for the hosted alternative. T12-L01 for what may be pasted where. This book applies the four quadrants from T01-L01.
• Heidelberg AI Desk and Podman Desktop, installed and working, as in T11-L03.
• A model: LM Studio or Ollama on the same computer, with a model that fits its memory, or an API key from a provider your organisation has approved.
• Your organisation's data rules, and the name of whoever answers for the network (usually IT).
• About 2.5 hours: 20 minutes to read, 2 hours of doing.

Last verified 23 September 2026. Heidelberg AI Desk is a free internal beta that installs Open WebUI 0.5.20, which this book's labels match. Ollama has no login of its own, and LM Studio's login is off until you switch it on. Details for experts at the end of this book.

The idea in one page

A self-hosted assistant has three parts, and each one answers a different question.

Where prompts go depends on the model, not on the interface. Open WebUI is a front end. With a local model, the prompt goes from Open WebUI to LM Studio or Ollama on the same computer and no further. With a provider key, every prompt and every uploaded document goes to that provider, under the terms of the account the key belongs to. Self-hosting the interface doesn't change that.

Open WebUI keeps everything, on your machine. Every chat, every uploaded file and every account lives in Open WebUI's named volume, the storage Podman keeps for the container between restarts. That volume is now a store of whatever your colleagues paste into it, so it needs the same care as the data itself: backups, access and a rule for how long chats are kept. And an admin can read other people's chats from the Admin Panel. Tell your colleagues that before they start.

Reach is the part that grows. Desk opens apps on a local route: only the computer Desk runs on can reach them. That's the safest place to start, and for one person it's enough. The moment a colleague uses it from another computer, you run a network service. That needs a proper address, encryption (HTTPS), a firewall and someone who looks after it. That's a server job, and it has its own books: T11-L04 builds the server and T12-L04 locks it.

Model servers have no front door. Ollama has no login at all. LM Studio has one, but it's off until you switch it on. Anyone who can reach the model port can use the model, skip Open WebUI's login entirely, and leave no trace in it. So the model port stays closed to the network. The one exception is LM Studio with its login switched on, and only when nothing else works (see What goes wrong).

The blast radius grows with each step. Keep this table in view while you build:

This book takes you through stages 1 and 2 properly, and prepares stage 3. The server itself, with its HTTPS and firewall, follows T11-L04 and T12-L04.

Set up Open WebUI on one machine

1. In Heidelberg AI Desk, choose Open WebUI from the catalogue. Read what it needs before you install. Install it, press Start, wait until it's ready, and press Open.
2. Create your account immediately. The first account on a fresh Open WebUI becomes its administrator. Do this before anyone else could open the page.
3. Open the Admin Panel from your user menu, then Settings, then General. Check that Enable New Sign Ups is off, and that Default User Role is pending. Leave both that way.
4. Connect a model (below), start a new chat, pick the model, and ask something harmless. Check which model answered.

Connect a local model. Start your model server on the same computer first: LM Studio's server from T11-L02 (Developer tab, switch on the server, load a model), or Ollama with a model you've pulled. Open WebUI runs inside a container, so for it your computer isn't localhost. Podman gives the computer a name the container can use:

• LM Studio: in the Admin Panel, open Settings, then Connections. Under OpenAI API, add a connection with the URL http://host.containers.internal:1234/v1. LM Studio doesn't check the key unless you've switched on Require Authentication, so any placeholder text works.
• Ollama: in the same place, under Ollama API, set the URL to http://host.containers.internal:11434.

Save, go back to a new chat, and your model should appear in the model list. If it doesn't, see The model is running but Open WebUI can't find it below.

Connect a provider. Under OpenAI API, add a connection with the provider's API address and your key. Before you paste the key, set a monthly spending limit in the provider's console, and make sure the key belongs to the organisation's account, not your personal one. The key sits in Open WebUI's settings, so anyone who administers Open WebUI controls how it's used.

Look through Web Search and Code Execution in the admin settings, and Enable Community Sharing under General. Switch off whatever no task needs yet. Each one adds a path out of your machine or a way to run code on it. Add them back one at a time, when a task needs them.

Worked example: one assistant, two routes

Lab: a local model for unpublished work

Structure it. Lena: "Eight people need an assistant for drafting, code help and paper summaries, including unpublished results. No prompt may leave the institute. A useful result: people use it from their own desks, and I can say who has an account and where every chat is stored."

Understand it. She asks IT first whether the institute provides an assistant. It doesn't, and IT adds that the workstation sits on the general institute network, which several thousand people share. Then she tries it herself. She installs Desk on the workstation, then Open WebUI, and connects it to LM Studio running Gemma 4 on the big graphics card. It works on the first day. Three things come out of the test:

• Open WebUI keeps every chat in its volume on the workstation. The workstation has never been backed up.
• As admin, she can open anyone's chats. Two colleagues say they'd paste differently if they knew.
• Desk's route works only on the workstation itself. For people at their own desks, the assistant has to become a network service on the institute network. "Opening the port" would have put a login page, and behind it the whole group's unpublished work, in front of several thousand people.

Back to Structure it: "Eight named people, reachable only from the group's part of the network, with accounts I approve. Group material is fine; Restricted data (patient samples from the clinic collaboration) stays out. The chats are backed up weekly and deleted after six months. Until the server is ready, people use it at the workstation."

Choose tools. Down the ladder: the institute provides nothing, and a business plan with a US provider would break the institute's rule for unpublished results. Each person running Desk and a model on their own laptop (the T11-L03 pattern) would keep the blast radius small, but most laptops in the group can't run a model that's good enough. So: one assistant, on the workstation, with the local model. Stage 2 now, with Desk. Stage 3 with IT, following T11-L04 and T12-L04, with an address that only the group's network segment can reach.

Build it. She writes the assistant record before anyone else logs in:

GROUP ASSISTANT · Lindqvist lab · v1 · 2026-09-30 · review 2027-03-31

Interface: Open WebUI (via Heidelberg AI Desk) on workstation SB-07
Model:     Gemma 4 in LM Studio on the same workstation.
           Prompts never leave SB-07.
Reach:     now: only at SB-07 itself
           next: group network segment only, via IT (ticket 4471)
Accounts:  named members only; I approve each one; no sign-up
Admins:    Lena; deputy: Tom. Admins can read all chats.
Data:      Open and Group material yes. Clinic samples: NO (Restricted).
Chats:     backed up weekly (volume export to the group share);
           chats older than 6 months deleted at each review
Contact:   Lena · IT: servicedesk · DPO: [name]

She creates accounts for three colleagues through the Admin Panel, each as an ordinary user, and asks each to log in at the workstation, try one real task, and try to open the Admin Panel. None of them can. She exports the volume and restores it on her laptop once, as in T11-L03. At the group meeting she reads out one line of the record: Admins can read all chats. One person asks for their account to be removed until the server has a second admin. That's the record working.

What it taught her: the model was ready on day one. The week went into reach, accounts and the chat store, and each of those came from someone asking a question at the workstation.

Company: a provider key for six people

Structure it. Jonas: "Six people in quality draft SOP changes and answer customer questionnaires with one assistant and one set of rules. The managing director needs a one-line answer to 'who else sees what we type'."

Understand it. He sets up Open WebUI through Desk on his own laptop and connects the company's account with an EU-hosted provider through a key. Then he follows one prompt. It goes from his laptop to the provider, under the contract the company signed, and the chat stays in Open WebUI's volume on his laptop. He reads the contract's data section with the managing director: no training on their data, processing in the EU, thirty days of logs at the provider.

His test with real material finds a problem the contract can't fix. Complaint summaries from customers sometimes contain a patient's initials and a date of birth, copied from a hospital's report. That's health data. Back to Structure it: "SOPs and questionnaires, yes. Complaint records only after the patient details are removed, and never whole reports."

Choose tools. Down the ladder: a business plan with a large provider (T02-L03) would give six people a polished assistant without running anything. Jonas compares both on the managing director's question. The business plan answers it with a vendor's terms; the self-hosted route answers it with the company's own contract and keeps the chats on company hardware. The company already has the contract, so the self-hosted route wins, on one condition: it can't stay on his laptop. The pilot runs on Desk; the team version goes on a small server at the company's EU hosting provider, built by T11-L04 and locked by T12-L04 with the external IT contractor.

Build it. In the pilot he sets a monthly spending limit on the key, switches off web search, and creates two ordinary accounts to test with. His record has the same headings as Lena's, with two differences: Model: provider X, EU region, contract of 2026-03-01, no training, 30-day logs and Key: company account, limit €150 a month, only Jonas and the contractor can see it. The managing director gets her answer in one sentence: "The provider, under our contract, and the two of us who administer it."

What it taught him: the self-hosted interface didn't make the data path private; the contract and the paste rule did. The interface made it visible.

In both cases the model took an afternoon. The Level 4 work was deciding who can reach it, who has an account, and what may go in.

Making it available to a team

When you move from stage 2 to stage 3, three things change. Settle each one in the record before the server exists.

Who can reach it. Pick the narrowest audience that works: the group's network segment, the office network, or a VPN. The public internet is almost never the right answer for a small team. Only the HTTPS address is reachable; Open WebUI's own port and the model's port are not. The server steps (address, certificate, firewall, how to test from a second device) are in T11-L04. The checks that it's actually locked are in T12-L04.

Accounts.

• Sign-up stays off. You create accounts, or approve pending ones, by name.
• Two admins, named in the record, so the service doesn't depend on one person's holiday. Everyone else is an ordinary user.
• Leavers lose their account on their last day. Put it on the leaving checklist, next to the email account.
• If your organisation has central logins (single sign-on), ask IT whether Open WebUI can use them. Then leavers are handled for you.

Data.

• Write the allowed data classes into the record, using your organisation's classes or the three from T15-L04: Open, Group and Restricted.
• Decide how long chats are kept, and delete older ones at each review.
• Back up the volume and restore it once, as in T11-L03. The backup holds everyone's chats, so it goes where the data itself may go.
• Keep connectors, web search and tools off until a task needs one. Each one lets the assistant read or reach something new, and every account can use it.

Then the move itself. Your pilot's accounts and settings can come along in the volume export from T11-L03: restore it on the server before Open WebUI starts there for the first time, the way you tested it on a second computer. Before the first colleague logs in on the server, test with an ordinary account from a second device: sign-up is off, the Admin Panel is out of reach, and the model port doesn't answer.

What goes wrong

The port opened "just for a week". Symptom: Open WebUI answers from other computers on its own port, without HTTPS, because someone changed a firewall rule for a demo. Fix: close it. Team access goes through the server route in T11-L04, with HTTPS and a firewall, or not at all.

The model port with no lock. Symptom: someone reaches Ollama or LM Studio directly from another machine and uses the model without ever logging in to Open WebUI. Fix: keep model servers on their default, local-only setting. If LM Studio must serve the network, switch on Require Authentication first and give Open WebUI the token as its key.

The model is running but Open WebUI can't find it. Symptom: LM Studio or Ollama answers in your browser on the same computer, but the model list in Open WebUI stays empty. Fix: check that the connection uses host.containers.internal, not localhost, and that the server is on and a model is loaded. On some setups, especially on Windows, a container can't reach a server that listens only on the computer's own loopback address (127.0.0.1, reachable only from that computer). Don't solve that by opening Ollama to the network, because it has no login. Use LM Studio with Serve on Local Network and Require Authentication switched on together, and paste the token into Open WebUI's connection.

Sign-up left open. Symptom: an account you don't recognise appears in the user list. Fix: switch Enable New Sign Ups off, delete the account, and check what it could see. Test from a private browser window that the login page offers no sign-up.

Colleagues who don't know the admin reads along. Symptom: someone finds out later that admins can open their chats, and stops trusting the assistant. Fix: put it in the record, say it out loud when you create each account, and keep the admin list short.

A key without a limit. Symptom: the provider's bill triples in a month because one person pasted whole reports all day. Fix: set a monthly limit in the provider's console before the key goes into Open WebUI, and look at the usage at each review.

Only one person can fix it. Symptom: the assistant is down during Lena's conference week and nobody can restart it. Fix: a second admin, the T11-L03 run note, and one restart practised by that second person.

Do it yourself (120 minutes)

Use your own group or team. If you can't change network settings, do the steps and hand the network part to IT.

1. Structure it (15 min). Write one sentence: who needs the assistant, for which tasks, what data they'll paste, and what a useful result looks like. Name the second admin.
2. Understand it (30 min). Ask IT whether your organisation already provides an assistant. Install Open WebUI through Desk, create your admin account, connect a local model or a provider key, and follow one prompt: where does it go, what stays in the volume? Try it on one real task per data class you expect. Rewrite your sentence with what you found.
3. Choose tools (15 min). Go down the ladder: an assistant IT provides, a business plan (T02-L03), everyone on their own laptop (T11-L03), or a shared self-hosted one. Choose the model route, and write down in one line where prompts go.
4. Build it (60 min). Check that sign-up is off and new users are pending. Create one ordinary test account and check that it can chat but can't open the Admin Panel. Write the assistant record: model and where prompts go, reach now and next, accounts, admins, data classes, chat retention, backups. Export the volume and restore it once. Test the record on a colleague with three "may I paste this?" questions from your own work. If a team will use it from other computers, open the ticket with IT for the server part and start T11-L04.

Exit check

Delivered artifact: a one-page assistant record, plus Open WebUI running on one machine with a non-admin test account.

• The record names the interface and the model, and says in one line where prompts go. It states who can reach it now and next, how accounts are created and approved, who the admins are (and that they can read chats), which data classes are allowed, how long chats are kept, and where backups go.
• Open WebUI has sign-up switched off and pending as the default role. The test account can chat with the connected model and can't open the Admin Panel.

It passes when both of those checks hold, and a colleague who didn't write the record answers three "may I paste this?" questions about your own material correctly from the record alone.

Rule to remember

Self-hosted isn't private until you've decided who can reach it.

Details for experts

Checked on 23 September 2026. You don't need this to follow the book; it's for setting things up or answering a colleague.

If these details change, the three questions in this book (where prompts go, who can reach it, who has an account) stay the same.

Further reading and tools

Next books

• T11-L04 · Your own AI server: the server, address and HTTPS for team access.
• T12-L04 · Put a lock on it: securing a self-hosted stack: securing the stack before anyone else can reach it.
• T02-L05 · Running the assistant for everyone: from one team to a whole organisation.
• T15-L04 · Set up AI for a whole research group: paste classes and a data map for a group.
• T04-L04 · Permission-aware retrieval over real systems: before you connect the assistant to shared documents.

Tools

• Open WebUI: Taught. The chat interface in this book.
• Heidelberg AI Desk: Taught. Runs Open WebUI on one machine.
• LM Studio: Taught. The local model server in the lab example.
• Ollama: Taught. The other local model server; it has no login, so it never faces the network.
• Podman: Catalogued. The engine Desk uses underneath.
• IONOS AI Model Hub, Scaleway: Catalogued. EU-hosted providers to compare for the key route.
• ChatGPT, Claude: Catalogued. Business plans are the hosted alternative from T02-L03.