Sites is in public beta and is available with ChatGPT Plus, Pro, Business, Enterprise and Edu plans. Plan-specific usage limits apply across all Sites during the beta. ChatGPT shows the current limits and notifies you as you approach one. Reaching a limit can prevent you from creating a Site, adding storage, or keeping a high-usage Site public, but you can still edit and manage existing Sites.
Sites lets ChatGPT create, host, refine, and share websites, web apps, and games. Use Sites when you want to turn a prompt or compatible existing project into a hosted experience without setting up a separate deployment workflow.
Open Sites in the ChatGPT desktop app. You can start a site from a prompt or from a compatible local project, then return to the Sites view to manage it.
Use Sites in ChatGPT on the web to create and manage hosted sites. Select More > Sites, or go directly to Sites in ChatGPT, to find Sites you’ve created.
Sites doesn’t have a standalone Codex CLI management view. Use ChatGPT web or the desktop app to create, save, deploy, and manage a Sites project. You can still use Codex CLI to edit and test a local project before publishing it.
Sites doesn’t have a standalone IDE extension management view. Use ChatGPT web or the desktop app for Sites operations, and use the IDE extension to edit and test the local source project.
Every Sites deployment URL is a production deployment. If you want to review a build before it becomes live, ask ChatGPT to save a version without deploying it.
Get started with Sites
In ChatGPT, include the word “website” in your prompt or mention @Sites to
start the Sites workflow explicitly.
-
Describe the Site
Describe the audience, purpose, required behavior, and information the Site should use.
-
Review the Site
Review the generated content and behavior. Check that the Site uses the intended information and handles data as expected.
-
Refine the Site
Describe the changes you want. Add relevant files or visual context when they will help ChatGPT make the change.
-
Manage and share the Site
Return to Sites to reopen or refine the Site. When it’s ready, choose who can visit it and share the resulting link.
In the preview, select Edit. Under Describe website edits, describe the changes you want. Use Screenshot or Add files and more when additional context would help.
For help creating and managing Sites, see Creating and managing ChatGPT Sites in the Help Center.
Prompt Sites for common tasks
For a new website, dashboard, or internal tool, include the audience, core experience, and required information:
For an existing project, ask Sites to prepare and publish the current app:
When a site needs durable application data or uploaded files, say so in the request:
Browse the Sites showcase for deployed internal apps and the full prompts used to create them.
Review Site analytics
Sites records traffic automatically, so you can see how people use a deployed Site without adding an analytics SDK. The analytics view shows total unique visitors and page views, plus both metrics over time. Change the date range or granularity to inspect a different period.
Open Sites, find the Site, then select More actions > Analytics.
Go to Sites in ChatGPT, find the Site, then select More actions > Analytics.
Sites doesn’t have a standalone analytics view in the CLI or IDE extension. Open the Site in ChatGPT on the web or in the desktop app to review its analytics.
Analytics is currently available for Sites that aren’t owned by an Enterprise workspace.
Add Sign in with ChatGPT
Public Sites can remain open to everyone while offering optional Sign in with ChatGPT for identity-aware features, such as saved progress, personalized views, or records that belong to a specific person. Workspace-restricted Sites already use ChatGPT identity to enforce their sharing settings.
Ask Sites to add the sign-in experience:
How it works
Sites handles the sign-in and sign-out flows through platform-provided paths, then returns the visitor to your Site:
<a href="/signin-with-chatgpt">Sign in with ChatGPT</a>
<a href="/signout-with-chatgpt">Sign out</a>After a visitor signs in, Sites forwards their identity to the server through these request headers:
oai-authenticated-user-emailcontains the authenticated email address.oai-authenticated-user-full-namemay contain a non-empty profile name. Treat it as optional and fall back to the email address.
Keep authorization decisions in server-side code, and don’t depend on name-split headers.
Bring user data to your Site with plugins
Use plugins in Sites to build a Site that loads data from each Site viewer’s own connected apps. For example, an issue dashboard can show your assigned issues to you and your teammate’s assigned issues to them. Each visitor signs in with ChatGPT and chooses which connected accounts and access to allow.
Using plugins in Sites requires a workspace where the feature is enabled and a Site that is private to that workspace. Connected features require membership in the Site’s workspace and remain subject to each visitor’s existing app permissions. Admins can follow Enable plugin use in Sites to review individual plugin permissions and check tenant restrictions.
Build a Site with connected data
- Ask ChatGPT Work or Codex to build a Site. Name the plugin connector and what it should do, or ask which plugins are available.
- Try the preview with real data. The agent uses your available connections while building and previewing the Site.
- Ask the agent to publish the Site for your workspace and share its link with teammates.
For example:
You can also build a document finder that links to original documents or a project overview that combines tickets and messages.
Data loading
On page load, Sites reads connected data using the visitor’s connection and permissions. Sites manages caching and reloading; ask ChatGPT Work or Codex to add a manual refresh action if needed.
By default, Sites uses a Load more action to fetch another page when the connector returns a cursor.
Sites uses getContext() to find a plugin’s actions. It returns cached tool names, descriptions, and schemas; it doesn’t refresh discovery.
Write to an app
If your Site needs to write to an app, ask for write access. Write actions must be enabled and configured, and require visitor consent and an explicit user action.
Let visitors choose their connections
To use connected features, a visitor signs in with ChatGPT, reviews the app access the Site requests, chooses the connected account and access to allow, and returns to the Site. Sharing the Site doesn’t grant access to your connected accounts. The Site receives data from the apps each visitor allows.
Visitors can continue without granting app access, but features that need it won’t work. If an app is unavailable, check that it’s connected in the right workspace and allowed by workspace settings.
Understand projects, versions, and deployments
A Site is a persistent hosted output that you can reopen, refine, configure, and share from Sites in ChatGPT.
A Sites project links a local source project to hosting managed through Sites.
Sites stores that linkage and optional storage binding names in
.openai/hosting.json. A newly created local starter can begin without a
project_id; Sites adds one after it provisions the hosted project.
For example, a provisioned site that uses a relational database binding and no file storage can contain:
{
"project_id": "<project-id>",
"d1": "DB",
"r2": null
} A Site appears in your Sites list even after the ChatGPT Work chat that created it ends. You don’t need a local project or manifest to start a Site on the web. A Site is separate from a ChatGPT Project.
Sites publishing has two separate stages:
- Save a version. ChatGPT builds a deployable version. For a local source project, ChatGPT associates the version with the Git commit used for the build. Use this stage when you want a reviewable deployment candidate.
- Deploy a version. ChatGPT publishes a saved version and reports the production URL when deployment succeeds. Use this only when you intend for the selected audience to access the site.
Ask ChatGPT to list or inspect saved versions when you need to identify a previous deployment candidate.
Choose a supported site shape
For new projects, the Sites workflow can start with its recommended Site starter. For an existing project, ask ChatGPT to confirm that the project can produce compatible deployment artifacts before you request a deployment.
Tell ChatGPT about the product behavior you need so it can select the appropriate site shape:
| Site need | What to ask Sites for |
|---|---|
| Content-led website or landing page | A Site with no persistent application state unless the experience requires it |
| Saved records, user progress, or game scores | D1, a relational database for durable structured data |
| Images, documents, audio, video, or other uploads | R2, object storage for files |
| Uploaded files with searchable metadata | D1 for metadata and R2 for file contents |
| Internal site that needs the current workspace user’s identity | Workspace-authenticated user identity |
| Public sign-in or an external identity provider | An authentication-enabled Site |
Don’t request durable storage for temporary presentation state, such as a theme choice or a dismissed banner. Do request it for product data that people expect the hosted site to remember.
Control access and secrets
A new Site is limited to its owner and workspace admins until you change its access. Keep access limited while you review the content, data handling, and expected audience.
Depending on your account and workspace settings, sharing options can include:
- Owner and workspace admins
- Selected active users or groups, where supported
- Invited external viewers, when external invitations are available
- Anyone in the workspace, where supported
- Anyone on the internet, only when public publishing is enabled
Visitor access lets people open the Site; it doesn’t give them editing access. In Enterprise workspaces, public publishing is off by default and must be enabled by an admin.
For limited sharing, invited visitors must sign in with the account that received access. A public Site is available without ChatGPT workspace access. A Site’s audience setting and any sign-in feature built into the Site are separate controls.
For example:
Invite people outside your workspace
External invitations let you give named people access to a Site without making it public. You can invite viewers outside your workspace, or share a private Site from a personal account. The feature is rolling out to Sites users on Plus, Pro, Business, and Enterprise plans.
- Open a Site you own and select Share.
- To keep the Site private, set Who has access to Only those invited.
- Enter the viewer’s email address under Search for people or groups, or Enter an email address for a personal Site, then select the recipient.
- Review the audience and the recipient’s Viewer access, then select Invite.
- Confirm that the viewer appears in the saved access list. Share the Site’s link and ask them to sign in with the account that received access.
External viewers can open and use the Site. They don’t become workspace members or Site editors, and can’t edit or publish the Site. The invitation grants access to this Site; review its content and connected data before sharing.
In Enterprise, admins manage Allow members to invite external visitors to sites under Workspace settings > Permissions & roles. This permission is separate from permission to publish Sites publicly. Business workspaces don’t have a separate external-invitation permission toggle; Sites must be enabled, and the feature must be available to the account. If the invitation option is missing, check the selected account, Site ownership, workspace permissions, and rollout availability.
To remove a viewer, open the Site’s sharing controls and remove their access. Also check the remaining audience settings: removing one invitation doesn’t remove access the person has through public, workspace, or group sharing.
Collaborate on a Site
Site collaboration requires a workspace. When the feature is available, a Site owner can invite active members of the same workspace as editors.
Editors can read the Site’s live database data. Invite only people you trust with the Site’s code and data.
- Open the Site and select Share.
- Under Add people or groups, find and select a workspace member. They are added as a visitor.
- Open Can view next to that person and choose Can edit. Access saves automatically. The Site appears under Shared with you in the member’s Sites view.
- The editor can open the Site, make changes, save versions, and publish updates after the owner has published the Site for the first time.
The Site owner manages editor access and can promote an existing visitor to editor, change an editor to Can view, or remove their access. Co-editing doesn’t add a separate workspace permission toggle.
Editors can’t change the Site’s audience, invite or remove other people, manage settings or analytics, restore an earlier version, or transfer ownership. An editor also can’t perform the Site’s first publish; the owner must publish the Site before editors can publish later updates.
Editor access is separate from visitor access. The steps above first add the person as a visitor, then grant editing access. Promoting a visitor to editor doesn’t change the Site’s audience setting.
Configure runtime environment values
Open Sites, then open the Site’s settings to add, update, or remove hosted environment variables and secrets. Keep secret values out of prompts, attached files, and Site content.
Go to Sites in ChatGPT, find the Site, then select More actions > Settings.
Don’t store these values in .openai/hosting.json. Keep local .env and
.env.example files aligned with the keys needed for local development, and
don’t commit secret values.
When you add, update, or remove hosted environment values, ask ChatGPT to redeploy the approved saved version so the next deployment uses the updated configuration.
Change a Site URL
Where URL editing is available, Site owners can change the ChatGPT-hosted URL for an existing Site without creating another deployment.
- Open Sites, find the Site, and open its settings.
- Find the Site URL and select Change URL.
- Enter an available name. It must contain at least five characters, start with a lowercase letter, and use only lowercase letters, numbers, and single hyphens. It can’t end with a hyphen or contain consecutive hyphens.
- Confirm the change and wait while Sites updates the address.
The URL change doesn’t create another deployment. The previous address redirects to the new one, including routes and query parameters.
Changing the ChatGPT-hosted URL doesn’t add, remove, or change a custom domain. Custom domains are a separate, existing feature; use the custom-domain settings when that feature is available.
Connect a custom domain
Where custom domains are available, you can connect an apex domain or subdomain that you already own. Sites doesn’t register domains for you, so you must be able to change the domain’s DNS records. Custom domains aren’t available in Enterprise workspaces at launch.
To connect a domain:
- Open the Site’s settings and select Add domain.
- Enter the apex domain or subdomain you want to use.
- Copy the DNS records and values Sites provides, then add them through your domain provider.
- Wait a few minutes, then return to the Site’s settings and refresh the domain status.
You can also ask ChatGPT to help point the domain at your Site. If browsing or computer use is enabled, ChatGPT can help you navigate your domain provider after you sign in.
Review before you share
Before you share a Site:
- Review its content, generated text and images, links, uploaded files, forms, and interactive behavior.
- Confirm that it doesn’t expose confidential or sensitive information, secret values, or third-party content you don’t have the right to share.
- Test the Site from the intended visitor experience, including its access and sign-in behavior.
- Review features that collect personal information or other visitor content. Decide whether the Site should collect, share, or publish that information.
- If the Site uses Sign in with ChatGPT, explain what visitor information it receives and how it uses that information.
- If the Site collects or processes personal data, comply with applicable privacy and data-protection laws.
- Choose the narrowest sharing option that fits the intended audience.
- Open the shared Site and confirm that the intended audience can visit it.
For a Site built from a local project, also review the source changes and any database migrations in the Codex review pane.
Take down or delete a Site
To remove access without deleting a Site, open its sharing settings and restrict access to yourself or selected people. Confirm that the previous audience can no longer open it.
To permanently delete a Site:
- Open Sites and locate the Site.
- Select Delete site and follow the instructions in the prompt.
- Enter the Site slug, then select Permanently delete.
Deleting a Site permanently removes it. You can’t restore a deleted Site.
Understand limits and unsupported uses
Sites hosts web experiences that run in the supported Sites runtime. Some frameworks, private networks, databases, background services, and hosting patterns aren’t supported.
HTTP, HTTPS, and WebSockets are supported. Raw inbound and outbound TCP connections aren’t.
Each Site has these storage limits:
| Resource | Limit |
|---|---|
| D1 database storage | 10 GB |
| R2 object storage | No fixed storage limit |
Sites doesn’t support data residency or inference residency at launch. This includes deployed Sites, Site code, D1 and R2 data and file storage, generated artifacts, and logs.
Don’t use Sites to process Protected Health Information or payment-card data; target children under 13 or the applicable age of digital consent; enable financial transactions; distribute malware; enable phishing; impersonate people or organizations; or otherwise violate OpenAI policies. See Creating and managing ChatGPT Sites for the current limits and policy links.
Related documentation
- ChatGPT desktop app introduces app navigation, projects, and chats.
- Review and ship changes explains how to inspect source changes before publishing them.
- Projects and chats explains how folder and workspace context carries across chats.
- Review and ship changes explains the review workflow for each Codex client.
- Sandboxing explains the local execution boundary.
- Open Sites in ChatGPT to return to Sites you’ve created.
- Projects and chats explains how to keep related chats and source files together.
- Work with files explains how to review generated files in ChatGPT web.