Back to All Cheatsheet Libraries cheatsheets

OpenAI ChatGPT Sites

Build, host and share websites, web apps and games from inside ChatGPT — with a real database, file storage and Sign in with ChatGPT. Plus the limits worth knowing before you commit.

Describe a website, get a hosted one

ChatGPT Sites lets you create, host, refine and share websites, web apps and games from inside ChatGPT. There is no build step, no deploy pipeline and no server to provision — every site gets a production URL and OpenAI runs the hosting.

The part that makes it more than a page generator: sites can have a real relational database, file storage, and authenticated users. That moves it from "landing page" into internal-tool territory.

Aspect	Detail
Plans	ChatGPT Plus, Pro, Business, Enterprise and Edu. Not on the free tier.
Status	Beta — plan-specific usage limits apply across all your sites.
Where you manage it	More → Sites on ChatGPT web or the desktop app.
How you start one	Include the word "website" in your prompt, or mention `@Sites`.
Production URL	Something like `goblin-tales.openai.chatgpt.site`, assigned automatically.
Database	D1, relational, up to 10 GB.
File storage	R2 object storage, no fixed limit.
Public API	None. Every operation goes through the ChatGPT interface.

What people actually build with it

Content sites and landing pages — the obvious case, and the least interesting one.
Internal tools behind workspace auth — request trackers, dashboards, forms. This is where it earns its keep, because the alternative is a spreadsheet nobody maintains.
Apps with persistent state — scores, progress, saved records, anything needing a database.
Games — genuinely supported, not an afterthought.
Public sites with optional Sign in with ChatGPT, so visitors can authenticate without you building an identity system.

Prompting it well

Describe four things: the audience, the purpose, the behaviour, and the information it needs. Missing any one produces something generic.
A good example from the docs: "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."
Notice that names the users, the actions, the data and the interactions — that is why it works.
Start from the recommended Site starter unless you have an existing compatible project.

Save a version

Creates a reviewable deployment candidate, associated with the underlying Git commit. Nothing is live yet.

Deploy that version

Publishes the saved version to production. Only now does the live URL change.

Note there is no staging tier: every Sites deployment URL is a production deployment. The save/deploy split is your review gate.

Set the audience

Owner/admin only · selected workspace users or groups · the whole workspace · or public, if your workspace permits it.

Visitor access is not edit access — letting someone open the site does not let them change it.

Editing

Go to More → Sites, hit Edit on the preview, and describe what you want under Describe website edits.
You can attach screenshots or files as context — useful for "make it look like this" rather than describing a design in prose.
Local editing works too: use Codex CLI or the IDE extensions on the project before publishing. That is the escape hatch when prompting stops being precise enough.

Collaboration

Workspace members can be invited as editors.
Editors can read the site's live database data — worth knowing before you invite someone to a site holding real records.
Editors cannot change audience settings, manage analytics, or publish the initial version. Those stay with the owner.

Analytics

Traffic is recorded automatically — unique visitors and page views, plus both over time.
Find it under More actions → Analytics in the Sites management view.
Unavailable for Enterprise workspace-owned sites.

.openai/hosting.json ├── project ID └── optional storage bindings ├── D1 — relational database, 10 GB max └── R2 — object storage, no fixed limit # NEVER put secrets in this file, or in anything committed. # Hosted environment variables and secrets are configured in # Site settings on ChatGPT web.

Sites provides platform-managed sign-in paths — you do not build an auth flow:
/signin-with-chatgpt and /signout-with-chatgpt
Visitor identity is forwarded to your app as request headers:
oai-authenticated-user-email
oai-authenticated-user-full-name
That is the whole integration. Read the header, you have the user — which is why an internal tool is genuinely quick to stand up here.

URLs and custom domains

Every site gets a ChatGPT-hosted URL such as goblin-tales.openai.chatgpt.site.
You can change the hosted URL of an existing site without creating a new deployment. The new slug must be at least five characters, start lowercase, and use only lowercase letters, numbers and hyphens.
Custom domains — connect an apex domain or subdomain by updating DNS, where available.
Custom domains are not available in Enterprise workspaces at launch. That is the single most likely blocker for a corporate rollout.

What you must not build

No Protected Health Information. Sites is not a HIPAA-appropriate surface — this rules out a large slice of healthcare internal tooling.
No payment data.
Nothing targeting children under 13.
No malware, phishing, impersonation, or other policy violations — the usual, and enforced.

Technical limits

Data residency and inference residency are unsupported. If your organisation has a residency requirement, that is a hard stop regardless of plan.
No private networks. A Site cannot reach into your VPC or an internal-only API.
No background services. No cron, no workers, no long-running jobs — request/response only.
Certain frameworks are unsupported. Start from the Site starter unless you know your stack is compatible.
D1 caps at 10 GB. R2 has no fixed limit.
Beta usage limits are plan-specific and apply across all your sites collectively. Hitting them can block new site creation or maintaining a high-traffic public site — though existing sites stay editable.

Things that will catch you

Saving is not publishing. Save creates a candidate; deploy makes it live. Two steps, always.
There is no staging environment — every deployment URL is production. Use the save/deploy gap as your review step.
Editors can read your live database. Invite accordingly.
Enterprise loses two things at launch: custom domains and analytics.
There is no API and no CLI for managing Sites. Codex can edit the local project, but creation, publishing, audience and settings are ChatGPT-interface-only — so this cannot be driven from CI.
Secrets belong in Site settings, never in .openai/hosting.json or any committed file.

Tips

Name the users, actions and data

The prompts that produce useful tools specify who uses it, what they do, and what it stores. "Build a dashboard" gets you a mockup; the four-part version gets you something people can actually use.

Drop to Codex when prompting stalls

Editing the local project with Codex CLI or the IDE extension is far more precise than describing a change in prose — especially for layout and CSS.

Attach a screenshot

The edit box accepts screenshots and files. Showing a reference beats describing a design, and it is the fastest way to fix "not quite right" visuals.

Auth is two headers

oai-authenticated-user-email and oai-authenticated-user-full-name. No OAuth dance, no session store — read the header and you have your user.

Fix the slug early

You can rename the hosted URL later without redeploying, but do it before sharing the link — five characters minimum, lowercase, letters, numbers and hyphens only.

Check residency before you invest

No data residency, no private networks, no PHI. Confirm those against your organisation's requirements before building the internal tool, not after.

When to use something else

Honest positioning

Good fit: internal tools for a ChatGPT workspace, quick prototypes, small apps needing a database and login without infrastructure, one-off sites you want hosted and forgotten.
Poor fit: anything needing background jobs, private-network access, data residency, PHI or payments, or CI-driven deployment.
Consider Lovable if you want the generated code in your own Git repo and full control of hosting — Sites keeps you inside the ChatGPT platform.
Consider a normal stack once the thing outgrows request/response and needs workers, queues or scheduled tasks. There is no upgrade path from Sites to that.

Resources

ChatGPT Sites documentation The official guide — building, publishing, storage, auth and limits. learn.chatgpt.com OpenAI developer docs API, Codex, Plugins, Workspace Agents and Commerce. learn.chatgpt.com OpenAI Codex How to edit a Site's local project precisely, when prompting is not enough. www.ty1er.com OpenAI ChatGPT The product Sites lives inside, and where your plan determines access. www.ty1er.com Lovable The closest alternative — generated apps you own in your own repo. www.ty1er.com