ChatGPT Sites lets you build, host, and share interactive websites, web apps, and games directly inside ChatGPT, with no separate deploy pipeline and no server to rent. You describe what you want in a prompt, ChatGPT builds it (running on Codex under the hood), and you get a live production URL you can share with your workspace or the public. As of July 2026 it is in public beta on every paid ChatGPT plan except Free and Go, and it's not the same thing as ChatGPT Projects or Canvas. This guide walks through exactly how to use ChatGPT Sites, what it can and can't build, and when you're better off building against an API instead.
What ChatGPT Sites actually is
Sites turns a prompt into a hosted, interactive surface (a dashboard, a project tracker, a landing page, an internal tool, or a small game) instead of a static document or a chat reply. The build and hosting both happen inside ChatGPT, so there's no exporting code, no picking a host, and no wiring up a deploy step.
Two distinctions matter up front. Sites is separate from ChatGPT Projects (which organizes chats and files) and from Canvas (a document/code editing surface inside a single chat). Sites is the only one of the three that produces a *hosted, shareable* app at its own URL. It's built on Codex, the same agent that powers OpenAI's coding workflows, and it's aimed as much at operators, analysts, and marketers as at developers.
*The details below are verified against OpenAI's official Sites documentation as of July 15, 2026. Because Sites is in public beta, plan and region availability can change.*
Who can use ChatGPT Sites right now
Sites is in public beta, and access has been rolling out plan by plan. The current rule from OpenAI's Help Center: Sites is available on paid plans except Free and Go. That covers Plus, Pro, Business, Enterprise, and Edu, with some plans (Plus and Business) enabled later in the rollout than Pro and Enterprise. Workspace admins can gate it, so on managed accounts you may need an admin to switch it on.
Two access constraints catch people out:
- Region. At launch, Sites is unavailable in the European Economic Area, Switzerland, and the UK, with no announced timeline for those regions.
- Platform. You open Sites in the ChatGPT desktop app or through ChatGPT Work on the web at
chatgpt.com/sites. It isn't managed through the Codex CLI or IDE extensions.
To start, either ask ChatGPT to build you a site in a normal chat, or type @Sites in your prompt to trigger a build explicitly. You can also start from a compatible existing local project rather than from scratch.
If you don't see Sites at all, the cause is almost always one of three things: you're on Free or Go (unsupported), you're in a restricted region (EEA, UK, or Switzerland), or a workspace admin hasn't enabled it for your account.
How to build a site, step by step
The build is a conversation, not a form. Four stages:
1. Write the opening prompt. The quality of the first build tracks the detail in your prompt. Specify the audience, the core workflow, what data it needs, whether users sign in, and who should be able to see it. A prompt that works:
> Build an internal project tracker for my marketing team. Team members sign in with our workspace account. Each project has a name, owner, status (Not started / In progress / Done), and a due date. Save the records so they persist. Show an overview table plus a simple board grouped by status. Access should be limited to our workspace only.
That single prompt names the audience (marketing team), the workflow (track projects), the data model (fields), persistence (save records), and access scope (workspace only), which is everything Sites needs to make sensible choices instead of guessing.
2. Review what it generated. ChatGPT shows you the built site and how it handles data. Check the layout, the fields, and any sign-in or storage behavior before you share it anywhere.
3. Refine. Ask for changes in plain language: "add a filter for overdue projects," "move the board above the table," "let owners edit their own rows only." You can attach screenshots or files to steer the design. Most non-trivial sites take a couple of refinement rounds to get right, especially around sign-in and permissions logic.
4. Get your link. When it's ready, deploy and share the URL. More on the publish step next.
Saving vs deploying: how publishing works
This is the part that trips up first-time users. Every deployment URL is a production URL. There's no separate staging environment, so Sites splits publishing into two actions:
- Save a version creates a reviewable build tied to a source commit, without pushing it live.
- Deploy a version publishes a saved build to its production URL.
The safe pattern: ask ChatGPT to *save* a version, review it, and only then *deploy*. If you skip straight to deploy, whatever you built is immediately live at a shareable address.
Sharing and access control
Once deployed, you control who can reach the site. The access modes are:
- Owner only: just you and workspace admins (a good default while a site is still under review).
- Selected users or groups: specific people you name.
- Workspace: everyone active in your workspace.
- Public: anyone with the link.
Sharing grants viewing, not editing: recipients see the site, they don't get into the builder. Admins can disable public sharing entirely, and in Enterprise workspaces publishing can be admin-gated. Any secrets your app needs (API keys, tokens) go in the site's Settings panel, not in your code or config files, so they aren't exposed in the shared build.
What you can and can't build
Knowing the walls up front saves a wasted build. Sites runs on OpenAI-managed hosting compatible with the Cloudflare Workers runtime, with two storage options: D1 (a SQLite-based relational database) for structured records, and R2 (object storage) for file uploads like images, documents, and video.
| Supported | Not supported | |
|---|---|---|
| App types | Content sites, dashboards, trackers, planners, landing pages, internal portals, small games | E-commerce / payment-card processing, health data apps, anything for under-13s |
| Backend | Managed serverless logic (Workers runtime), D1 database, R2 file storage, workspace or public sign-in | Node.js servers, Postgres or external databases, WebSocket servers, background jobs / long-running services |
| Data | Persistent records in D1, uploads in R2, environment variables via Settings | Data residency controls (not available at launch) |
The technical limits are the real gotcha: if your idea needs a persistent server process, an external Postgres instance, live WebSocket connections, or scheduled background work, Sites can't host it. It's built for interactive front-ends with lightweight, managed persistence, not full custom backends.
Custom domains work where available, with a catch: Sites doesn't register a domain for you. You bring your own, own it, and point DNS records at the site. Custom domains are also *not* available in Enterprise workspaces at launch.
What it costs
There's no separate Sites fee. It's included with your paid ChatGPT plan, and building or editing a site meters against your plan's usage allowance under the same structure as Codex, so heavy iteration draws down the same budget your other Codex work does. Usage is capped at plan-specific limits that OpenAI surfaces inside the product. As of July 2026 there is no public price list specific to Sites; the cost is effectively "part of your existing subscription, within its usage limits."
When to use an API instead of Sites
Sites is the fastest path from idea to a shared, working app *if* you stay inside its box. You outgrow it the moment you need something the runtime blocks (a real backend server, an external database like Postgres, persistent WebSocket connections, or background jobs), a specific model the app calls directly, usage-based pricing instead of metering against a chat plan, or deployment in a region Sites doesn't cover yet.
At that point you're building a normal application against a model API and hosting it yourself, which trades Sites' zero-setup convenience for full control over the stack. Model access through an API is billed per token rather than against a seat-based plan; gateways such as AIReiter route the major model families (including Anthropic-compatible Claude endpoints) at usage-based rates, which is the pricing shape a standalone app tends to want. It's a different tool for a different job: Sites for fast, self-contained internal apps; an API when you need a genuine backend.
| Use ChatGPT Sites when… | Build against an API when… |
|---|---|
| You want a shareable app in minutes | You need a custom or persistent backend |
| A dashboard, tracker, or internal tool is enough | You need Postgres, WebSockets, or background jobs |
| Your users are inside your workspace | You need a specific region or provider |
| Metered usage on your plan is fine | You want per-token, usage-based cost control |
Frequently asked questions
Is ChatGPT Sites free?
No. It requires a paid ChatGPT plan. It's available on every paid tier except Free and Go, and there's no separate charge on top of the subscription. Usage counts against your plan's limits.
Can I use a custom domain with ChatGPT Sites?
Yes, where the feature is available: you supply a domain you already own and point its DNS records at the site. Sites won't register a domain for you, and custom domains aren't offered in Enterprise workspaces at launch.
Is ChatGPT Sites available on the Plus plan?
It's rolling out to paid plans except Free and Go, which includes Plus, though Plus and Business came later in the rollout than Pro and Enterprise. Availability can still depend on your region and workspace settings.
What's the difference between ChatGPT Sites and ChatGPT Projects?
Projects organizes related chats, files, and instructions in one workspace. Sites produces a hosted, interactive website or app at its own shareable URL. They're separate features that solve different problems.
Can I build an online store with ChatGPT Sites?
No. Sites explicitly prohibits e-commerce and payment-card processing, along with health-data apps and anything aimed at children under 13. It's meant for interactive tools and content sites, not transactional commerce.