Deploying Static Sites With Claude Code and Cloudflare

Posted 30 Aug 2026 11 min read

This guide is written for SEO specialists running small sites: landing pages, programmatic SEO pages, microsites, and similar low-complexity properties, who want to deploy changes fast using Claude Code without manually touching hosting, FTP, or a dashboard for every edit. The same process scales from one site to a portfolio of many, using the same repository and the same daily workflow for each.

Table of Contents

The Problem

Small static sites do not need a complex hosting stack. A handful of pages and a stylesheet can run without a server, without ongoing maintenance, and with a build pipeline that only exists to compile the site once before it ships.

The part that consistently causes problems is the deployment model, not the sites themselves. An instruction like “use GitHub and Cloudflare Workers” sounds simple, but without a clear process behind it, the default fallback is to treat GitHub as a place to download files from and Cloudflare as a place to upload files to: FTP, in effect. This breaks the entire point of the setup. GitHub is meant to be the single source of truth for the code. A second, unmanaged copy of the site, whether a local folder or a ZIP file uploaded by hand, breaks that model immediately.

Example

When ten small client sites needed to be built, the instruction given was straightforward: use GitHub and Cloudflare Workers, static deployment, no manual hosting. Instead, after consulting ChatGPT and Claude for a second opinion on the instructions, the colleague assigned to the work began manually uploading ZIP files of the site to Cloudflare Workers for every change, bypassing GitHub entirely.

This produced the failure mode described above, at ten times the scale. Each site’s live version and its local files could drift apart with no way to compare them. Nothing was tracked, nothing was reviewable, and a mistake on any one of the ten sites had no audit trail to trace back through.

This guide sets out the correct process end to end, so it does not need to be re-explained per project.

Why This Works

The workflow is: Claude Code edits the site locally, GitHub stores every version of the code, and Cloudflare Workers rebuilds the live site automatically whenever GitHub’s main branch changes. Shipping a change means committing and pushing. There is no manual upload step, no dashboard visit, and no risk of two people working from two different, unsynced copies of the same site.

This scales in a way manual uploads do not. Ten sites, each following the identical process, are no harder to manage than one; the process is copied, not reinvented per site. Every change to every site has a timestamp, an author, and a diff. If something breaks, the previous version is one command away.

Manually uploading ZIP files to Cloudflare has none of this. There is no history, no way to see what changed between uploads, and no way to tell which local copy on which machine is actually current once more than one person is involved. It works, technically, for a single site edited by a single person who never makes a mistake. It does not hold up past that.

Git Basics

Git and GitHub are not the same thing. Git is version control software that runs locally and tracks changes to a set of files over time. GitHub is a hosting service for Git repositories; it stores a remote copy of the project and adds features on top, such as pull requests and access control.

A few terms come up throughout this guide:

Repository (repo): a folder tracked by Git, containing the project’s full file history.
Commit: a saved snapshot of changes, with a short message describing what changed.
Branch: a parallel line of work. main is the default branch and, in this setup, represents the live, approved version of the site.
Push / Pull: sending local commits to GitHub (push), or fetching GitHub’s latest commits into the local copy (pull).
Pull request (PR): a proposed merge of one branch into another, opened for review before it happens.

None of this needs to be memorized to use the workflow day to day. Claude Code runs these operations on request, in plain language. The concepts matter for reading what Claude Code reports back, and for troubleshooting when something does not look right, not for typing commands from memory.

The Stack: Claude Code, GitHub, and Cloudflare Workers

Three tools make up this workflow, each with one job.

Claude Code edits files. It runs locally and has access to the project folder and a terminal. It can create files, edit files, and run commands, including Git commands, when asked.

GitHub hosts the repository and functions as the single source of truth. Every version of every file that has ever been committed lives here, with a full history of who changed what and when.

Cloudflare Workers is the hosting and deployment target. It watches the connected GitHub repository and rebuilds the live site automatically whenever the main branch changes.

Cloudflare Workers is used here instead of Vercel for one practical reason: cost at scale for small static sites. As of August 2026, Vercel’s Hobby plan is free but restricted to personal, non-commercial use under its own fair use terms; a client site on Hobby is not compliant with that plan. Commercial use requires Vercel Pro, at $20 per seat per month. Cloudflare does not draw that distinction. Static asset requests are free and unlimited on every Workers plan, including the free one. Running ten, twenty, or a hundred small commercial sites costs nothing extra on Cloudflare for being commercial; on Vercel, the pricing model assumes otherwise from the first client site.

Do Not Reinvent the Wheel

The sites in this workflow are built with Astro, a static site framework, rather than as fully custom HTML and CSS written from a blank file. Astro is the default starting point, not a custom build. When Claude Code sets up a new site, the instruction is to reach for an existing Astro theme or starter template that already fits the type of site being built, and an existing component library, such as daisyUI (a Tailwind CSS component library), for the actual UI pieces: navigation, cards, forms, tables, buttons.

The reasoning is practical, not aesthetic. A site built entirely from scratch means every one of those UI pieces has its mobile behavior, its accessibility, and its edge cases (long text in a table cell, a form field on a small screen, a dropdown near the edge of the viewport) worked out from zero, for every site, individually. An existing, maintained theme or component library has already had that worked out, by far more usage than any one small client site will ever generate. Rebuilding it is not more control; it is more surface area for the same bugs to reappear.

In practice, this means prompting Claude Code with the starting point already named, rather than asking it to design one:

use the <theme-name> Astro theme as the starting point, and
build the components with daisyUI instead of custom CSS

Claude Code still writes the actual site: content, structure, copy, page-specific layout. What it is not doing is inventing a design system, a grid, and a component library from nothing for every new client site.

