PilaePilae
Talk to us

Operate

Deploy

Services

Start with one workload

Fixed-price onboarding, then a monthly plan per managed app. Your estate grows one app at a time.

09:41 discover  keycloak 26.1.4
09:41 backup    verified, zur1
02:00 apply     rolling, ok
02:01 restore   drill ok, 1m02s
Talk to us

By project

By industry

By role

Private AI, on your own servers

Chat, search and drafting with open models on infrastructure you control, operated by Pilae.

See private AI

AI and LLM

Workflow and data

Data and streaming

Collaboration and identity

Business

Engineering and security

Browse

Security and operations

Compliance and legal

Request the security pack

DPA, sub-processor list and architecture overview, sent to your security or procurement team.

Request the pack

Learn

Compare

Company

News from Pilae

New apps, new regions and posts from the blog, as they ship.

Follow on LinkedIn
  1. Pilae
  2. Apps
  3. Open WebUI

Managed Open WebUI hosting

AI and LLMOn-prem or your region

A chat interface over models you host, so prompts and the documents people paste into them never leave your network. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about Open WebUI

Licence
Open WebUI License
Runs on
Your own hardware, or any of 10+ Pilae regions — six of them in Switzerland and the EU
Upgrades
Pinned, tested against your configuration, applied in your window
Upstream
openwebui.com

Running Open WebUI in production: what it takes

  1. Size, then pin and deploy

    A version we have run, against the model server your hardware justifies, with Postgres and pgvector behind it instead of the default file.

  2. Put it behind your identity provider

    OIDC sign-on and group-based access to models, so an expensive model is not available to everyone by accident.

  3. Wire retrieval to your own documents

    The file share or wiki indexed into pgvector, with permissions respected — a retrieval layer that ignores who may read what is a data leak with a chat interface.

  4. Back up conversations and index

    We take the database and the vector store offsite nightly. Once a month we restore both into a scratch environment and ask a question against the restored index.

  5. Upgrade in your window

    The project moves fast and the schema moves with it. We hold your version, test the next against a copy of your data, and apply it in the window you agreed.

What Open WebUI is, and who runs it

Open WebUI is a chat interface. It looks like the commercial assistants people already use — threads, history, file uploads, shared prompts — and it sits in front of whichever model you point it at: something running on your own GPUs, or a hosted API if you decide that trade is acceptable for a given use.

It is usually the first thing an organisation deploys when the answer to “can we use ChatGPT for this” has become no. The refusal is rarely about the model’s quality; it is about the documents people paste into it. A contract, a patient record, a draft set of accounts — once it has gone to a third party, it has gone, and no policy retrieves it.

Running the interface yourself changes where that boundary sits. With models on your own hardware, a prompt and everything attached to it stays inside the network. The retrieval layer goes further: Open WebUI can index your own file share or wiki and answer from it, which is the capability the public tools cannot offer at all, and in practice the one that makes people stop using them.

The things that go wrong are consistent. The default SQLite database holds every conversation in one file and does not survive real use. Without sign-on wired to your directory, access is whoever found the URL. A retrieval layer that ignores your file permissions is a data leak with a chat interface in front of it: it will quote a document to someone who was never allowed to open it. And a deployment sized for a model the hardware cannot actually serve produces an assistant slower than the one people were told to stop using, which ends the project more reliably than any policy.

Open WebUI ships under a BSD-3-clause licence with one added condition: above fifty users in any thirty-day period you must keep the project's branding, unless you hold an enterprise licence from them or you are a merged contributor. Fifty or fewer is exempt. Nothing else about internal use is restricted. Most organisations we deploy for are over that line, so if you want it white-labelled we start that conversation with the project before you ask.

Open WebUI system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

GPU
NVIDIA, sized to the modelEnough memory for the model at the context length you need. Open WebUI can front a hosted API instead, in which case you need no GPU — and nothing stays on your side.
CPU and memory
4 vCPU · 8 GBFor the interface. The interface is small; the inference is what costs.
Database
PostgreSQLThe default SQLite holds every conversation in one file, which stops being appropriate past a handful of people.
Vector store
pgvectorIn the same Postgres, for retrieval over your documents. One database to back up rather than two.
Identity provider
OIDCSo accounts arrive from your directory, instead of anyone who finds the URL being able to sign in.

