Cloudflare Pages Deployment Setup

This site deploys via .github/workflows/deploy.yml, which builds the static export and pushes it to Cloudflare Pages using wrangler-action. It needs two repository secrets before it can run.

Get your Cloudflare Account ID

Log into the Cloudflare dashboard , go to Workers & Pages, and copy the Account ID shown in the right sidebar (also visible in the URL: dash.cloudflare.com/<ACCOUNT_ID>/...).

Create a scoped API token

Go to My Profile → API Tokens and click Create Token.

Use a scoped token, not your Global API Key — the Global Key has full account access and should never be pasted into a CI secret.

Use the “Edit Cloudflare Workers” template, or a custom token with:

Permission: Account → Cloudflare Pages → Edit
Account Resources: scoped to your specific account only

Copy the token immediately — it’s shown once and can’t be retrieved again.

Create the Pages project

wrangler pages deploy deploys into an existing project — create it once, either via the dashboard (Workers & Pages → Create → Pages → Direct Upload, named to match the workflow’s --project-name value) or from the command line:


npx wrangler pages project create ranlanka-docs

Add the secrets to GitHub

In the repo: Settings → Secrets and variables → Actions → New repository secret.

Secret name	Value
`CLOUDFLARE_API_TOKEN`	The token from step 2
`CLOUDFLARE_ACCOUNT_ID`	The account ID from step 1

Trigger a deploy

Push to the branch configured in the workflow’s on.push.branches, or trigger it manually from the Actions tab (workflow_dispatch).

Troubleshooting

“Project not found” — the Pages project name in the workflow’s --project-name flag doesn’t match an existing project. Create it first (step 3), or fix the name to match.

401/403 from the deploy step — the API token is missing the Cloudflare Pages → Edit permission, or is scoped to the wrong account. Regenerate it with the correct scope.

Build succeeds locally but fails in CI — confirm npm ci (not npm install) is used in the workflow, so the exact locked dependency versions are installed; a local node_modules that’s drifted from package-lock.json can hide a real CI failure until it’s actually run there.