OpenAI rolled out Sites on June 2, a Codex plugin that builds a web app from a prompt, hosts it, and hands back a shareable URL. It landed at the company's Intelligence at Work stream alongside six role-specific plugins and an annotations tool, but Sites is the one worth talking about. Ask Codex to build something, and it builds, validates, deploys, and returns a link, all inside one thread.
This is the part of the announcement aimed squarely at Lovable and Replit. Except OpenAI is not chasing landing pages.
What it actually makes
The pitch is internal tooling. Onboarding dashboards, knowledge bases, idea boards, reporting views, the small workflow apps that teams currently fake with spreadsheets and Notion pages. The Sites docs lean hard on this framing, with a sample prompt building a project request dashboard for an operations team, sign-in required, data persisted between visits.
Two storage options come bundled. D1 for structured data: checklist state, bookmarks, filters, configs, file metadata. R2 for the files themselves, documents, images, assets. The docs are blunt about not requesting durable storage for throwaway UI state like a dismissed banner, which is the kind of guidance that suggests they have already watched people misuse it.
About that storage
Here is the detail nobody at the stream dwelled on. D1 and R2 are Cloudflare products, a serverless SQL database and an egress-free object store respectively. OpenAI's own documentation confirms Sites hosts projects that build Cloudflare Worker-compatible output as ES modules, and the project config file literally lists d1 and r2 as binding names.
So "hosted by OpenAI" means OpenAI wrapped Cloudflare's edge platform under its own brand and its own auth. Not building the infrastructure, renting it and putting a login screen in front. Which is a perfectly reasonable thing to do, and also worth knowing before you assume your internal app lives on OpenAI metal.
Who gets to see it
Access starts locked down. By default only the owner and workspace admins can open a deployed site, which is the right default for something that might be holding company data. From there you widen it: workspace_all opens it to everyone in the workspace, or custom targets specific people and groups. Sign-in runs through ChatGPT.
One thing the docs are firm on: every deployment URL is a production deployment. Want to review before it goes live? You ask Codex to save a version without deploying it. Save and deploy are two separate stages, and conflating them is how someone publishes something they meant to sit on.
Sites is in preview, on by default for ChatGPT Business workspaces. Enterprise admins have to flip it on through role-based access controls first. No word yet on when it widens past those two tiers.
