Redeploy when the repository changes

Manual deployment helped prove the configuration. Now Cloudflare Workers Builds can run the same commands when GitHub receives a commit. This is a release pipeline: source changes still need review and a successful hosted build before they are live.

1. Connect the existing Worker

Open the existing my-blog Worker in the intended Cloudflare account. In its build settings, connect GitHub and select the private my-blog repository. Restrict the GitHub app installation to this repository rather than all repositories when the authorization screen permits that choice.

Review the GitHub identity and repository before approving access. If Cloudflare cannot see a private repository, check installation access instead of making it public. Dashboard labels may change; Workers Builds configuration describes the current settings.

2. Use the same toolchain

Setting	Course value
Worker name	my-blog, exactly matching wrangler.jsonc
Production branch	main
Root directory	Repository root (/)
Build command	pnpm verify
Deploy command	pnpm exec wrangler deploy
NODE_VERSION build variable	24
PNPM_VERSION build variable	11.19.0
Install command, if exposed	pnpm install --frozen-lockfile

Explicitly pin the pnpm build version: the provider’s default can differ from the packageManager field. See the Workers build image for supported overrides. Commit pnpm-lock.yaml; a frozen install should fail rather than silently resolve a different dependency set.

The deploy command does not call pnpm deploy because the build command has already performed verification. That avoids an unnecessary second build. Build variables are distinct from runtime variables/secrets used by a future comments Worker.

Cloudflare’s managed integration handles deployment authorization. Inspect its access scope in the dashboard; do not add a broad API token to a committed file.

Disable non-production branch builds if you do not need them. If you enable previews later, treat their URLs as public. preview_urls: false in Wrangler does not replace reviewing branch-build settings. A future preview containing a comments API must use a separate database, queue, and identity configuration.

3. Test one small release

Change a harmless sentence on your homepage. Run:

pnpm verify
git diff
git add src/pages/index.astro
git commit -m "Refine the homepage introduction"
git push origin main
git rev-parse HEAD

Open Cloudflare’s build entry for that exact commit. Wait for both build and deploy success. Open your actual domain and confirm the new sentence appears. An earlier successful build does not prove the newest commit deployed.

4. Test a rejected release locally

In an unpublished practice file, temporarily remove the required description. Run pnpm verify; it should fail before deployment. Restore it and rerun verification. You do not need to push a deliberately broken release to learn this behavior.

If a real hosted build fails, read its logs, reproduce the problem locally using the frozen lockfile and matching tool versions, fix it, and push a new reviewed commit. The previous deployment normally remains live when a build fails before deployment; verify the actual site and deployment version rather than assuming.

Checkpoint

You can trace one source commit through a successful Cloudflare build to visible content on the domain. Your private repository stays private, the published site stays public, and the CI setup uses the same verification command as your computer.