Why EU data residency changes the ChatGPT Enterprise decision
If a renewal, residency review or data protection question has landed on your desk, the question to answer first is where each data type must sit. Open WebUI or LibreChat deployed in EU infrastructure can keep the conversation store, the retrieval index and the model endpoints under your organization's control, but whether that fits depends on the residency scope you actually need. Some obligations concern where content is stored at rest, others concern where inference runs, and others concern who can administer the logs. Write those three scopes down before comparing products.
OpenAI's regional data residency is a documented control. Per OpenAI's help center, it stores in-scope ChatGPT content at rest in a selected region for eligible API customers and for new ChatGPT Enterprise and Edu customers, and inference residency is offered in some regions on top of that. ChatGPT Enterprise is still an OpenAI-hosted service, though, and the controls OpenAI documents for it are SAML SSO, admin retention settings, regional data residency and SOC 2 Type 2 audits. Ask OpenAI in writing which regions, which data types and which features fall inside the residency commitment for your contract, and whether any of your planned use is excluded.
Self-hosting moves those answers into your own change control, but it also moves the responsibilities. Your team would select the EU region or data centers, decide where backups and file uploads are kept, and document which model endpoints receive prompts, including any hosted provider called through an OpenAI-compatible API. Confirm with your counsel and data protection officer which legal obligations apply to your processing before you rely on any architecture. This page does not reach legal conclusions, and an independent auditor or certification body, not DeployOpen, would assess any resulting controls.
What EU data residency requires of your conversation store and model endpoints
EU data residency is not one setting. It is a set of decisions about where conversations, retrieval indexes, uploads, model inference, logs and identity records sit, and who can change them. The cards below separate those decisions so you can confirm each one against your own scope before comparing hosted and self-hosted options.
Where conversation data rests
Conversation history, message metadata and uploaded files are written to a database and file store. OpenAI offers a selected storage region for eligible ChatGPT Enterprise customers, while a self-hosted Open WebUI deployment places the database in the EU cluster you choose. A multi-instance deployment needs PostgreSQL rather than SQLite, so confirm which EU region holds every database replica and backup copy.
Who controls retention and deletion
In ChatGPT Enterprise, workspace admins set retention, and OpenAI states that deleted conversations are removed from its systems within 30 days unless legally required. In a self-hosted stack, retention is a configuration and backup policy you write yourself. Decide how long chats, deleted records and backups persist, and confirm that deletion reaches replicas, object storage and snapshots.
Where retrieval indexes and uploads live
Documents uploaded to a chat and the vector index built from them are separate data stores from the conversation database. Open WebUI supports 13 vector databases, so the choice affects where embeddings sit. Multi-replica deployments also need shared file storage so uploads and knowledge stay reachable from every replica. Confirm the region for each store, including embedding model calls.
Where inference runs
Data residency for storage does not guarantee where prompts are processed. OpenAI offers inference residency only in some regions on top of data residency, so confirm the regions and the model endpoints your team uses. A self-hosted stack can route to a model served on EU hardware through an OpenAI-compatible server such as vLLM, or to a provider endpoint you select. Ask every model provider for its processing location in writing.
Who can access logs and exports
ChatGPT Enterprise admins can view, export and delete end user conversations, and the Enterprise Compliance API is the documented export path. In your own stack, application logs, metrics, reverse proxy logs and database exports each need an owner and an access list. vLLM exposes Prometheus metrics that can include operational detail, so restrict who scrapes them. Define who reviews exports and where they are stored.
How identity is enforced
Identity decides who can open a conversation and which sources a user can retrieve from. ChatGPT Enterprise supports SAML SSO. Open WebUI documents SSO through OIDC and LDAP, SCIM 2.0 provisioning, and role-based access control with groups. LibreChat supports OAuth2, LDAP and email login. Confirm that your identity provider lives in the EU, that deprovisioning removes access to chats and knowledge, and that MFA is enforced at the identity layer.
Where ChatGPT Enterprise residency controls stop
The documented residency controls for ChatGPT Enterprise cover a defined slice of the data lifecycle. OpenAI's data residency stores in-scope content at rest in a region you select, and it is available to eligible API customers and to new ChatGPT Enterprise and Edu customers. Inference residency, where prompts are processed in-region, is offered only in some regions and sits on top of data residency. Around that, your workspace admins set retention, and deleted conversations are removed from OpenAI's systems within 30 days unless law requires otherwise. The service also carries SAML SSO and an independent SOC 2 Type 2 audit. Those are real controls, and for many teams they answer most questions in a vendor review.
Residency does not cover everything the service does. ChatGPT Enterprise runs only as an OpenAI-hosted service, so the platform, its operators, its subprocessors and its upgrade schedule sit outside your infrastructure. You cannot place the application, the conversation store or the retrieval layer in an EU cloud account or data center of your choosing, and you cannot inspect the network path a prompt takes. Where an EU regulator or your own data protection office asks where processing happens and who can access it, the answer depends on OpenAI's documentation and your contract, not on your own configuration.
Before deciding, ask OpenAI in writing which regions are available under your contract, whether your region includes inference residency or only data at rest, which content types are in scope (conversations, uploaded files, custom GPT data, logs and any Compliance API exports), and whether support or abuse-monitoring access can involve staff outside the region. Record the answers with the contract date. If a self-hosted design is needed, the same questions apply to each component you would run in EU infrastructure, starting with the model endpoint, which determines whether prompts leave the EU at all.
Which open-source option fits EU data residency best
This table compares Open WebUI, LibreChat, Onyx and AnythingLLM on where conversations, retrieval indexes and model endpoints sit, how sign-in works, and what licensing applies. Open WebUI and LibreChat are the chat interfaces this page centers on, while Onyx and AnythingLLM suit document-heavy use. Use the confirm column to check each point against your own build before you commit.
| Criterion | Open WebUI | LibreChat | Onyx and AnythingLLM |
|---|---|---|---|
| Conversation store | Runs in your infrastructure. Scaled deployments need PostgreSQL and shared storage, so confirm the database sits in your EU region. | Runs in your infrastructure with MongoDB in the reference Docker setup. Confirm where the database and backups are placed. | Onyx runs its database and index in self-contained services you deploy. AnythingLLM stores data locally in its Docker or desktop install. Confirm both in your environment. |
| Retrieval index | Supports 13 vector databases, including ChromaDB, PGVector, Qdrant, Milvus and Elasticsearch, so you choose where the index lives. | Uses a separate RAG API service alongside Meilisearch in the reference compose file. Confirm the index and embedding path stay in the EU. | Onyx's document index runs inside your deployment and can be air-gapped. AnythingLLM uses built-in or chosen vector databases. Confirm which one you select. |
| Model endpoints | Connects to Ollama, OpenAI, Anthropic or any OpenAI-compatible provider. Pair with self-hosted vLLM to keep inference in your network. | Supports OpenAI, Azure OpenAI, Google, Vertex AI, Anthropic, AWS Bedrock, Ollama and custom endpoints. Confirm which provider regions you use. | Onyx works with self-hosted models through Ollama, LiteLLM or vLLM. AnythingLLM connects local or cloud LLMs. Confirm any cloud endpoint's processing region. |
| Identity options | OIDC and LDAP SSO, SCIM 2.0 provisioning, role-based access control with groups, and authenticator-app MFA. | OAuth2, LDAP and email sign-in with an admin panel. Confirm whether SAML is needed for your identity provider. | Onyx supports Google OAuth, OIDC or SAML and SCIM. AnythingLLM supports multiple users with workspace-level permissions. Confirm the tier that includes your features. |
| Licensing constraints | Open WebUI License. Branding changes are restricted above 50 users in a rolling 30-day period unless you hold an enterprise license or written permission. | MIT licensed with no branding clause in the README. Confirm the current release terms before deployment. | Onyx Community Edition is MIT, but code in ee directories requires the Onyx Enterprise License. AnythingLLM is MIT licensed. |
| Release and maintenance | Frequent releases, including v0.12.3 on October 16, 2026. Your team or a partner must apply upgrades and patches. | Latest tagged release is v0.8.8, a pre-release. ClickHouse acquired the project in November 2025. Confirm the release channel you will track. | Onyx and AnythingLLM publish open-source releases you run yourself. Confirm the upgrade process and who owns it in your operating model. |
| Main trade-off | Strong for a multi-provider chat interface, but the branding clause and multi-replica setup add decisions. | Broad agent and MCP support with several providers, but the stack spans more services to run and secure. | Best suited to chatting over company documents. Less focused on a general chat front end, so confirm fit for your main use. |
How to deploy Open WebUI for EU data residency step by step
This sequence takes a team from an EU hosting decision to a multi-replica Open WebUI deployment with PostgreSQL, Redis, identity provisioning, a vector store, guarded model endpoints and routine operations, all inside infrastructure the organization controls.
Confirm EU hosting and residency scope
Before any installation, the platform owner and the data protection lead agree where every component will run and which data each one holds. The list should cover the conversation database, the file store, the vector index, logs, backups and each model endpoint, whether that endpoint is a local Ollama or vLLM server or an external API. Confirm with each external model provider in writing where inference runs and whether prompts are retained, because an EU-hosted interface still sends prompts elsewhere if a remote API is selected. The step is done when the residency register is signed off and every component has a named EU location and owner.
Install Open WebUI with Docker Compose or Helm
The platform engineer deploys Open WebUI in the chosen EU cloud account, data center or cluster using Docker and Docker Compose for a single host, or Kubernetes with Helm for a cluster. Pin the image to a specific release tag rather than a floating tag, and record the version in the change log. Keep the first deployment on a private network with no public ingress. The step is done when the login page loads from an internal address, a test account can start a chat, and the version number is recorded in the asset inventory.
Move the database from SQLite to PostgreSQL
The platform engineer points Open WebUI at a PostgreSQL instance in the same EU region before users are onboarded. The scaling guide requires PostgreSQL for multi-instance deployments because SQLite does not handle concurrent writes from multiple processes well, so the change is needed before a second replica exists. Use managed or self-run PostgreSQL with encrypted storage and backups, and confirm the database admin role is separate from the application role. The step is done when a conversation created in the new deployment is written to PostgreSQL and survives a container restart.
Add Redis and shared file storage for replicas
When more than one Open WebUI replica is needed, the platform engineer adds Redis as the shared state store for sessions, websocket connections and application state, and places uploads and knowledge files on shared storage that every replica can reach. Both components should sit in the same EU region as the database. Test by stopping one replica during a chat session and confirming the user is not dropped and a previously uploaded document is still retrievable. The step is done when this failover test passes and the storage location is recorded in the residency register.
Connect OIDC or LDAP and enable SCIM
The identity team connects Open WebUI to the organization's identity provider using OIDC or LDAP, which the features documentation lists as supported single sign-on options. Enable SCIM 2.0 so users and groups are provisioned and removed from the directory rather than created by hand, and map directory groups to Open WebUI groups before granting any model or knowledge permissions. Confirm that a user removed in the directory loses access at the next sign-in. The step is done when a test leaver is denied access and group membership matches the directory.
Select the vector database and index EU content
The platform engineer chooses a retrieval backend from the vector databases Open WebUI supports, such as PGVector if PostgreSQL is already run, or Qdrant as a separate service. Confirm that the index, its embedding model and any reranker run inside the EU boundary, because embeddings are derived from personal or confidential text. Ingest a small pilot knowledge collection and check that answers cite the expected files. The step is done when the index location is in the residency register and the pilot answers match the source documents.
Place model endpoints behind an allowlist proxy
The platform engineer exposes model endpoints, such as vLLM's OpenAI-compatible server or an Ollama service, only through a reverse proxy that allowlists the routes users need. The vLLM security documentation warns that its --api-key option does not protect every route, including /metrics, /health and /invocations, and recommends an allowlisting proxy, so block all other paths. Keep the metrics route reachable only from the monitoring network. The step is done when a direct request to a blocked route fails and a chat request through the proxy succeeds.
Run backups, log retention and access reviews
The operations lead sets a backup schedule for PostgreSQL, the file store and the vector index, and tests a restore into a separate environment before go-live. Define the log retention period in the security policy and confirm that prompt and response logs are kept, reviewed and deleted under that policy. Schedule upgrades by testing each new release in a staging copy first, and run a recurring review of group membership and admin roles. The step is done when a restore test completes, the retention setting is documented, and the first access review is signed by the data owner.
Choosing model endpoints that stay inside the EU boundary
vLLM runs the model on GPUs you place in an EU data center or cloud account, so prompts and completions are processed only where you put the hardware. The server, started with vllm serve, exposes OpenAI-compatible routes including /v1/chat/completions, /v1/completions, /v1/responses and /v1/embeddings, which lets Open WebUI or LibreChat point at it as a provider.
- API key scope: The
--api-keyoption protects routes under/v1,/v2,/inferenceand/cohere, but not/invocations,/pause,/resume,/abort_requests,/metricsor/health. Do not rely on it alone. - Reverse proxy allowlist: Put a proxy in front of the server that forwards only the endpoints users need, such as chat and embeddings, and blocks the control routes from the network.
- Metrics and health:
/metricsexposes request counts, token throughput, latency and KV cache use, and/healthreveals service state. Restrict both to your monitoring network. - Multi-node traffic: Node-to-node communication in a multi-node deployment is insecure by default, with no authorization or encryption, so isolate those nodes on a private network.
Confirm with your platform team which GPU region and network path the traffic uses, and whether any logging layer outside vLLM records prompts.
Ollama runs smaller open-weight models on a single host, such as a workstation or a modest on-premises server, and serves them to Open WebUI over its local API. Inference stays on that machine, which makes it a practical option when the model size fits the hardware and the workload is interactive rather than high volume.
- Placement: Install the host in the EU site you have approved and keep the model store on encrypted disks you control.
- Network binding: Bind the Ollama API to a private interface or a loopback address behind the interface container, rather than exposing it to every network segment.
- Model provenance: Record which model files and versions were pulled, and keep an internal copy so you can reproduce a result during review.
- Capacity limits: Single-host setups have no built-in failover, so an outage stops every user on that endpoint until the host recovers.
- Scale path: When concurrency or model size outgrows one host, move the same model class onto vLLM with a reverse proxy in front.
Confirm that the host, backups and any swap or crash dumps stay in the approved region, since a small server is easy to overlook in data flow diagrams.
An external provider reached through an OpenAI-compatible API means prompts leave your infrastructure and are processed on the provider's systems. The EU boundary then depends on the provider's contract, region options and retention terms, not on your own hardware. Open WebUI and LibreChat both accept custom OpenAI-compatible endpoints, so the integration is simple to set up and easy to switch on by mistake.
- Processing region: Ask in writing where inference runs, whether that is an EU region only, and whether any fallback or load balancing sends traffic elsewhere.
- Retention and training: Confirm how long prompts, outputs and logs are kept, whether they are used for training by default, and how deletion works on request.
- Subprocessors: Obtain the list of subprocessors and any sub-contracted inference hosts, and check whether they change over time.
- Gateway placement: If you route through a gateway, confirm where that gateway logs requests and where its database sits.
- Contractual terms: Make sure the data processing agreement and the region commitment cover the exact service and model you plan to use.
Check these answers against the provider's current documentation and contract before any user data is sent.
Evidence an EU data residency review asks you to produce
An EU data residency review checks where each store sits, who can reach it, and what is kept and for how long. The cards below are the records that connect those answers, and most of them must be produced from your own environment rather than inherited from a vendor. DeployOpen prepares systems, controls and evidence, but independent auditors or certification bodies make the compliance determinations.
Data flow map by store
A diagram and table showing where the conversation database, retrieval index, file storage, cache and each model endpoint run, which region and account each sits in, and which network paths connect them. Reviewers use it to confirm that no store falls outside the approved EU boundary. Check that backups, logs and observability exporters are on the map too, because they often hold prompt text and are easy to miss.
Retention and deletion settings
Exported configuration showing how long chats, uploads, embeddings and audit logs persist, and how deletion reaches each store. For Open WebUI and LibreChat, record the settings in your deployment configuration and the database rules that apply. Test deletion end to end, including vector entries and cached copies, and keep the test result as evidence. Ask the team who holds the approval to change these values.
Access control and group mapping exports
Exports from your identity provider and the application showing which groups map to which roles, which users hold administrator rights, and which knowledge collections each group can read. Open WebUI documents SSO through OIDC and LDAP, SCIM 2.0 provisioning, and role-based access control with groups. Capture the mapping at a fixed date, then repeat the export on a schedule so reviewers see changes over time.
Audit and access logs
Logs that record logins, role changes, administrative actions, data exports and deletions, with the retention period and the place where they are stored. Confirm that logs are written to a store inside the EU boundary and that access to them is restricted and reviewed. Logs of prompts and responses need the same classification as the conversation store, so decide whether they are captured at all.
Backup location records
A register of every backup set, its storage location, encryption method, replication target, retention period and restore test date. Backups of the database, object storage and vector index all count, and a copy sent outside the EU can undo the residency design. Ask your backup vendor or platform team to confirm where replicas are written and who holds the keys.
Model endpoint register
A list of every model the assistant can call, including self-hosted vLLM or Ollama servers and any external API, with the physical region, the operator, the data retention terms and whether prompts are used for training. Self-hosted endpoints keep prompts inside your network, while external APIs bring their own terms that you must obtain in writing. Re-check the register whenever a model is added or a provider changes its terms.
How much does EU data residency cost to run in-house?
What are the main cost components of running Open WebUI or LibreChat in EU infrastructure?
The cost splits into the infrastructure you rent or own, the model inference you pay for, and the people who build and run the stack. The main lines are compute for the application, a PostgreSQL database, Redis and shared file storage for multi-replica setups, a vector database for retrieval, EU-region object or block storage, and the model endpoints, whether those are GPUs you operate or API calls to a provider with EU processing. Add SSO integration, backups, monitoring, upgrades and support. Each line has a different payer: your cloud provider or data center, your model vendor, and either your own staff or a DeployOpen engagement for implementation and support.
Which costs are one-time and which recur every month?
One-time costs usually include scoping, architecture, initial installation, SSO and directory integration, data migration from exports, hardening, and documenting controls for an assessment. Recurring costs include cloud or hardware capacity, GPU or API inference consumption, database and storage growth, backups, monitoring, license fees where they apply, and patching and upgrades. Upgrades deserve a line of their own because Open WebUI and LibreChat both ship releases regularly, and each one needs testing in a non-production environment before it reaches users.
What drives the running cost of a self-hosted EU assistant up or down?
The largest drivers are the model choice and where inference runs. Hosted API models bill per token and scale with usage, while self-hosted models on GPUs bill for capacity whether or not it is busy. Other drivers include the number of concurrent users, the size of the document corpus that gets embedded and stored, how many replicas you need for availability, how long conversations and uploads are retained, and the EU region you select, since pricing differs between providers and regions. Reducing retained data and right-sizing the GPU pool are usually the most direct levers.
How long does an EU-hosted assistant deployment take to implement?
Duration depends on the scope you agree, not on the software alone. The biggest factors are how many identity sources and groups must map to roles, how many document sources need indexing with their permissions, whether you need a single instance or a multi-replica setup with PostgreSQL, Redis and shared storage, whether a self-hosted model server needs GPU procurement, and how much review your security and compliance teams require before go-live. Ask DeployOpen or any implementation partner for a timeline tied to a written scope, with the assumptions listed so you can see what would move it.
What does the work need from our internal team?
Expect time from several roles. Your identity team needs to supply SSO configuration and group structure. Your cloud or infrastructure team provides the EU-region accounts, networking, secrets handling and backup targets. Your security team reviews access, logging and data flows, and your data owners decide which sources are indexed and who can see them. Someone must own the platform after handover to approve upgrades and respond to incidents. Naming these owners early usually matters more to the schedule than the installation itself.
Can our own team run an EU-hosted assistant without an implementation partner?
Yes, if you have engineers comfortable with containers or Kubernetes, PostgreSQL, identity federation and GPU operations. Both Open WebUI and LibreChat publish Docker-based install methods, and Open WebUI also documents Kubernetes with Helm. The gaps tend to appear in multi-replica scaling, model serving, retrieval tuning, backup restore testing and control evidence. Be realistic about capacity: a team that can deploy a demo may still need outside help to harden, document and support the stack for regulated use. Many organizations split the work, keeping day-to-day operations in-house and buying design, hardening or retainer support.
What should we ask for in a fixed-scope quote for this work?
DeployOpen does not publish prices. A quote follows from a written scope, which is normally agreed before work starts. Ask for:
- The list of systems in scope, including the chat interface, database, vector store, model endpoints and SSO connections
- Deliverables for architecture, installation, integration, hardening, backup and handover documentation
- Which EU regions and accounts are used, and who holds the keys
- Assumptions about user counts, source volume and model choice, with what changes the price
- Whether ongoing support, upgrades and testing are a separate retainer
- Who pays for cloud, GPU and model consumption, which is normally your organization directly
- Acceptance criteria and the timeline with its dependencies
Does the price of ChatGPT Enterprise compare directly with self-hosting costs?
Not directly. ChatGPT Enterprise is a per-seat subscription for an OpenAI-hosted service, and OpenAI's data residency options are offered to eligible customers under their own terms, so you should confirm the current price and regional options with OpenAI. A self-hosted stack moves cost into infrastructure, inference and people, which scale differently. For a fair comparison, model both sides across the same user count, retention period and support level, and include the staff time for upgrades and incident response on the self-hosted side.
How DeployOpen deploys AI chat under EU residency requirements
DeployOpen plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including EU cloud accounts, data centers or isolated networks. For EU residency work, that means the conversation store, retrieval index and model endpoints are scoped and placed where the client's own controls apply.
How we scope
- Written scope fixes which chat interface, retrieval index and model endpoints sit in EU infrastructure.
- We confirm with you which data categories, user groups and sign-in methods the deployment must cover.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We install Open WebUI or LibreChat with PostgreSQL, shared storage and the retrieval services your scope requires.
- We connect SSO, group mapping and role-based access, then test that permissions behave as documented.
- We configure model routing to EU-hosted endpoints and run security testing against the deployed stack.
How we hand over
- You receive architecture documentation covering data locations, backups, logging and retention settings.
- We document license obligations, including the Open WebUI branding clause, so your team can confirm its position.
- We prepare configuration and evidence for your compliance assessors, who issue any audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades follow each project's release notes, and we test them in a staging environment before production.
- Your team keeps administrative control, and we advise on any change that affects data location or access.
