Cloudflare’s edge is the most fun deployment target I’ve used in years. It’s also the most opinionated, and that opinion shapes how you architect.
The constraint that defines everything
The edge runtime is not Node. It’s a V8 isolate with the WinterCG API surface plus Cloudflare’s additions. No fs, no child_process, no native modules. Most npm packages that work on edge declare it explicitly; the ones that don’t often crash at request time.
My rule of thumb: if a dependency was written for Node, assume it doesn’t work on edge until proven otherwise.
Tiny app, big checklist
A new edge app worth deploying needs:
- A storage layer (D1 for relational, KV for cache, R2 for files)
- An auth strategy that doesn’t depend on Node crypto (bcryptjs, Web Crypto API, signed JWTs)
- A build pipeline that knows about the edge target (next-on-pages, sst, or wrangler directly)
- A clear story for secrets (wrangler.toml + dashboard, no .env)
None of these are hard individually. Together they add a week of plumbing before you ship the first feature.
D1 is more useful than it looks
D1 has rough edges — read replication is eventually consistent, transactions are limited — but for the apps I build (mostly read-heavy, tens to hundreds of writes per minute), it’s ideal. The schema lives in migrations, the queries are SQL, and the deploy is one wrangler command.
The thing I had to internalize: don’t treat D1 like Postgres. Avoid n+1 queries (the latency penalty hurts more than on a local DB), prefer materialized aggregates over runtime joins, and use the prepared-statement API.
Where I keep stumbling
Mostly it’s libraries. Image processing, PDF generation, anything that wants Buffer — these need replacements. @react-pdf/renderer works on edge (it’s pure JS); puppeteer does not. Worth checking before you commit.
The payoff: low latency everywhere, deploys in seconds, and a per-request cost that rounds to zero for most personal projects.