OpenAI Brings ChatGPT Sites to Enterprise With EU Data Residency
OpenAI has moved ChatGPT Sites from beta to general availability for Enterprise, adding regional data residency, custom domains, and private tunnels to internal APIs.
- ChatGPT Sites is now generally available for Enterprise workspaces.
- New Sites support US or EU data residency in eligible workspaces.
- Workspace custom domains let orgs publish on verified corporate domains.
- Private tunnels connect hosted Sites to approved internal infrastructure and APIs.
- Plugins in Sites let each teammate load their own connected app data.
- Team apps now include relational databases, file storage, and Sign in with ChatGPT.
OpenAI adds data residency and private access to ChatGPT Sites
OpenAI has made ChatGPT Sites generally available for eligible Enterprise workspaces. New Sites can use US or EU data residency, while verified corporate domains and private tunnels give deployed apps controlled access to internal systems.
Sites is OpenAI’s in-chat builder for websites, web apps, and games. A user describes an app in a prompt, ChatGPT creates and hosts it, and Sites returns a production URL without requiring a separate CI pipeline, cloud console, or hosting account.
The beta’s missing controls arrive
OpenAI introduced Sites to eligible ChatGPT Enterprise and Edu workspaces in June 2026. The preview let users ask Codex to create and revise lightweight JavaScript and TypeScript apps with hosted URLs, workspace-restricted access, Sign in with ChatGPT, databases, and file storage. A public beta followed in July. By Sept. 11, 2026, OpenAI’s official ChatGPT account reported that users had created more than five million Sites.
The general-availability release adds the residency, networking, and domain controls that companies commonly require before deploying internal applications.
Residency, domains, and tunnels arrive
| Capability | What it provides | Developer impact |
|---|---|---|
| US and EU residency | New Sites in eligible workspaces can be assigned to a supported data region. | Teams can align new deployments with organizational data-location requirements. |
| Workspace domains | Admins can publish Sites under a verified corporate domain, such as support.sites.yourdomain.com. |
Internal apps can use recognizable company URLs instead of default hosting addresses. |
| Private tunnels | Deployed Sites can call approved APIs and services behind a corporate firewall. | Internal services do not need a public endpoint solely to support a Site. |
| Connected-app plugins | Sites can load data through each visitor’s connected accounts and support scheduled updates. | One deployment can produce permission-aware views for different workspace members. |
| Managed app services | D1 stores relational data, R2 stores files, and Sign in with ChatGPT supplies identity. | Teams can build stateful, authenticated apps without provisioning separate services. |
Cloudflare Workers provides the application runtime. D1 is a SQLite-based relational database, while R2 is object storage for uploaded files and other unstructured data. OpenAI specifies residency support for new Sites, so existing beta deployments should not be assumed to inherit a regional setting.
Plugins preserve each viewer’s permissions
Connected-app plugins run in the visitor’s identity context. When teammates open the same Site, each person sees data available through their own connected accounts and existing permissions. Workspace members approve access to those accounts, with read-only access supported for uses such as issue dashboards and project trackers.
On page load, Sites retrieves and caches connected data. Connectors that paginate results with a cursor can expose a Load more action, where the cursor acts as a token for the next page of results. Supported write operations require explicit consent and a user-initiated action, reducing the risk of unintended changes caused by malicious or untrusted content.
Sites supplies the authenticated user’s identity to server-side code through two request headers:
oai-authenticated-user-email # authenticated email
oai-authenticated-user-full-name # optional display nameServer-side code should enforce authorization because browser-side checks can be inspected or modified by a visitor.
The runtime has hard edges
General availability retains several technical and policy constraints that affect architecture and deployment:
- Deployments are production by default. ChatGPT publishes each deployment unless the user explicitly asks it to save a version without deploying.
- D1 storage is capped at 10 GB per Site. Larger datasets require another approved service exposed through a supported interface.
- Network support covers HTTP, HTTPS, and WebSockets. Raw inbound and outbound TCP connections are unavailable, which excludes long-running TCP servers and many direct database drivers. Those systems need an HTTP-facing API or proxy.
- Protected data has explicit restrictions. Sites cannot process Protected Health Information or payment-card data, and financial transactions are prohibited.
Faster delivery creates a governance task
Data residency and private tunnels address two common barriers to deploying generated apps inside regulated companies. Teams can create dashboards, intake forms, request trackers, and other focused tools without first assembling a frontend project, identity provider, database, hosting account, and VPN rule.
Teams still own authorization rules, data design, testing, retention, and application lifecycle. OpenAI’s report of five million Sites during the beta also points to a practical management problem: Enterprise admins will need an inventory of deployed Sites, named owners, review processes, and retirement policies as creation accelerates.
Comments
