Why Cloudflare

Base is built for Cloudflare Workers, and that is a choice, not a default we backed into. A framework's runtime shapes everything above it: how you deploy, how you scale, what your data layer can be, where your code runs relative to your users. We picked the edge because it is the model we want for the applications we build, and we built Base to make that model easy.

The edge is where applications should live

A traditional backend runs in a region. You pick a data center, your servers sit there, and a request from the other side of the world pays the round trip. You provision capacity for your busiest moment and pay for it during your quietest. Scaling is your job, and so is the machine that is idle at 3 a.m.

Cloudflare Workers invert that. Your code runs at the edge, in the location closest to whoever is calling it, on infrastructure that is already there. There is no server to provision, no region to pick, no idle box to pay for. The platform scales the work and bills you for what actually runs. For the kind of application that answers requests from everywhere, that is the right shape, and it is hard to get any other way without building it yourself.

Cloudflare is a platform, not just a runtime

If Workers were only a place to run code, the story would be smaller. What makes Cloudflare compelling is that the surrounding platform gives you the pieces a real application needs, all living at the same edge as your code: a SQLite database in D1, key-value storage in KV, object storage in R2, message queues, scheduled triggers, Durable Objects for coordinated state, Containers for heavier workloads, and websockets for live connections.

That breadth is exactly why Base leans in. Base does not just run on Workers; it gives you a first-class way to use the whole platform. The ORM ships an adapter for D1 so SQLite-at-the-edge is a connection in your settings, not an integration project. Queues, scheduled workers, KV, object storage, Durable Objects, and websockets each have a home in Base's settings and its decorator vocabulary. The platform offers the primitives; Base makes them feel like parts of one framework rather than services you wire together by hand.

The fit between Base and the edge

The edge runtime has real constraints. Workers start fast and stay light, so a framework meant for them has to start fast and stay light too. That constraint shaped Base. The pieces you do not use are optional and absent, so a worker carries only what it declares. The data layer defaults to Drizzle, which is lightweight and fully typed and a strong match for Workers, with adapters for the databases that belong at the edge. The result is a framework that fits its runtime instead of fighting it.

This is the same idea as the rest of Base, seen from the infrastructure side. Base hands you the pieces already fitted together, and on Cloudflare the pieces include the platform itself. You write your worker, you name the platform features you want in your settings, and you deploy to an edge that scales and bills around your actual traffic.

Why it matters for you

Choosing Cloudflare is choosing to spend your attention on your product instead of your infrastructure. No servers to run, no regions to balance, no scaling code to maintain, and a platform whose storage and compute primitives are already at the edge where Base puts your logic. Base exists to make that whole picture coherent: one framework, one settings object, one deploy, running close to your users on infrastructure you never have to babysit.