What this actually is

Cloudflare is free hosting your AI can drive by itself.

Hosting means: the place your website lives so that other people can open it. Normally that's a monthly bill — Webflow, Wix, Squarespace, a server somewhere. Cloudflare gives it away on a free plan that is genuinely generous, and it has one property none of the others have: it is fully controllable from a command line, which means your AI can do it without you touching a dashboard, a builder, or a settings page.

That's the whole unlock. You describe what you want, your AI builds it, your AI ships it, and you get a link back. No hand-off, no "now export this and upload it somewhere."

The five words, in plain English

You'll hit these five terms constantly and every guide assumes you know them. You don't need to understand them deeply — you just need to stop being confused when your AI says one.

A domainthe address

The address of your shop: yourbusiness.com. You rent it by the year from a registrar. It is just a name — it holds nothing and does nothing on its own. It points at wherever you tell it to point. Roughly $10–15 a year · Cloudflare sells them at cost

DNSthe signpost

The internet's address book. It is what connects the name to the actual building. When someone types your domain, DNS is the thing that says "that address means this place, over here." Cloudflare is one of the best address books in the world, and it's free. Free · unlimited domains

Cloudflare Pagesthe building

Where your files actually live and get handed to visitors. It serves static sites — meaning the pages are already written, and everyone who visits gets the same thing. Landing pages, reports, documentation, one-pagers, dashboards that just display. This covers about 80% of what you'll ever want to ship. Free · unlimited visitors · unlimited bandwidth

A Workerthe member of staff

A static page can't do anything — it can't check a password, save a form, or call an AI. A Worker can. It's a small piece of code that runs the instant someone visits, and it can think, check, save and fetch. In normal language: a Worker is a backend without a server. It's how a page becomes an app. Free up to 100,000 visits a day · then $5/month

A subdomaina room in the building

Anything in front of your domain: docs.yourbusiness.com, reports.yourbusiness.com, acmecorp.yourbusiness.com. You get unlimited of them, free, off the one domain you already rent. This is how you give every client their own address without buying anything. Free · unlimited

One more you'll see your AI type: wrangler. That's the delivery van — the command that moves your files from your laptop into the building. You will never need to learn it. Your AI runs it.

What you actually get

Five things you can do this week that you probably can't do today.

What it costs

Verified against Cloudflare's published limits, August 2026. The honest summary: for what an agency does, it is free, and it stays free for a very long time.

To put 100,000 requests a day in perspective: that is a page being loaded roughly once a second, all day, every day. If you cross it, the fix is five dollars.

Start — five steps

Do these once. After that, shipping anything is one sentence.

1. Make a free Cloudflare account Go to dash.cloudflare.com/sign-up. Email and a password. No card, no trial, no sales call.

   Two minutes. Don't buy anything and don't add a domain yet — you don't need one to start.

2. Copy two things down You need an Account ID and an API token. Both live in the same dashboard.

   Account ID — click Compute (Workers) in the left sidebar. The Account ID is on the right-hand side of that page. It's a long string of letters and numbers. Copy it.
   API token — click your profile icon (top right) → Profile → API Tokens → Create Token. Choose Create Custom Token, then under Permissions pick Account → Cloudflare Pages → Edit. Create it, and copy the token. It is only shown once — paste it somewhere now.

3. Put them in a file called .env In the folder your project lives in, make a plain text file named .env (yes, starting with a dot) containing exactly two lines:

   CLOUDFLARE_API_TOKEN=your-token-here
   CLOUDFLARE_ACCOUNT_ID=your-account-id-here

   Copy

   Or skip this entirely — paste the two values into your AI and say "put these in a .env file for me." It'll do it. Never paste a token into a chat that isn't yours, and never commit .env to a public repo.

4. Paste the prompt Open your project in Claude Code, Cursor, Codex or whatever you use, and paste The Prompt below. It tells your AI everything it needs and, importantly, tells it not to lie to you about whether it worked.
5. Say "deploy it" You get back a live link ending in .pages.dev. That link works for anyone, anywhere, immediately. Send it to a client.

   Want it on your own domain instead of .pages.dev? That's one more sentence — it's covered in How It Works.

The prompt

