What is Codex Sites? OpenAI's hosted deploy, explained
A plain-English primer on Codex Sites: what it is, the save-versus-deploy flow, who can use it, and what runs under the hood.
Codex Sites is the Sites plugin for OpenAI Codex: it turns a prompt — or a compatible existing project — into a website, web app, or game that OpenAI hosts for you, without you wiring up a separate deployment pipeline. You describe what you want, Codex builds it, and you either save a reviewable version or deploy it to a live production URL. It runs Cloudflare Worker-compatible builds, can attach a database and file storage, and is free while in preview. This post explains what it is and how the pieces fit.
What Codex Sites actually is
Codex Sites is a plugin, not a separate product. You add it to Codex, then ask Codex — in plain language — to create, save, deploy, or inspect a site. The output is a real hosted site managed by OpenAI, so there is no git push, no build server to babysit, and no separate hosting account to configure.
Two things are worth pinning down early because they shape everything else:
- A Codex Sites project links your local source to hosting managed through Sites. Codex records that linkage, plus any storage binding names, in a small
.openai/hosting.jsonfile. A fresh starter can begin with noproject_id; Sites adds one once it provisions the project. - Every deployment URL is a production URL. There is no throwaway preview link that quietly expires. If you want to look at a build before it goes live, you ask Codex to save a version instead of deploying it.
That second point trips people up, so the save-versus-deploy distinction is the next thing to understand.
How it works: save vs deploy
Codex Sites splits "ship a site" into two deliberate stages. Saving builds a deployable candidate tied to your current Git commit; it does not put anything in front of users. Deploying publishes a saved version and reports the production URL. Saving is your review gate.
| Stage | What it does | Is it live? | When to use it |
|---|---|---|---|
| Save | Builds a deployable version, ties it to the source Git commit | No — reviewable candidate only | Pressure-test a build before anyone sees it |
| Deploy | Publishes an approved saved version | Yes — returns the production URL | The saved version passed review and you want it live |
In practice the loop is: describe the site, ask Codex to validate the build, save a version, review it, then deploy the version you approved. A typical deploy prompt for an existing project looks like this:
@Sites Deploy this project. Check whether it is compatible with Sites, make any required changes, and give me the deployment URL.
Naming the plugin with @Sites matters, especially when the task should end in a hosted deployment — it tells Codex this is a Sites job, not generic code generation.
Who can use it today
Codex Sites is in preview, and availability is still expanding. Per OpenAI's documentation it launched on ChatGPT Business and Enterprise workspaces, with more plans rolling out during the preview.
| Plan | Codex Sites during preview | What it means for you |
|---|---|---|
| Business | Available, on by default | Add the Sites plugin and start |
| Enterprise | Available once an admin enables it | Turned on via role-based access control in admin settings |
| Other plans | Rolling out during preview | OpenAI's feature-availability page lists the current set |
Two operational notes. On Business, Sites is on by default — members can start using it immediately. On Enterprise, an admin has to enable Sites through role-based access control in ChatGPT admin settings before anyone can use it. The Sites documentation also notes the feature started on Business and Enterprise "with more plans rolling out later," so treat the official feature-availability page as the live source of truth rather than this table.
Adding the plugin is the same everywhere: open Plugins in the Codex app (or run /plugins in the CLI), find Sites, add it, and start a new thread afterward.
What runs under the hood
Codex Sites does not host arbitrary anything. It hosts projects whose build produces Cloudflare Worker-compatible output as ES modules. The cleanest path for a new project is the recommended Sites starter; for an existing site, you ask Codex to confirm the build produces compatible artifacts before you deploy.
When a site needs to remember things, Sites can attach storage — and you should only request it when product data must persist, not for temporary UI state:
- D1 — a relational database for durable structured data.
- R2 — object storage for files.
- D1 + R2 — uploaded files plus searchable metadata.
The linkage and binding names live in .openai/hosting.json. Secrets do not. Environment variables and secrets are set in the Sites panel (Sites in the sidebar, then your project), never committed to the repo. A minimal hosting file with a database binding and no file storage looks like this:
{ "project_id": "<project-id>", "d1": "DB", "r2": null }
What people build with it
The pattern Codex Sites fits best is the internal tool — the small, real app a team needs but nobody wants to stand up infrastructure for. OpenAI's own showcase leans this way: an Onboarding Hub tracking progress, meetings, and tasks; an Enablement Hub with learning paths; a Pulse Dashboard surfacing trends and metric health; Sparkboard for proposals and voting; Launch Cal for planning and risk signals; and an Event Planning Hub for requests and templates.
A new-tool prompt from the docs gives the flavour of how much you specify in one go:
@Sites 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. Require people to sign in with their workspace account, and keep the request data saved between visits.
That single request implies sign-in, persistence, and a real data model — Codex provisions the pieces rather than making you wire them up.
What it isn't (yet)
Being honest about the edges matters more than the hype:
- It is in preview. Free today does not mean free forever, and behaviour may change.
- It is not a general host. If your build does not produce Worker-compatible ES modules, it is not a fit without changes.
- There is no casual preview URL. Because every deployment is production, the save step is the only built-in review gate — use it.
- Access is your job. Set the audience before sharing; keep new sites to owner and admins until reviewed.
Where it fits
Codex Sites earns its place once you already know what you want to build. The weak link is usually the brief, not the build — and that is the part Codex Sites does not help with. This is where a multi-model chat helps before you ever type @Sites: we use oran.chat to draft a site brief and pressure-test it across GPT, Claude, and Gemini, branching the prompt instead of overwriting it, so the spec we hand Codex is the one that survived three sets of objections. If you keep one instruction set in play across those models, see the system prompt that works across GPT, Claude, and Gemini.
For the next steps, our walkthrough of how to use Codex Sites covers the end-to-end flow, and save vs deploy in Codex Sites digs into the review gate. The official source is the Codex Sites documentation, and current preview terms live on the Codex pricing page. For more like this, see Playbooks.