On October 3, 2026, Hacker News put Sites in ChatGPT near the top of the front page — roughly 209 points and 218 comments by the time the thread settled. The link was not a surprise launch post. ChatGPT Sites has been in public beta for months. What HN did was force the practitioner questions that product pages skip: is this a toy, a prototype host, or something you would put a real audience on?
explainx.ai already covered the MCP hosting path, workspace co-editing, and the music-album vibe-coded Site. This post is the HN-thread read — what builders argued, what OpenAI's Sites docs actually say, and where the gap between showcase demos and a durable app still sits.
TL;DR — questions the thread actually asked
| Question | Short answer |
|---|---|
| What is Sites? | Prompt → refine → publish a hosted website, web app, or game inside ChatGPT |
| Who gets it? | Public beta on Plus, Pro, Business, Enterprise, Edu (plan limits apply) |
| Prototype or production? | Deploy URLs are production; fit is light apps and shareable prototypes, not PHI/card/residency workloads |
| Custom domain? | Yes where available — you own DNS; not on Enterprise at launch |
| Export? | Custom domain ≠ export; some users download and self-host separately |
| Auth? | Optional Sign in with ChatGPT on public Sites; headers carry email / optional name |
| Storage? | D1 up to 10 GB; R2 with no fixed storage limit |
| Connected tools? | Workspace-private Sites can load visitor plugins / connected apps |
| Lock-in? | Default *.chatgpt.site; mitigate with custom domain or a real export path |
| Docs | learn.chatgpt.com/docs/sites · Help Center |
What ChatGPT Sites is (product facts, not marketing)
OpenAI's developer guide states the job clearly: Sites lets ChatGPT create, host, refine, and share websites, web apps, and games when you want a hosted experience without a separate deployment workflow. You start from a prompt (mention website or @Sites) or from a compatible local project, review a preview, iterate, then set audience and share the link.
Surfaces that matter:
- ChatGPT web — More → Sites, or chatgpt.com/sites
- Desktop app — Work or Codex
- Not a standalone Codex CLI or IDE "Sites manager" — those edit local source; publish still goes through ChatGPT web or desktop
Publishing has two stages the docs insist on:
- Save a version — build a deployable candidate (for local projects, tied to the Git commit used for the build)
- Deploy a version — publish that saved version
Every Sites deployment URL is a production deployment. If you want review first, save without deploying. That single sentence answers half the HN confusion: the product does not give you a separate staging hostname; discipline is in the save step.
For the original product framing and Business/Enterprise role plugins context, see explainx.ai's Codex Sites launch coverage. For how Work and Codex split day-to-day, see ChatGPT Work vs Codex.
Sign in, storage, connected tools, custom domains
These are the four capabilities HN kept circling. All four are documented.
Sign in with ChatGPT
Public Sites can stay open to signed-out visitors while offering optional Sign in with ChatGPT for saved progress, personalized views, or per-user records. Workspace-restricted Sites already use ChatGPT identity for access control.
After sign-in, Sites forwards identity to your server via headers:
oai-authenticated-user-emailoai-authenticated-user-full-name(optional; fall back to email)
OpenAI's guidance is blunt: keep authorization decisions in server-side code. If you collect personal data, you are responsible for privacy law compliance — the platform does not absorb that for you.
Storage (D1 and R2)
Ask for durable data when the product needs it. Docs map needs to bindings:
| Need | Binding |
|---|---|
| Saved records, scores, progress | D1 (relational) |
| Uploads (images, audio, documents) | R2 (object storage) |
| Uploads plus searchable metadata | D1 + R2 |
Documented limits per Site: D1 up to 10 GB; R2 with no fixed storage limit. Temporary UI state (theme, dismissed banner) should not burn durable storage. Local projects store linkage in .openai/hosting.json (for example project_id, d1, r2).
Connected tools / plugins
Where the workspace enables it, a workspace-private Site can load data from each visitor's own connected apps — issue trackers, docs, and similar connectors — after the visitor signs in and consents. Sharing the Site does not share your connections; each visitor brings theirs. Write actions need explicit consent and an enabled write path. This is the same family of surface as the Sites-hosted MCP / plugin story from October 1 — different job (data in vs tools out), same hosting layer.
Custom domains
Where available, Site settings → Add domain, enter an apex or subdomain you already own, copy DNS records Sites provides, wait, refresh status. Sites does not register domains for you. Custom domains are not available in Enterprise workspaces at launch. Changing the ChatGPT-hosted slug (*.chatgpt.site) is a separate control from attaching a custom domain; old hosted URLs redirect when you rename.
Also worth knowing for team and compliance readers: Sites does not support data residency or inference residency at launch — that includes Site code, D1/R2 data, artifacts, and logs. Do not use Sites for PHI, payment-card data, or under-13 audiences; OpenAI's policy list in the Help Center is the authoritative ban sheet.
What Hacker News actually argued
The thread was calmer than a typical model-launch pile-on, but the themes were sharp.
1. Hour-scale prototypes are the sweet spot
Top comments described Sites as underrated for quick app ideas that become playable the same day — a higher-dimensional maze game spun up after a concert, an offline-friendly festival schedule after a bad official site, a campus food guide for an event. That matches how vibe coding has played out all year: the win is not "replace the agency," it is "the friction to a shareable URL dropped below the friction of not building."
2. Prototype vs production is the real fork
Several commenters treated Sites as "not production-capable" while others shipped real (if small) tools. The docs settle the URL semantics: deployed means live. The fit question is different. Unsupported frameworks, no raw TCP, beta usage limits that can stop new Sites or public high-usage Sites, and the residency gap all say: use Sites when the blast radius of downtime or data locality is acceptable. Use a stack you operate when it is not.
A useful mental model:
| Use Sites when… | Do not use Sites when… |
|---|---|
| You need a shareable URL today | You need residency / regulated data |
| Teammates iterate in ChatGPT / Codex | You need unsupported runtimes or raw TCP |
| D1/R2 + Sign in covers the app | You process payments or PHI |
| Audience is invited, workspace, or low-stakes public | You cannot accept .chatgpt.site or OpenAI hosting risk |
3. Export vs custom domain — two different exits
A commenter looked at *.chatgpt.site and asked: will these be dead soon, and can I export to my own domain? Two answers appeared in the thread, and both are true in different ways:
- Custom domain (documented): map DNS to the hosted Site. You keep OpenAI's runtime; visitors stop seeing the
chatgpt.sitesuffix. - Export / self-host (user-reported): some builders download the project and hand it to another agent or host. That is not the same as the custom-domain setting, and OpenAI's public Sites guide does not frame "one-click portable export" as a first-class product promise.
If durability matters, plan the exit before you accumulate users: custom domain for branding on the hosted runtime, or treat Sites as a mockup stage and move code when the app graduates. Do not assume DNS pointing equals source portability.
4. Showcase demos and the "slop" detector
HN roasted parts of OpenAI's own showcase. Tidal House (tidal-house-retreat.openai.chatgpt.site, also listed on the OpenAI showcase) drew fire for unreadable text on an image. Below the Surface (below-the-surface-ocean.openai.chatgpt.site, showcase entry) was called detectable as AI slop "on first contact." Other showcase pieces (Frame Studio Motion came up) split the room — some could not spot the tell, others said the typography aura was immediate.
The useful takeaway is not "Sites can only make slop." It is that hosted polish is not automatic. Showcase prompts from OpenAI staff still need a human pass for contrast, copy, and type. The music-album Site explainx.ai covered earlier is the same lesson in reverse: a specific real need plus iteration beats a cinematic landing page prompt that nobody edits.
5. ChatGPT Sites vs Claude Artifacts (prose only)
HN kept asking whether Sites is "better than Claude" or just Artifacts with a URL. Keep the comparison at the product shape:
- Sites — persistent hosted output in a Sites list, save/deploy, analytics (non-Enterprise), D1/R2, Sign in with ChatGPT, workspace editors, plugins for connected data, custom domains where available, default
*.chatgpt.sitehosts. - Artifacts — interactive canvases that live closer to the chat turn; great for explaining or iterating inside a conversation, weaker when the job is "give me a durable shared app with storage and audience controls."
If the deliverable is a link coworkers open tomorrow without the original chat, Sites is the closer match. If the deliverable is a temporary interactive explanation inside a thread, Artifacts still win on friction. Neither replaces a full production frontend when you need CI, multi-region, or compliance controls you own.
6. Lock-in, .chatgpt.site, and "will they abandon it?"
The aesthetic complaint ("early-2000s free host vibes") and the strategic complaint ("OpenAI will abandon this") showed up together. One commenter predicted Sites would be dropped as focus moved elsewhere; a reply in-thread pushed back that Sites is unlikely to be abandoned soon. Treat both as opinions, not commitments.
What you can verify today:
- Sites is explicitly a public beta with plan-specific limits that can block new Sites or public high-usage Sites
- Default hostnames sit under
chatgpt.site - Custom domains exist for non-Enterprise (at launch) accounts that already own DNS
- Residency is not supported
- Co-editing, URL rename, analytics, and plugins keep expanding the surface — which is the opposite of a mothballed experiment, but still not a forever contract
For anything you care about in six months, prefer a custom domain or a deliberate export path. For throwaway prototypes, .chatgpt.site is fine — that is most of what the front-page thread celebrated.
How this fits the explainx.ai Sites series
Read this post as the decision layer on top of prior coverage:
| Post | Job |
|---|---|
| Codex Sites launch (June 2026) | What Sites was at launch |
| Collaborative editing (Aug 2026) | Workspace editors, Git-tied versions, URL rules |
| Music album Site (Aug 2026) | Solo "just build the player" use case |
| Host MCP on Sites (Oct 1) | Backend / plugin hosting path |
| This post (Oct 3) | HN practitioner questions + doc-backed limits |
If you are already treating Codex as a platform harness — local repo, review pane, save then deploy — Sites is the publish button for that loop, not a different product category. DevDay context for the wider ChatGPT/Codex surface lives in our OpenAI DevDay 2026 recap.
Practical prompts builders actually need
Copy patterns that match the docs' own examples, then tighten for your case:
Internal tool with identity
Build a project request dashboard for my ops team. Let people submit
requests, assign owners, update status, and filter the list. Require
workspace sign-in and keep request data between visits. Use @Sites.
Public Site with optional ChatGPT sign-in
Add Sign in with ChatGPT to this public Site. Keep it usable signed out.
Show Sign in / Sign out actions. After sign-in, greet with full name or
email. Keep authorization decisions in server-side code.
Storage
Add player scores and avatar uploads. Persist scores in D1 and avatars
in R2 between visits.
Deploy discipline
Save a version of this Site without deploying. Show me the saved version
details, then wait for my approval before deploy.
Custom domain
Walk me through connecting my existing domain example.com to this Site.
List the DNS records I need to add, then refresh domain status after I
confirm they are live.
Honest limitations (so you do not learn them in prod)
- Beta limits — hitting a plan limit can block new Sites, added storage, or keeping a high-usage Site public; editing existing Sites may still work
- Runtime shape — HTTP/HTTPS/WebSockets yes; raw TCP no; many frameworks and background patterns unsupported
- Enterprise gaps — public publishing off by default; custom domains unavailable at launch; analytics currently called out as unavailable for Enterprise-owned Sites
- No residency — do not put regulated workloads here hoping for a quiet compliance story
- Showcase quality — OpenAI's own demos got roasted for contrast and copy; your Site needs the same human pass
- Default hostname optics —
*.chatgpt.sitesignals "AI-hosted" to a chunk of the internet; custom domain or export if that matters
None of that makes Sites useless. It makes the HN consensus roughly correct: excellent for shareable prototypes and light apps; a bad silent swap for a production stack you already trust.
Related reading
- Host an MCP server on ChatGPT Sites
- ChatGPT Sites collaborative editing with Codex
- Vibe-coded music album app on ChatGPT Sites
- OpenAI Codex Sites launch: roles and plugins
- What is vibe coding?
- ChatGPT Work vs Codex
- Codex as a platform harness
- OpenAI DevDay 2026
- Official: Sites developer guide · Creating and managing ChatGPT Sites · HN thread
Details on ChatGPT Sites, Hacker News scores, and OpenAI documentation are accurate as of October 3, 2026. Sites remains in public beta — limits, Enterprise availability, and hostname behavior can change.