Copy this into Claude Code, Cursor, or any coding agent, with your project folder open. The last paragraph is the important one — it's the difference between getting a working link and getting a confident lie.

I want to put this project live on Cloudflare so I can send it
to a client as a real link.

My Cloudflare API token and Account ID are in the .env file in
this folder. If there is no .env file, tell me and stop.

Please:
1. Look at this folder and tell me in one sentence what kind of
   site it is and whether it is ready to deploy.
2. Create the Cloudflare Pages project if it does not exist yet.
3. Deploy the whole folder.
4. Give me the live URL.

Rules:
- Assume I am not technical. If something is missing (a token, an
  index.html, a build step), tell me exactly what to do in plain
  English. Do not assume I know what any of it means.
- Do NOT tell me it worked until you have actually opened the live
  URL yourself and confirmed it loads and shows the right content.
  "It deployed successfully" is not the same as "it works" - check it.
- If anything fails, show me the actual error and what you are going
  to try next. Do not silently retry or guess.

Works with Claude Code · Cursor · Codex · any agent with terminal access

What to do first

Don't try to do all five use cases. Pick the one that's already sitting on your desk:

The whole journey

The part worth understanding: your files get copied to hundreds of cities at once. A visitor in Sydney is served from Sydney, not from wherever you uploaded. That's why it's fast everywhere without you configuring anything, and it's why the free bandwidth isn't a trick — serving cached files is genuinely cheap for them.

The two kinds of thing you can build

Almost every question you'll have comes down to which of these two you're making.

The good news for anyone non-technical: you don't choose up front and you don't migrate later. A static site becomes an app by adding a folder. It's the same project, same domain, same deploy command. So start static, always.

Putting it on your own domain

A fresh deploy gives you something.pages.dev. That's a real, working, shareable link — but for client-facing work you'll want your own name on it. Here's the part that trips up literally everyone, including experienced developers:

In practice, the sequence is:

1. Get the domain onto Cloudflare Either buy it from Cloudflare directly (simplest — it arrives already connected), or if you already own it elsewhere, add it to Cloudflare and change its nameservers at your current registrar.

   Nameservers = telling the world "Cloudflare is now my address book." It's two fields at GoDaddy/Namecheap/wherever. Takes minutes to swap, up to a few hours to spread everywhere.

2. Attach the domain to your site In the Pages project → Custom domains → add it. Or let your AI do it.
3. Make sure the DNS record actually exists This is the step that gets skipped. There must be a record pointing your domain at yourproject.pages.dev. If you bought the domain from Cloudflare and attached it in the dashboard, this is usually created for you. If you're scripting it, you have to create it yourself — and it uses different credentials to the deploy step, which is why scripts silently half-work.
4. Wait for the padlock Cloudflare issues the HTTPS certificate automatically once DNS resolves. Usually a few minutes, occasionally 15. A certificate warning in the first ten minutes is normal, not broken.

The four things that will bite you

These are the ones worth knowing in advance, because each one fails quietly — you won't get an error, you'll get something that looks fine and isn't.

When you outgrow it

One real ceiling exists and it's worth knowing about before you hit it, because the obvious workaround makes it worse.

You can have 100 Pages projects per account, and Cloudflare says that limit is not routinely increased.

Each separate site is one project. If your model is "every client gets their own site," you have a hundred clients' worth of runway and then a wall. The instinctive fix — "we'll stop buying domains and just use the free .pages.dev ones" — is backwards, because a .pages.dev address is a project. It consumes the scarce thing faster while saving the abundant one. Domains have no limit at all.

The actual fix is to stop creating a project per client: one domain, one Worker, and a wildcard so that every client gets a subdomain served by the same deployment. Unlimited clients, one project. That's a build, not a setting — the specifics are in Tab 3.

Stack anatomy

The shape that works, and the division of labour that keeps it cheap: Cloudflare is the edge and the front door; anything long-running or heavy belongs somewhere else.

The commands

# one-time: create the project
npx wrangler pages project create <name> --production-branch main

# deploy (idempotent; --branch main pins the stable *.pages.dev alias)
npx wrangler pages deploy <dir> --project-name=<name> --branch=main

