Codex Sites vs Vercel & Netlify: when to use which
An honest head-to-head: Codex Sites is prompt-to-host inside ChatGPT, while Vercel and Netlify are git-to-host production platforms.
If you are choosing where a new site or app should live in 2026, the honest split is this: Codex Sites is prompt-to-host and lives inside ChatGPT and Codex, turning a description into an OpenAI-hosted deployment with a Cloudflare Worker-compatible runtime; Vercel and Netlify are git-to-host, where you push a repository, CI builds it, you get automatic preview URLs, and you promote a build to production on your own custom domain. Pick Codex Sites when you want an internal app or prototype the moment the prompt is good; pick Vercel or Netlify when you need a production-grade public site, branch previews, and a mature ecosystem. The sharpest difference is the review model, and it is inverted between the two camps.
Two different bets: prompt-to-host vs git-to-host
Vercel and Netlify made the same bet years ago: your source of truth is a Git repository, and every push should build. The killer feature both pioneered is the preview deployment — open a pull request and you get a throwaway URL that is not production, so you can click around before anything ships. Production is a separate, deliberate promotion.
Codex Sites makes a different bet. You describe what you want to Codex, name @Sites, and it builds and can deploy a hosted site without you wiring up a separate deployment workflow. The twist that trips people up: every Sites deployment URL is a production deployment. There is no automatic "preview URL" in the Vercel sense. Instead, the review step is to ask Codex to save a version without deploying it. A saved version builds, ties to your source Git commit, and is reviewable — but it is not live until you deploy it.
So the inversion is real. With Vercel and Netlify you get a preview first and promote to production. With Codex Sites you save first and the only published state is production. Same goal — don't ship something broken — opposite default.
The comparison, row by row
We have kept this fair. Where Codex Sites genuinely doesn't document a capability that the others have, we say so rather than scoring it a zero.
| Codex Sites | Vercel | Netlify | |
|---|---|---|---|
| How you ship | Prompt Codex, name @Sites, deploy | git push a repo, CI builds | git push a repo, CI builds |
| Review / preview model | Save a version without deploying | Automatic per-branch / per-PR preview URLs | Automatic deploy previews per branch / PR |
| Production model | Every deploy URL is production | Separate promote-to-production step | Separate promote-to-production step |
| Runtime / hosting | OpenAI-hosted; Cloudflare Worker-compatible ES modules | Serverless + edge functions, many frameworks | Serverless + edge functions, many frameworks |
| Data & storage | D1 (relational), R2 (objects), or both | External DB or partner add-ons | External DB or partner add-ons |
| Access control | Owner+admins, workspace, or custom; RBAC on Enterprise | Public by default; team/SSO controls | Public by default; team/SSO controls |
| Custom domains | Not documented in preview | Yes, documented | Yes, documented |
| Pricing | Free while in preview; pricing TBA | Free tier + paid plans | Free tier + paid plans |
| Best for | Internal/workspace apps, prototypes from a prompt | Production apps, Next.js, public sites | Production sites, JAMstack, public sites |
A few rows deserve a note. On access control, Codex Sites starts new sites restricted to owner and admins, and you set the audience (admins only, the whole workspace, or a custom set) before sharing; on Enterprise an admin must first enable Sites via RBAC, while Business has it on by default. That is a workspace-first posture. Vercel and Netlify default to public and layer team and SSO controls on top — a public-web posture.
On custom domains, branch URLs, edge regions, and analytics, the Codex Sites docs simply don't cover them in preview, so we list them as "not documented" rather than asserting the feature is missing. You can confirm the current state on the official Codex Sites documentation.
When Codex Sites is the right call
Reach for Codex Sites when the work starts as a prompt and should end as something running, fast:
- Internal tools and workspace apps. A dashboard for your team, an admin panel, a small data app behind workspace auth. The owner+admins default and RBAC make it a natural fit for things that never need to be on the open web.
- Prototypes you'll build by describing them. When you'd rather say "build me a small site that does X" than scaffold a repo and a CI pipeline, prompt-to-host removes the setup tax entirely.
- You're already living in Codex. If your team uses Codex day to day, adding the Sites plugin and shipping from the same thread is less context-switching than wiring a separate host.
- Cloudflare Worker-shaped projects. New work can start from the recommended Sites starter; existing projects work if Codex confirms the build produces Worker-compatible ES module artifacts.
The honest caveat: it is in preview, the published state is always production (so lean on save-without-deploy as your gate), and the public-web features — custom domains especially — aren't documented yet. For deeper how-tos, see our explainer on what Codex Sites is and the walkthrough on deploying an existing project to Codex Sites.
When Vercel or Netlify win
For most public, production-facing work in 2026, the git-to-host platforms are still the stronger choice:
- You need a custom domain, today. Both document domain setup; Codex Sites does not (in preview).
- You want preview URLs per branch. The deploy-preview workflow is the single biggest reason teams adopt Vercel and Netlify — reviewers click a real URL on every PR without touching production.
- You're shipping a real framework app. Vercel is the maker of Next.js and pairs tightly with it; Netlify has deep, broad framework support. Both have mature ecosystems, integrations, and analytics.
- You have an existing repo and CI mindset. If Git is already your source of truth, git-push-to-deploy fits your team without a new mental model.
Between the two, the short version: Vercel if you're on Next.js or want the most opinionated path to production; Netlify if you want the platform that pioneered git-push-and-preview and a slightly more framework-agnostic posture. Either way you get a documented production-grade host, which is exactly what Codex Sites is not trying to be in preview.
Use both: prototype in Sites, graduate to Vercel or Netlify
These don't have to be either/or. A pragmatic 2026 workflow looks like this:
- Think it through across models first. Before you write the prompt, pressure-test the brief — pages, data model, auth, what "done" means. This is where a multi-model chat helps: ask GPT, Claude, and Gemini the same brief and compare. You can do that in one place on oran.chat and branch the conversation instead of overwriting it, so a sharper draft of the prompt survives. (oran.chat is a thinking tool, not a deploy tool — it ends where Codex Sites begins.)
- Prototype in Codex Sites. Hand the refined brief to Codex, save versions to review, and get a working internal build in front of people quickly.
- Graduate to Vercel or Netlify when it goes public. Once the thing needs a custom domain, branch previews, and a production CI pipeline, move the validated project to a general-purpose host. The Cloudflare Worker-compatible build you produced for Sites is a reasonable starting point for that migration.
The mistake we see is forcing one tool to do both jobs — pushing an internal prototype onto a production host before it's worth a domain, or trying to run a public marketing site out of a preview product without custom domains. Match the tool to the stage.
Where this fits
This is one comparison in our Comparisons cluster. If you're weighing prompt-to-host builders against each other, read Codex Sites vs v0, Bolt, and Lovable. For the broader market view of AI tools, the pillar is the best ChatGPT alternatives in 2026. And remember the core trade: Codex Sites bets on prompt-to-host with production-by-default and a save-to-review gate; Vercel and Netlify bet on git-to-host with previews first. Choose by stage, not by hype.