A personal site on Cloudflare Workers with no origin server, no framework, and no database in the traditional sense. KV for content, R2 for images, D1 for view counts, Workers AI for summaries and translations.
I've been running this setup for roughly a year. Here's what I'd tell myself at the start.
What Works Remarkably Well
Deploy time. Pushing to main and seeing changes live in 30 seconds is the right baseline. Not a 3-minute Docker build, not a 10-minute serverless cold-start provisioning cycle. The Worker deploys to 300+ edge locations simultaneously in under a minute.
Zero infrastructure maintenance. No server to patch, no certificates to renew, no database to tune, no disk space to monitor. Cloudflare handles all of it. I've had zero infrastructure incidents in a year.
Cost. The free tier covers everything for a personal site: 100,000 Worker requests per day, 10GB R2 storage, 5GB KV storage. I've never gotten a bill. If traffic spikes, the paid plan is $5/month for reasonable usage.
Reliability. Workers are stateless. A request in São Paulo and a request in Tokyo are independent. There's no shared mutable state that can corrupt, no connection pool that can exhaust, no memory leak that accumulates. Each request is fresh.
What Actually Hurts
Debugging is remote. You can't attach a debugger to a production Worker. You have console.log (which streams to wrangler tail), error pages, and inference from behavior. Reproducing bugs locally sometimes requires recreating KV state, which is tedious.
wrangler dev helps but doesn't perfectly replicate the production environment. Some behaviors — particularly around KV consistency and AI binding latency — only manifest in production.
KV is eventually consistent. After a KV write, a read at a different edge location might return the old value for seconds or minutes. For post content, this means a newly published post might not appear immediately for all visitors globally.
In practice, I've never had a user notice. But building features that depend on KV reads immediately reflecting KV writes (like a real-time counter) would be unreliable.
The 1MB script limit requires discipline. Adding a large dependency — a syntax highlighter, a Markdown parser, a date library — can push you past the limit. I've written workarounds (custom tokenizer, hand-rolled utilities) that I wouldn't need on a traditional server.
marked (the Markdown parser) is the largest dependency at ~50KB. Everything else is from scratch. This is sustainable but constraining.
Workers AI rate limits surprise you at the wrong moment. Running tests that hit several AI endpoints in quick succession, or publishing multiple posts at once, can exhaust the free-tier rate limit. The error is silent (caught by try/catch) and the feature just doesn't work. Diagnosing it takes time.
What I'd Do Differently
Pre-generate AI summaries at publish time. Currently the first visitor of each post pays the 1-2 second BART latency. The publish script should run BART for every post and seed the KV cache. This is a 20-line addition to the publish script that I keep not writing.
Use Hono for routing. The manual if (path === "/blog") routing in the Worker function works but doesn't scale to many routes. Hono is a Workers-first router at 14KB — small enough to stay under the script limit, typed, and well-tested. I'd reach for it on a new project.
Use a separate KV namespace for staging. The current setup shares KV between production and staging. It works because the data is safe to share, but it's conceptually messy. A staging namespace with production data seeded on demand would be cleaner.
Add structured logging from day one. Currently errors disappear silently into try/catch blocks. A lightweight error reporter (even just a logging KV write or an Analytics Engine data point for errors) would surface issues faster.
The Honest Assessment
The Workers platform is genuinely good for this use case. A personal site or blog benefits from the edge model: globally fast reads, zero maintenance, trivial cost.
The constraints — script size, KV consistency, remote debugging — become relevant when you push beyond simple content delivery. If I were building a multi-user application with complex state, I'd reach for a more traditional backend.
For a blog that renders Markdown, serves images, and counts views: Workers is exactly the right tool. The constraints I hit were the ones I looked for. The ones I didn't look for, I haven't found yet.