Migrating from ChatGPT Team to Open WebUI

There is nothing to migrate, and that is the difficulty. People do not keep documents in ChatGPT Team; they keep habits. A private deployment that answers more slowly, or worse, than the tool they were using gets abandoned within two weeks. So the move is a sizing exercise, not a data migration. We work out which models your hardware can serve at the speed people expect. We tell you where a local model is weaker than the one they use today. And we put retrieval over your own documents in place early, because answering questions about your own files is the one thing the public tool cannot do.

  1. Size the hardware against the model

    Which models your GPUs can serve, at what context length, for how many people at once. This decides whether the rollout works, and it is answered before anything is installed.

  2. Put it behind sign-on

    Accounts from your directory, groups deciding who reaches which model. Nobody gets a new password and a leaver loses access with everyone else.

  3. Connect your documents

    Retrieval over the file share or the wiki. This is the capability that makes people switch, rather than the one that makes them tolerate the switch.

  4. Run both and watch which one people open

    The public tool stays available while the internal one is measured. If the internal one is not being used, the answer is sizing or retrieval, and we say which.

Where the model runs, and what leaves your network

Ollama on your GPUsYour hardwareNothing.
vLLM on your GPUsYour hardwareNothing.
Ollama on a Pilae siteAny Pilae regionNothing outside the region you picked.
OpenAI-compatible APIThird partyEvery prompt and every attachment.
Document retrievalpgvector, beside the appNothing. Your permissions are respected.
Open WebUI is an interface; where inference happens is a configuration choice, and it is the choice that decides whether anything leaves your network. We size this before anything is installed.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs
zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials
You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave
The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What running Open WebUI costs

On Starter, Open WebUI runs in Pilae Cloud for CHF 449EUR 479USD 559 a month, hosting and onboarding included. On Business, it is one of up to three apps for CHF 1,590EUR 1,690USD 1,990 a month, on your own servers or in Pilae Cloud. Enterprise is quoted. The plans set what each includes; these are the inputs that move the price around them.

Instance size
The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability
One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups
How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support
Starter, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region
Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where machines are priced per month. On Starter, Pilae chooses the site.
Sign-on and integrations
Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Open WebUI: common questions

Does anything we type reach a third party?

Not if the model runs on your hardware. Open WebUI is an interface; where the inference happens is a configuration choice. Point it at local models and nothing leaves. Point it at a hosted API and the prompts go there, which is sometimes the right trade and is never made by accident.

What hardware do we need?

It depends entirely on the model and the number of people using it at once, which is why sizing comes before installation. We work out what your existing GPUs can serve and tell you plainly when the answer is that they cannot serve what you are asking for.

Can it answer questions about our own documents?

Yes, and it is usually the reason the rollout succeeds. Documents are indexed into pgvector and retrieved at query time, with your permissions respected so the retrieval cannot surface a file the person asking may not read.

Is Open WebUI open source?

Not strictly. It is BSD-3 with one added condition: above fifty users in any thirty-day period you must keep the project's branding, unless you hold an enterprise licence from them or contribute to the project. Fifty or fewer is exempt. Nothing else about internal use is restricted, and a white-labelled deployment is a conversation with the project that we will start for you.

What happens to conversations if we leave?

They are in your Postgres, on your machine or in your account, and the compose files and runbook are in your repository. Nothing about them depends on us being here.

Also in ai and llm

Ollama

A server that loads open-weight models on demand behind an OpenAI-compatible API, run on GPUs in Switzerland, the EU or your own datacentre so prompts never reach a model vendor.

Replaces OpenAI API, Azure OpenAI

vLLM

An OpenAI-compatible inference server for open-weight models, run on GPUs in Switzerland, the EU or your own datacentre, so prompts and answers never reach a model vendor.

Replaces OpenAI API, Azure OpenAI

LibreChat

One chat interface over every model your organisation allows, local or hosted, with the keys, the history and the choice of provider held on your side.

Replaces ChatGPT Team, Poe

Back to apps

Bring us your Open WebUI. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.

Start with one workloadBook a 30-minute briefing