My Jekyll hosting setup on Cloudflare Workers
The publishing setup takes a checked Jekyll build and gives it a public home. The files stay ordinary HTML, CSS and a little JavaScript.
From repository to published files
This repository is configured for a Cloudflare Worker serving Static Assets. The source lives in www/. Jekyll writes the finished site into _site/, and a validator checks local destinations, images and page fragments before the build succeeds. This is the configuration of the publishing workflow; a successful local build is not itself a deployment.
The Worker uses wrangler.jsonc to point its Static Assets directory at _site. The deployment script runs bash scripts/build.sh, then npx wrangler deploy. The Ruby version is pinned in the repository. The Jekyll-side guide explains the files and checks behind that command.
What Workers adds
Workers gives this site a deployable Worker with a static asset directory, so the same configuration can later add request handling at the edge without moving the content. The current site does not need a runtime function; visitors receive the generated files directly.
For a personal site of notes and project context, Static Assets keeps the serving model small. Visitors receive the built pages; there is no Ruby process or content database needed at request time. The Worker configuration is documented in Cloudflare’s Workers configuration guide.
Keep the address stable
The domain is the public address. A custom domain is attached to the Worker through Cloudflare’s domain and route settings. The content links keep their existing paths: cards stay under /cards/, and résumé references keep their fragments. Cloudflare Workers custom domains
The old agenda addresses are preserved as redirects. This means a build-system change does not need to become a broken bookmark for a reader. The practical benefit I want is simple: publishing can evolve while the useful connections remain.