by Ilia Sadykov“Describe a website, get a website” is now a solved consumer feature, and it was solved by the largest company in the field. ChatGPT Sites generates a site, hosts it, versions it, gives it analytics, and will point your own domain at it. It is good, and it is going to be used by an enormous number of people.
Read its documentation as a product builder rather than as an end user, though, and a different picture appears. Sites is created and managed conversationally, in the ChatGPT app or at chatgpt.com/sites; there is no documented management API. It runs on a paid plan — Plus, Pro, Business, Enterprise or Edu — so every one of your customers needs their own subscription. Connecting a custom domain means the domain’s owner copies DNS records out of Site settings and pastes them into their own DNS provider. Every deployment URL is a production deployment unless someone explicitly asks for a saved version first. And the terms rule out using it to enable financial transactions.
None of that is a flaw. It is a shape. It is the shape of a feature built for the person typing in the chat box.
If you are building a CRM, a marketplace, an onboarding flow or a booking tool, you are not that person. You need to give a site to your customer, from your interface, under your billing relationship, without teaching them what a CNAME is. That is a different product, and it is the one we shipped.
The half that decides whether it’s shippable
Most “AI-built website” demos end at a screenshot. The interesting part starts after it: a bucket has to exist, hosting has to be switched on, files have to land, a certificate has to be issued, DNS has to point somewhere — and someone has to own the failure when step three works and step four doesn’t. That plumbing is why the feature so often ends as a downloadable ZIP.
We shipped that half, and then exposed it.
The workflow has two characters. A designer turns the description into the actual site. A publisher does the unglamorous half: creates the storage bucket, turns on static-website hosting, uploads the files, puts a CDN with a certificate in front so the result is HTTPS rather than plain HTTP, and upserts the DNS record so the subdomain resolves.
Nobody pastes a DNS record. Not you, and not your customer — the publisher holds the credential and makes the call. Those cloud credentials are resolved server-side at the moment of the call; they never enter the model’s context, the transcript, or a commit, which is the same rule every other Forge workflow runs under.
The output is not a mockup. It is a URL you can open.
Regeneration that edits, instead of re-rolling the dice
The second iteration is what moved this from demo to usable. A change request reads the current revision’s file manifest and the designer’s context before regenerating, so “make the pricing section shorter” means editing the files it names — not generating a brand-new site and hoping it lands closer.
That is the difference between a site that converges over five requests and one that thrashes. It matters more when the person making the request is your customer rather than you, because they will not be forgiving about the third attempt.
The undo button, and who gets to press it
Every published revision is stamped and recorded, and a completion hook marks each run done or failed. Two endpoints follow from that: list the revisions of a site, and roll it back to a specific one. There is a delete path too.
Note what “endpoint” buys you: your product decides who may roll back and when. You can put rollback behind a support tool, or expose it to the end customer, or run it automatically when a health check fails. A rollback that only exists as a menu item in someone else’s app is a rollback you cannot build a support process around.
The industry is anxious about supervising agents — tool-call rewriting, syscall-level barriers , gated approval loops. Those matter. But a lot of the fear comes from work that cannot be taken back. Agents that ship into a versioned, reversible surface can be allowed to move quickly, because the worst case is one click of undo.
The actual product: you can embed it
The whole capability is reachable as an HTTP API. One POST starts a build, the run is polled for its result, and further endpoints list revisions, roll back, and delete. Tenancy rides on the calling token, so one caller’s sites are separated from another’s by construction rather than by convention.
Concretely: a product that already collects a description from its own users can hand those users a live site without operating object storage, a CDN, certificates, DNS or a build pipeline. You call an endpoint; your customer gets an address. They never learn that an agent was involved, never sign up for anything, and never see our name unless you want them to.
There is a per-end-customer step too: characters can be cloned per customer, so one of your users gets a designer tuned to their brand voice and another gets a different one, without you running two products.
The remaining toll booth is going too: account linking and a sign-in surface that does not require a GitHub account landed in the same fortnight and are rolling out via staging. Your customers were never going to open a GitHub account to get a landing page, and they will not have to.
What running it taught us
This is a young capability and we would rather describe it accurately than vaguely.
Shipped and smoked live: brief → generated site → bucket + hosting → upload → CDN with HTTPS → DNS → working URL, plus revisions, rollback and delete.
The live smokes caught four defects that unit tests could not have — a cloud API that demanded a different content type, a tool that existed on one execution path but not the other, three missing IAM grants, and an enum that had to be uppercase. A green build is not a working pipeline. It is why we smoke everything against the real thing, and it is the reason we are comfortable putting an endpoint in front of it.
Scope: the shipped adapter targets one cloud’s object storage, CDN and DNS. The workflow shape is not tied to it. Certificate propagation at a cloud’s edge can take hours on a fresh domain — that one is physics and paperwork, not code, and you should plan your onboarding copy around it.
Takeaway
Generating a page is the easy half, and the easy half now has the best-funded implementation in the world attached to it. Publishing it, versioning it, being able to take it back, and being able to do all of that on behalf of someone else’s customer is the half that decides whether it can become a feature of your product.
That is the part we sell. The use case is written up here , or start a workflow .