Building Jekyll for Cloudflare Workers
Build the site, derive the connections, check the result, then publish the static files through a Worker. Each step has a clear job.
What goes into the build
The source directory holds the homepage, résumé, reading pages and a collection of connected cards. Shared layouts and includes provide the page shell and navigation. The Ruby version and gem dependencies are pinned so the local build and hosting build can use the same toolchain.
The command behind the build script is:
bundle exec jekyll build --source www --destination _site
The script then runs a link validator. Broken local destinations or résumé fragments cause it to fail. A complete build is required because changing one note can change incoming links on other notes.
Give plugins specific jobs
jekyll-seo-tag supplies page descriptions, canonical URLs, social metadata and structured data. jekyll-sitemap creates an inventory of canonical pages. Neither is a guarantee of search placement; they make the published content easier to identify and discover.
A small local plugin handles this site’s particular relationship model: explained links and ordinary mentions. It works during the build, leaving readable HTML behind. The person metadata names me, Reza Rosli.
Check the output before publishing
The checks cover relationship targets, duplicate links, missing assets, page fragments and the preservation of public addresses. I also look at the rendered pages on desktop and mobile: a successful build does not by itself tell me whether a page is comfortable to read.
The benefit is a workflow I can inspect with my AI agents. Content, templates and tests remain visible in the repository. The Cloudflare-side guide describes how Workers deploys the checked _site directory as Static Assets and connects it to a domain. This page describes the build configuration, not a record of a completed deployment.