Stand Up a Site with Cloudflare, GitHub, and Claude — Hands-Off After Setup

I’ve been running TravTeks on a stack that costs me almost nothing, gives me global edge delivery, and lets me edit the site from my phone by typing a sentence to an AI. After a few months of iteration the pattern is worth documenting — not because it’s clever, but because it’s boring, in the good way. The same setup works for any small site: a personal blog, a docs portal, a marketing page, a side project.

The pieces:

• GitHub — source of truth for everything. Every post, every layout change, every config tweak lives in version control.
• Cloudflare Pages — hosting on the free tier, Git-integrated CI/CD, custom domain, edge cache, automatic HTTPS.
• Claude — your second pair of hands. Hand it a scoped access token to your GitHub repo and it can clone, edit, commit, and push for you. Cloudflare does the rest.

Once these three are wired together, the day-to-day workflow is:

1. Open Claude in a chat
2. Tell it what you want changed (“add a new post about X”, “fix the hero copy”, “make the featured cards have more padding on the left”)
3. Claude makes the change in your repo, commits, pushes
4. Cloudflare detects the push, runs your build, deploys
5. ~60–90 seconds later, your changes are live

No FTP. No server to patch. No CI config to babysit. No screen-sharing your laptop to fix a typo.

Here’s how to set it up end to end.

Prerequisites

• A GitHub account (free is fine; the repo can stay private)
• A Cloudflare account (free tier covers personal sites with room to spare)
• A domain you control — either registered through Cloudflare, or one where you can change DNS or nameservers
• A static site project ready to push, or a starter you’ll generate in step 1. Astro, Hugo, Eleventy, Next.js static export, plain HTML — anything that produces a build folder works.

Step 1 — Push your site to GitHub

Create a new repo on GitHub. Private is fine — Cloudflare and Claude can both access private repos with the right tokens. Then locally:

git init
git add .
git commit -m "Initial commit"
git branch -M main
git remote add origin https://github.com/YOU/your-site.git
git push -u origin main

If you don’t have a site yet, scaffold one in 60 seconds:

npm create astro@latest my-site
cd my-site
npm install
git init && git add . && git commit -m "Initial commit"
# create the GitHub repo, then:
git remote add origin https://github.com/YOU/my-site.git
git push -u origin main

You can swap Astro for whatever fits your style — I happen to like it because it produces a fast static build with no JS hydration unless you ask for it. Hugo, Eleventy, Jekyll, plain HTML files in a folder all work the same from Cloudflare’s side.

Step 2 — Connect Cloudflare Pages to your repo

In the Cloudflare dashboard:

1. Workers & Pages → Create → Pages tab → Connect to Git
2. Authorize the Cloudflare GitHub app and pick your repo. You can scope the install to just this one repo — Cloudflare doesn’t need to see the rest of your account.
3. Configure the build:
   • Framework preset — pick yours (Astro, Hugo, etc.). For unfamiliar setups, choose “None” and fill in the next two fields manually.
   • Build command — usually npm run build
   • Build output directory — typically dist/, public/, or _site/ depending on the framework. Check your framework’s docs if you’re unsure.
4. Save and Deploy.

Cloudflare runs the build on its own infrastructure (no GitHub Actions minutes burned), uploads the output to its global edge, and gives you a your-site.pages.dev URL within about a minute. From this point forward, every push to main triggers a fresh build and deploy automatically. That’s the part that makes the rest of this work.

Pages vs. Workers — what’s going on: Cloudflare is gradually merging Pages into Workers (it’s all “Workers + Static Assets” under the hood now). Pages is still the simpler entry point with the cleanest Git UX, and is what I recommend for any new site. If you later need server-side logic, edge KV/R2/D1 storage, or scheduled jobs, you can add Pages Functions or migrate to Workers without changing the user experience.

Step 3 — Wire up your custom domain

Still in the same Pages project:

1. Custom domains → Set up a custom domain → enter yoursite.com
2. If your domain is already on Cloudflare’s nameservers, the DNS records get created automatically. Done.
3. If not, follow the prompts to either move DNS to Cloudflare (recommended), or add a CNAME at your existing DNS host pointing to your-site.pages.dev.

SSL is automatic. Within a couple minutes, https://yoursite.com is live and serving from Cloudflare’s edge in 300+ cities.

Step 4 — Give Claude access to your repo

This is the interesting part. You’re going to create a fine-grained GitHub Personal Access Token (PAT) scoped to just this one repo, then hand it to Claude.

Why fine-grained: classic PATs can read and write every repo your account has access to. That’s far too much trust for a token you’ll paste into a chat. Fine-grained tokens limit access to specific repositories and specific permissions, with a required expiration. They’re the right tool here.

