Sites is in public beta. Availability can depend on your plan, region, and workspace settings.
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 Work on the web to create and manage hosted sites. Select More > Sites, or go directly to chatgpt.com/sites, 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
-
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.
Prompt Sites for common tasks
For a new website, dashboard, or internal tool, include the audience, core experience, and required information:
Build a project request dashboard for my operations team. Let team members
submit requests, see who owns each one, update the status, and filter the list.
Require people to sign in with their workspace account, and keep the request
data saved between visits.
For an existing project, ask Sites to prepare and publish the current app:
Deploy this project with Sites. Check whether it is compatible, make any
required changes, and give me the deployment URL. When a site needs durable application data or uploaded files, say so in the request:
Add player scores and avatar uploads to this game. Keep the scores and uploaded
avatars between visits.
Browse the Sites showcase for deployed internal apps and the full prompts used to create them.
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 Work task 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
Hosting a Site doesn’t automatically make it public. Keep access limited while you review the content, data handling, and expected audience.
Depending on your account and workspace settings, sharing options can include:
- Only you or people you invite.
- Everyone in your workspace.
- Anyone with the link.
Sharing lets people visit the Site; it doesn’t let them edit it. Workspace admins can restrict whether members can share Sites publicly.
For example:
Change this Site's access to everyone in my workspace after showing me the
current Site and confirming its URL.
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 chatgpt.com/sites, 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.
Review before you share
Before you share a Site:
- Review the Site’s content and behavior in the preview.
- Check that the Site handles information and uploaded files as expected.
- Confirm that the Site doesn’t expose confidential information or secret values.
- 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.
Related documentation
- ChatGPT desktop app introduces app navigation, projects, and tasks.
- Review and ship changes explains how to inspect source changes before publishing them.
- Projects, chats, and tasks explains how folder and workspace context carries across tasks.
- 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, chats, and tasks explains how to keep related chats, tasks, and source files together.
- Work with files explains how to review generated files in ChatGPT web.