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:
- 404s unless the token matches — and renders the site's real 404 page, so the worker's existence never leaks
- Checks an idempotency marker — an already-patched file aborts, so double-patching is impossible
- Counts every needle string — if an anchor doesn't appear exactly the expected number of times, nothing is written
- Backs up before writing, and restores automatically if post-write verification fails
- Verifies the patch, not the intent — the replacements must land byte-exact or it rolls back
- 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)