Generate the token:

1. GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token
2. Fill it in:
   • Token name — something descriptive, like claude-yoursite
   • Expiration — 30, 60, or 90 days. Treat this as your rotation interval.
   • Resource owner — yourself (or your org, if applicable)
   • Repository access — Only select repositories → pick the one repo from step 1, and only that one
3. Permissions (under Repository permissions) — keep them minimal:
   • Contents → Read and write (this is what’s needed to clone, commit, and push)
   • Metadata → Read-only (auto-included, can’t disable)
   • That’s it. Don’t grant Administration, Webhooks, Workflows, or anything else unless you have a specific reason to.
4. Generate token → copy the value. It starts with github_pat_…. You only see it once.

Hand it to Claude:

Open a Claude conversation and share two things — the repo URL and the token. A clean way to phrase it:

My site repo is YOU/your-site. Here’s a fine-grained token with content read/write scope: github_pat_xxxxxxxxxxxxxxxxxxx. I’d like you to make changes to the site by cloning, editing, committing, and pushing. Cloudflare auto-deploys on push, so I just need to wait ~90 seconds after your push to see results.

Claude will clone with https://<token>@github.com/YOU/your-site.git, work in its sandbox, commit with a sensible message, and push. The Cloudflare webhook fires. The build runs. The site updates.

Step 5 — The development loop

Once the token is in place, day-to-day looks like this:

• “Add a new post under the Networking category about ARP poisoning. Here’s the rough outline…” → Claude drafts the markdown, places it in src/content/blog/, pushes.
• “Bump the homepage hero text size by about 10%.” → Claude edits the layout file, pushes.
• “My latest post has a typo in paragraph three.” → Claude finds it, fixes it, pushes.
• “Move the contact CTA above the fold and make it amber instead of blue.” → Claude edits the component, pushes.

What I find genuinely useful is that Claude can read your existing patterns from the repo before making changes. It picks up your frontmatter conventions, tag style, category naming, code-block formatting, and writing voice — so new posts match the rest of the site without re-explaining the structure every time. Layout tweaks slot into your existing CSS instead of getting their own ad-hoc styles bolted on.

When something goes wrong (a typo in a frontmatter field, a broken layout, a failing build), Cloudflare emails you and the previous deploy stays live. You can either ask Claude to investigate and fix forward, or roll back to a known-good deploy from the Cloudflare dashboard with one click.

Security considerations

You’re handing out a credential to a chat session, so it’s worth being deliberate about a few things:

• Use fine-grained tokens, never classic PATs. A compromised fine-grained token affects one repo with limited permissions. A compromised classic token is much worse.
• Set a real expiration and respect it. GitHub now requires it. 30 to 90 days is reasonable. When it expires, generate a new one and update the chat — don’t extend forever.
• Don’t paste tokens in shared or group chats. Treat them like passwords. The conversation should be just you and Claude.
• Revoke tokens you’re done with. GitHub: Settings → Developer settings → Personal access tokens → Fine-grained tokens → click the token → Revoke. If you ever can’t account for a token, revoke it without thinking twice.
• Review the diffs. GitHub emails you on every push. Open the commit on github.com and skim what changed. Trust but verify.
• The repo can stay private. Nothing in this workflow requires public source code. Cloudflare and Claude both work fine with private repos.

If you’re working inside an organization repo rather than a personal one, your org admin may need to enable fine-grained PAT access in the organization settings first. This is a one-time toggle.

When to graduate from Pages to Workers

Pages is the sweet spot for static sites and most blogs. Reasons to think about Workers (or Pages Functions, which are smaller Workers-flavored handlers attached to a Pages project) eventually:

• Server-rendered pages with dynamic data per request
• Form submission endpoints or contact handlers
• Auth gates, paywalls, or rate limiting
• Edge KV / D1 / R2 storage integration
• Scheduled jobs via Cron Triggers

Workers also exposes a richer configuration surface: compatibility flags, multiple environments, finer-grained bindings. If you’re unsure, start with Pages and migrate later — there’s a documented Pages-to-Workers migration path that handles most cases without breaking your URLs.

Wrap-up

End to end, this is maybe 30 minutes the first time and 5 minutes once you’ve done it before. What you get is a site you can edit from anywhere — including, in my case, a phone — by typing a sentence to an AI that already understands your repo.

This is how this site is run. New posts get written, layouts get tweaked, OG cards get regenerated, and deploys happen — all from inside Claude conversations. The infrastructure stays out of the way, which is the whole point of infrastructure.

If you set this up for your own site, the setup gives you the same loop: faster iteration, lower friction, no servers to babysit, and the pieces stay free or near-free at the scale most personal sites operate. Worth half an hour.