Hosting decision for Codex builds

Where Should a Codex-Generated Site Be Hosted?

Pick the host from the constraint that actually blocks you: shared workspace access, a custom domain, public SEO, a database, uploads or code ownership. Everything below is either a rule this site already applies or a fact you can check on an official page.

Estimate Scope Risk GitHub and Vercel Path Deploy Checklist

Short answer

Keep the build in Codex Sites while the only people opening it are workspace members. The moment a custom domain, public search traffic or payments become a requirement, the host changes: move the same requirements into a repository and deploy that repository to Cloudflare Pages or Vercel.

GitHub Pages is the lightest option of the three and the most limited. It is the right call when the output is genuinely static and you never want to think about a runtime, and the wrong call as soon as you need server-side code, a database binding or request-time logic.

Storage is the second half of the decision, and it follows the app rather than the host. D1 covers structured records; R2 covers real uploads; a static site needs neither.

Start here

Which host fits which constraint

One row per blocking constraint. These are the same routing rules the interactive tools on this site apply.

Constraint	Default host	Why
Only workspace members should sign in	Codex Sites	Workspace-authenticated internal tools are the Sites lane, so the deployed Sites version is already the right answer.
Your own domain on your own DNS	Cloudflare Pages	A custom domain needs DNS control, analytics, sitemap control and Git-based auto deploy.
Public SEO traffic and crawlable pages	Cloudflare Pages	Public SEO needs sitemap control, analytics and a repository-backed deployment path.
Payments	Vercel or Cloudflare Pages with a backend	Payments need explicit auth, webhook and rollback control, so the money path belongs on a host you own.
A same-day public draft and code ownership is optional	Lovable or Replit	Speed matters more there than keeping full control of the source.
A framework app, preview deployments and code ownership	Vercel	Vercel is built around framework builds, preview deployments and code-owned public products.
Static files straight out of a Git repository and nothing else	GitHub Pages	GitHub Pages publishes static files from a repository and has no server-side runtime to configure.

Side by side

Codex Sites, Cloudflare Pages, Vercel and GitHub Pages

Four decision points that actually change the migration work: what the host is good at, how a domain attaches, whether server code can run, and how storage is reached.

Decision point	Codex Sites	Cloudflare Pages	Vercel	GitHub Pages
Best for	Internal workspace apps, dashboards, review rooms and lightweight data apps.	Public SEO sites, custom domains and Git-based static deployment.	Framework apps, public previews and code-owned product deployment.	Plain static files served from a repository, with no build runtime to manage.
Custom domain	No first-party domain path. Treat a custom domain request as the signal to move to a repository-backed host.	The domain is added to the project, and the DNS record lives wherever the zone is managed.	The domain is added to the project, and the DNS records are created at your registrar or DNS provider.	The domain is configured in the repository settings, with DNS records created at your provider.
Server-side runtime	The Sites runtime, driven by the saved and then deployed version of the app.	Pages Functions run on the Workers runtime, alongside Workers you deploy yourself.	Serverless functions and framework server rendering, billed as usage.	None. Static files only, so no server code runs at request time.
D1 and R2 pairing	The Sites hosting config binds D1 and R2 by name next to the project id.	D1 and R2 attach to the project as platform bindings, so no extra service or credential is introduced.	D1 and R2 are Cloudflare products, so a Vercel project reaches them as external services with their own credentials.	No binding mechanism exists, so any database or file storage is a separate service you add yourself.

Cost: what actually decides the bill

Static hosting has no server to keep running, which is why all three hosts are used as cheap front doors. What you pay for later is everything you add on top of the files:

Bandwidth and request volume, which follow traffic rather than code.
Build minutes and build concurrency, which follow how often the repository is pushed.
Function invocations and CPU time, which appear only once request-time code exists.
Database size and rows read or written, which follow the number of records.
Object storage bytes and egress, which follow uploaded files.
The domain registration itself, paid to a registrar and separate from the host.

This page deliberately publishes no price figures. Rates, free-tier limits and overage rules change, and they differ by plan and region, so treat pricing and limits as official-provider questions rather than something an independent site can guarantee. Verify the current numbers on the official pages listed at the end of this page before you commit a domain to a provider.

Where D1 and R2 sit relative to the host

Codex Sites does not leave storage as an exercise: the hosting config declares the bindings next to the project, and the app reads records from D1 and uploaded objects from R2. That is the same shape as a Cloudflare project, which is why the Cloudflare path is the shortest migration when storage already exists.

Use D1 for structured records, status, owners, tags and notes. Use R2 only for files a user actually uploads, and keep the searchable metadata in D1. Static content needs neither. On Vercel or GitHub Pages there is no binding layer, so the same requirements become external services with separate credentials, separate limits and a separate bill.

Binding shape

{
  "project_id": "",
  "d1": "DB",
  "r2": "ASSETS"
}

Bindings only appear when the app really stores records or uploads. A static site ships with neither.

D1/R2 Storage Planner

Reachability, including mainland China

This site publishes no reachability guarantees for any provider. Whether a host, its CDN edge and its default domain respond on a given network depends on routing, DNS resolution and policy decisions that change without notice, and an independent page cannot honestly promise an outcome it does not continuously measure.

There is exactly one sample this site can stand behind, and it is the page you are reading. The deploy configuration in this repository points this domain at a Cloudflare Pages project, so if this page loads on your network you have one live data point for that provider at that moment. One data point is not a guarantee.

Test the way that matters instead: from the network your users are actually on, check DNS resolution, then the TLS handshake, then the first byte, repeat at a couple of different hours, and run the same test against the provider you are considering before the domain is committed.

Keep DNS and hosting as two separate decisions. The DNS provider decides what you can place in front of the host, and changing the host later is far cheaper than changing the domain.

Before you commit

Hosting checks that prevent a rebuild

Each of these has cost someone a migration, and each one is cheaper to confirm now than to discover after a domain is live.