The stack behind SentinelGrid: no servers, on purpose

Every SentinelGrid service (the helpdesk, the uptime monitor, the CRM behind this site's forms, our email handling, this blog) runs on Cloudflare Workers. There is no server anywhere in the company. This is the most consequential technical decision we've made, so it's worth explaining.

The math for a small studio

A traditional stack means a VPS, which means an OS to patch, a reverse proxy to configure, certificates to renew, a disk that fills up, and a machine that goes down at 2am: the exact operational burden we sell our clients relief from. It would be a strange look to drown in it ourselves.

The Workers model replaces all of it: code deploys to Cloudflare's edge, scales to zero, and costs close to nothing at our size. But the real win isn't the bill. It's that maintenance stops being a tax on every service we've ever shipped. A worker we deployed six months ago is exactly as healthy today, untouched. That's what lets a small team run a helpdesk, a monitoring platform, a CRM, an email pipeline, and a fleet of client sites without a full-time ops person.

The parts

• Workers for compute: every API, cron job, and scheduled check.
• D1 (SQLite at the edge) for data: tickets, monitors, incidents, clients. Real SQL, no connection pools, no database server.
• KV for the simple stuff: inbound email storage, settings, caches.
• Email Workers to receive mail. Inbound support email becomes a ticket without an IMAP poller pretending to be reliable.
• Pages for static sites like this one, pushed to git, deployed globally, cached hard.

The constraints are features

Serverless platforms make you design inside limits, and the limits are usually good taste in disguise. Workers cap subrequests per invocation, so our incident notifications send one bcc'd email to all watchers instead of a naive per-watcher loop. That's not a workaround; it's the design a considerate system should have had anyway. No long-running processes means every job must be resumable and idempotent, which is how background jobs should be written everywhere, enforced here by physics.

Honest downsides

D1 is young, and remote queries occasionally return transient errors that succeed on retry, so retries are built in, not bolted on. Local development against edge services takes tooling (wrangler is good, not magic). Vendor lock-in is real, and we accept it with eyes open: the data is SQL and exportable, which is the part that matters.

If you're a small team

You probably don't need the VPS. The boring, disappearing infrastructure is the point. It's why a studio our size can offer managed IT with real monitoring and a real helpdesk behind it, and spend our hours on the work instead of the plumbing.