Build a pull-based deploy pipeline for a site on shared hosting

Ercan Atay runs an Astro static site in 26 languages on a shared cPanel account with no Node and a 1 GB quota. Deploys ran by rsync from his laptop, which had to stay awake and often lost the SSH connection. He wanted the server to fetch its own updates, with no public copy of the site anywhere and the SSH password never leaving the laptop. A Claude Code session first wrote a design document with routes, tokens, phases and done criteria. A cloud session then wrote the code on a branch: a three-job GitHub Actions build with build gates and a signed file manifest, a Cloudflare Worker with KV records sitting between GitHub and the server, and a server cron that checks every five minutes, verifies the build, installs it, smoke tests it and rolls back on error. A second, local session reviewed it with two parallel sub-agents and checked claims against the live server. Claude Code also set up the KV store, the Worker, the cron, the purge token and the GitHub secrets through the APIs.

Review went three rounds, with 15 findings in the first, 6 in the second and 5 in the third. Fixes included splitting the build so npm code never runs in a job with write access, pinning a third-party action to a commit hash, and giving each KV writer its own key after a single shared key lost install records. The first automatic install after a push took 21 seconds and wrote 194 of 902 files. New Medium posts reach the site within 25 minutes while the laptop is asleep. Extra cost is $0 on free Cloudflare and GitHub plans.

Several facts the pipeline depends on, such as localhost not working on the host and Cloudflare Bot Fight Mode blocking the server's requests, were not documented anywhere and had to be measured on the server. Free-plan limits (1,000 KV writes a day, 10 ms CPU per Worker call) shaped the design. The author's view is that having a separate session review the code is what caught the errors.