DEV Community

Bryan Hamilton
Bryan Hamilton

Posted on Edited on Originally published at bryanhamilton.info

The deploy pattern that keeps my 1,000-page site alive without shell access

I run The DJ Calendar (https://thedjcalendar.com) — about 1,000 pages of PHP/MySQL on shared cPanel hosting. No shell. No SSH. No deploy pipeline. LiteSpeed caches HTML for 5 minutes, and opcache serves stale output for a minute after every write.

Pasting a code change into a production file through a browser file manager is how sites die. So over months of live deploys, I built a worker pattern that makes that kind of deploy survivable. I just open-sourced it: guarded-deploy-workers (https://github.com/bryanhamiltondev/guarded-deploy-workers).

How a deploy works

A "worker" is a single PHP file I upload to the web root. I hit its URL once with a secret token. It:

  1. 404s unless the token matches — and renders the site's real 404 page, so the worker's existence never leaks
  2. Checks an idempotency marker — an already-patched file aborts, so double-patching is impossible
  3. Counts every needle string — if an anchor doesn't appear exactly the expected number of times, nothing is written
  4. Backs up before writing, and restores automatically if post-write verification fails
  5. Verifies the patch, not the intent — the replacements must land byte-exact or it rolls back
  6. Deletes itself after reporting

The pattern wraps what would otherwise be an open-heart surgery in a browser tab.

The bugs that taught me the most

The class is ~100 lines. The real value is the checklist of failure modes, all earned live:

  • A verifier that checked for an unchanged file length when the patch legitimately removed 2 bytes. It restored a correct patch. My own safety check fired on a good deploy.
  • A needle string that appeared twice in the file. The patch landed in both places. Now every needle is counted, not assumed.
  • opcache serving the old file long after the disk was correct — the default explanation for "the patch didn't work" on shared hosting, and the reason live verification always cache-busts.
  • Uppercase characters in a preg_replace lowercase filter — the string shredder that ate a slug. Always lowercase before the character-class filter.

The full list is an 18-rule pre-flight checklist (https://github.com/bryanhamiltondev/guarded-deploy-workers/blob/main/docs/checklist.md) in the repo.

When not to use this

If you have a real deployment pipeline, use it. This pattern is for the world a lot of us actually live in: a cPanel box, FTP credentials, a production site that pays the bills, and no infrastructure team coming to save you.

Your turn

What's your survivability trick on locked-down hosting? I'm genuinely curious — the comments are open, and so is the repo: github.com/bryanhamiltondev/guarded-deploy-workers (https://github.com/bryanhamiltondev/guarded-deploy-workers) (MIT).

Top comments (0)