Vishal Tyagi
← Writing
·blog

Shared hosting is a product constraint, not an insult

You don't always get systemd. Here's how to still ship queues, webhook deploys, and integrity checks — and when to stop pretending shared hosting is fine.

Engineers love to sneer at shared hosting. Then a school, NGO, or small business hands you cPanel and a deadline.

The useful move is not “rewrite on Fly.io.” It’s asking: what does this host actually allow? Often: PHP, MySQL, cron, sometimes Node, rarely Docker/systemd.

That constraint set still supports a serious ops story:

  • Queues — Node babysits queue:work (codelab)
  • Deploys — GitHub webhook → queued git pull + migrate (research)
  • Integrity — hash a critical file on boot and alert elsewhere (codelab)

I shipped that trio for a government school CMS. It is not blue-green multi-region magic. It is automatic deploys, background jobs, and a tamper signal — on hardware the client already paid for.

Know the exit criteria too: concurrent deploys need a single worker; failed migrations after pull are manual; TLS on alert webhooks is non-negotiable. When zero-downtime and multi-server show up as real requirements, graduate the host.

Constraints are design input. Sneering is not.