Last verified 12 October 2026, against the help pages of Heidelberg AI Desk 0.2.0-alpha.8 and the menus of the Open WebUI 0.11.4 it installs. Ollama has no login, and LM Studio's 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 at a local address: 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 · Put Your Team's Assistant on a Server Colleagues Can Reach builds the server and T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In 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, how much is exposed when something goes wrong, 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 · Put Your Team's Assistant on a Server Colleagues Can Reach and T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In.

Set up Open WebUI on one machine

1. In Heidelberg AI Desk, open the App Store and press Install and open on Open WebUI. Desk starts Ollama first; together the two are a download of about 10 GB, so the first start takes a while.
2. Create your account immediately. Click Get started, enter your name, an email address and a password, and click Create Admin Account. 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 Authentication. Under User Access, check that 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. The quickest route is the Ollama that Desk started with Open WebUI. The two are already connected, but a fresh Ollama has no model. In a new chat, click Select a model, type llama3.2:3b into the search field and click Download "llama3.2:3b". It's 2 GB. That model answered in the Desk team's test; two much smaller ones gave no usable answer. Desk's Ollama computes on the processor, not on a graphics card, so larger models are slow in it.

To use LM Studio instead, start its server first, as in T11-L02 · A Local Model Your Tools Can Call (Developer tab, switch on the server, load a model). Open WebUI runs inside a container, so for it your computer isn't localhost. Podman gives the computer a name the container can use. 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.

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 (the group's unpublished work) 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 · Local AI Apps Your Colleagues Can Rely On 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 · Put Your Team's Assistant on a Server Colleagues Can Reach and T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In, with an address that only the group's network segment can reach.

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

She creates accounts for three colleagues under Users in 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 · Local AI Apps Your Colleagues Can Rely On. 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 · Build a Shared Assistant Your Team Can Test and Take Over) 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 · Put Your Team's Assistant on a Server Colleagues Can Reach and locked by T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In 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 · Put Your Team's Assistant on a Server Colleagues Can Reach. The checks that it's actually locked are in T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In.

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 · Set Up AI for a Whole Research Group: Open (already public, such as published papers), Group (unpublished results, manuscripts, internal protocols) and Restricted (personal and patient data, material under a collaboration agreement, passwords and keys).
• 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 · Local AI Apps Your Colleagues Can Rely On. 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 · Local AI Apps Your Colleagues Can Rely On: 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 · Put Your Team's Assistant on a Server Colleagues Can Reach, 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. With Desk's own Ollama, an empty list only means that no model has been downloaded yet. 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 one-page run note from T11-L03 · Local AI Apps Your Colleagues Can Rely On (how to start, stop, back up and restore the app), 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 · Build a Shared Assistant Your Team Can Test and Take Over), everyone on their own laptop (T11-L03 · Local AI Apps Your Colleagues Can Rely On), 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 under Users in the Admin Panel 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 · Put Your Team's Assistant on a Server Colleagues Can Reach.

Exit check

What you hand in: 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 12 October 2026 for Heidelberg AI Desk, Open WebUI and Ollama, on 23 September 2026 for LM Studio. 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 · Put Your Team's Assistant on a Server Colleagues Can Reach: the server, address and HTTPS for team access.
• T12-L04 · Lock Down a Self-Hosted AI Service Before Real Data Goes In: securing the stack before anyone else can reach it.
• T02-L05 · Run One Assistant for a Whole Institute or Company, and Hand It Over: 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 · Connect an Assistant to Real Documents Without Widening Anyone's Access: 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 · Build a Shared Assistant Your Team Can Test and Take Over.