# local dev, with Functions running
npx wrangler pages dev <dir> --compatibility-flags=nodejs_compat

# secrets (prod). local dev reads .dev.vars instead
npx wrangler pages secret put <NAME> --project-name=<name>

# standalone Worker (not Pages) — for the wildcard/multi-tenant model
npx wrangler deploy -c wrangler.toml

# sanity
npx wrangler whoami
npx wrangler pages project list

Auth via CLOUDFLARE_API_TOKEN + CLOUDFLARE_ACCOUNT_ID in env

Omit --branch=main and wrangler infers the branch from git — which produces a preview deployment on a hashed URL rather than updating the stable alias. This is the most common "I deployed but the site didn't change."

Pages Functions

File-based routing, no router config. Every file exports onRequest/onRequestGet/onRequestPost and receives a context object carrying request, env (bindings + secrets), data, params and next.

functions/
  _middleware.ts        // runs before everything below it
  api/
    _middleware.ts      // scoped to /api/* only
    health.ts           // -> GET  /api/health
    chat.ts             // -> POST /api/chat
    auth/
      verify.ts         // -> /api/auth/verify
    conversations/
      [id].ts           // -> /api/conversations/:id
    _lib/               // underscore = not routed. shared code lives here
      env.ts  db.ts  session.ts

Directories and files prefixed with _ are never routed — that's where shared helpers go. A _middleware.ts applies to its own directory and everything beneath it, which makes it the natural place for auth: resolve the session once, hang the user on context.data, and let downstream handlers assume it.

Configuration

# wrangler.toml — Pages
name = "my-project"
compatibility_date = "2024-11-01"
compatibility_flags = ["nodejs_compat"]   # needed for most DB drivers
pages_build_output_dir = "dist"

# wrangler.toml — standalone Worker serving many clients off one wildcard
name = "my-app"
main = "worker/index.ts"
compatibility_date = "2024-11-01"
compatibility_flags = ["nodejs_compat"]

[assets]
directory = "dist"
binding = "ASSETS"
not_found_handling = "single-page-application"  # SPA deep links survive refresh
run_worker_first = true                        # else static files answer before your code

[[kv_namespaces]]
binding = "TENANTS"        # hostname -> { config, db_url, secret }
id = "<namespace-id>"

[[routes]]
pattern = "*.yourdomain.com/*"   # wildcards work on Workers. NOT on Pages.
zone_name = "yourdomain.com"

run_worker_first = true is subtle and important: without it the static asset server answers first, so a per-client /config.json would be served from whichever build shipped last — to every client.

The multi-client architecture

The escape hatch from the 100-project ceiling. Instead of a project, a domain, a secret set and a certificate wait per client, one Worker answers a wildcard host and reads the Host header to decide who it's serving.

Two constraints make this work rather than merely compile:

Done properly, provisioning a new client stops being a deploy pipeline and becomes a single KV write.

Limits — free plan

Verified against Cloudflare's published documentation, August 2026.

Workers Paid is $5/month minimum, including 10 million requests and 30 million CPU-milliseconds; then $0.30 per additional million requests and $0.02 per additional million CPU-ms.

Wiring a domain by API

The two-call sequence, and the credential split that makes scripted setups fail silently.

# 1. attach the domain to the Pages project — uses the API TOKEN
POST /client/v4/accounts/<account>/pages/projects/<project>/domains
     Authorization: Bearer $CLOUDFLARE_API_TOKEN
     { "name": "app.yourdomain.com" }

# 2. create the DNS record — the Pages token 401s here. Needs the GLOBAL key.
POST /client/v4/zones/<zone>/dns_records
     X-Auth-Key:   $CLOUDFLARE_GLOBAL_API_KEY
     X-Auth-Email: $CLOUDFLARE_EMAIL
     { "type": "CNAME", "name": "app.yourdomain.com",
       "content": "<project>.pages.dev", "proxied": true }

For agents

This page is machine-readable. Point any coding agent at either file and it has everything it needs to provision, deploy and verify without a human in the loop.

# markdown, for LLM context
curl https://<this-host>/llms.txt

# structured, for programmatic use
curl https://<this-host>/manifest.json

Both are linked from this page's <head> via rel="alternate"