This also changes one detail in the setup below. Astro builds the site into a dist folder before it can be deployed; that folder, not the raw source, is what Cloudflare serves.

Setting Up GitHub

Create a GitHub account at github.com, if one does not already exist.
Create a new repository: select New repository, name it, and choose Private (recommended for client work) or Public. It does not need to be initialized with a README; Claude Code populates it in the next section.
Note the repository’s URL (github.com/<account>/<repo-name>). It is needed when connecting Claude Code and, later, Cloudflare.

Installing and Connecting Claude Code

Install Claude Code:

macOS, Linux, WSL:

curl -fsSL https://claude.ai/install.sh | bash

Windows (PowerShell):

irm https://claude.ai/install.ps1 | iex

Confirm the install:

claude --version

Start a session inside the project folder for the site, and log in when prompted. A Claude Pro, Max, Team, or Enterprise account, or a Claude Console account, is required.

cd path/to/site-project
claude

The first session asks for approval before each file change or command. This is Manual mode. On Pro, Max, and Team plans, later sessions default to Auto mode, where a classifier approves most routine actions automatically; press Shift+Tab at any point to switch modes. Manual review is worth keeping on for anything touching Git or deployment until the workflow is familiar.

Inside the session, in plain language:

initialize a git repository here, set the remote to
github.com/<account>/<repo-name>, and make the first commit

create a wrangler.jsonc for a static site called <site-name>,
serving files from ./dist, and use today's compatibility date

push this to GitHub

Claude Code runs the underlying git init, git remote add, git add, git commit, and git push commands, and writes the config file, without those commands needing to be typed by hand. Note that ./dist does not exist until the Astro site has been built at least once (npm run build); Cloudflare runs that build step itself once the repository is connected, covered next.

What actually changed can always be checked afterward:

show me what changed in the last commit

Setting Up Cloudflare Workers Correctly

Create a Cloudflare account at cloudflare.com. No credit card is required for the Workers Free plan.
From the dashboard, go to Workers & Pages.
Select Create application, then Get started next to Import a repository.
On the first connection, Cloudflare prompts for GitHub authorization. Choose whether to grant access to all repositories or select specific ones; selecting specific repositories is the safer default when the GitHub account holds other, unrelated work.
Select the repository created earlier.
Configure the project. Cloudflare typically detects Astro automatically and prefills the build command as npm run build and the output directory as dist; confirm these rather than leaving them blank, since an Astro site needs an actual build step, unlike a plain HTML site. Confirm main as the production branch.
Select Save and Deploy. Cloudflare runs the first build and deploy.
Confirm the site is live at the provided *.workers.dev subdomain before attaching a custom domain.

For a Worker that already exists and needs a Git repository connected or changed afterward, the path is Settings → Builds → Git Repository → Manage instead of the steps above.

Adding a Custom Domain

A Workers Custom Domain requires the domain to be an active Cloudflare zone. If the domain was purchased elsewhere, such as Namecheap or GoDaddy, and is not already on Cloudflare, it needs to be added first.

In the Cloudflare dashboard, select Add a Site and enter the domain.
Cloudflare scans the domain’s existing DNS records and assigns two nameservers.
Update the domain’s nameservers at the registrar to the ones Cloudflare provides. This step happens outside Cloudflare, at wherever the domain was registered.
Wait for the nameserver change to propagate. This can take anywhere from a few minutes to about 24 hours. Cloudflare marks the zone Active once it detects the change.

Once the zone is active:

Open the Worker, go to Settings → Domains & Routes → Add → Custom Domain, and enter the domain or subdomain.
Select Add Custom Domain. Cloudflare creates the DNS record and issues the certificate automatically; no manual DNS entry or certificate management is required.

For a portfolio of many small sites, each on its own domain, this zone step happens once per domain, and in practice takes longer than the Worker setup itself, mainly because nameserver propagation is outside anyone’s direct control.

The Daily Workflow With Claude Code

Once a site is live, changes go through Claude Code rather than through raw Git commands. In plain language, inside a session started in the project folder:

pull the latest changes

update the pricing on the homepage from $49 to $59

show me what changed before committing

commit and push that

Claude Code translates each of these into the appropriate Git operations, and once pushed to main, Cloudflare rebuilds and redeploys automatically. No dashboard visit is needed for a routine content change.

One default worth knowing: as of August 2026, Auto mode’s classifier permits pushing directly to main without asking first. For a single-operator site with low stakes, that is generally fine. For anything reviewed by a client before publishing, either stay in Manual mode for the push step specifically, or ask Claude Code to work on a branch and open a pull request instead:

put this on a branch and open a pull request instead of
pushing straight to main

Cloudflare generates a preview URL for the pull request, so the change can be checked as a running site before it goes live.

Scaling to Multiple Sites

The same repository can serve many independent sites, each connected to its own Cloudflare Worker.

sites/
  client-a/
    wrangler.jsonc
    (astro project files)
  client-b/
    wrangler.jsonc
    (astro project files)
  client-c/
    wrangler.jsonc
    (astro project files)

Each folder is connected to Cloudflare separately, following the setup steps above, with its root directory set to that folder. Build watch paths can be set so a change to client-a does not trigger a rebuild of client-b.

For mass-publishing small SEO sites, this means adding site eleven is not a new repository, a new hosting account, or a new process. It is a new folder, following the same theme and component library as the ones before it, connected once in Cloudflare. Claude Code can be asked to scaffold a new site from an existing one directly:

copy the client-a folder into a new folder called client-d,
update the site name in wrangler.jsonc, and push it

The Cloudflare connection for that new folder is still a manual, one-time step in the dashboard, following the setup section above. Connecting many sites this way through the dashboard does not scale indefinitely; Cloudflare’s API and Terraform provider support scripting this step at higher volume, which is out of scope for this guide.