Where Cloudflare fits — and where teams hit the wall
Where Cloudflare fits well: products that genuinely need global low latency or edge-scale request handling, and teams happy to shape their code to the Workers runtime and its limits.
Where teams outgrow Cloudflare: when the app spreads across Workers, Pages, D1, R2, KV, Queues, and Vectorize — each a separate product with its own bindings and console — until nobody can draw the whole system on one page.
Many excellent products, one app to assemble
Cloudflare has spent a decade turning network pieces into developer products, and most of them are good. The cost is assembly: your application becomes the sum of its bindings, spread across products that were designed to be sold separately and behave that way in the console.
Each product also brings its own limits and mental model. Compute thinks in isolates and CPU time, data thinks in whichever of D1, KV, or R2 fits least badly, and the reviewer of a change has to know which console each behaviour lives in.
One zone, on purpose
KERNSTACK makes the opposite trade. A project runs whole in one European zone on our bare metal: functions for request-shaped work, container workers — real processes, not isolates — for everything longer, tables and buckets for data, and indexes declared over both.
- Long work runs as a worker process instead of being reshaped to fit an edge runtime
- Every resource is in the same stack.json, so one diff shows the whole change
- Users outside Europe get a longer network path — that is the honest price of one zone
Side-by-Side: Cloudflare vs KERNSTACK
| Dimension | Cloudflare | KERNSTACK (Software Lifecycle Cloud) |
|---|---|---|
| Where code runs | Hundreds of edge locations worldwide | One European zone per project, on our bare metal |
| Compute model | Workers isolates with runtime and CPU limits | Functions for handlers, container workers for long processes |
| Data | D1, KV, R2, and Vectorize as separate products | Tables, buckets, and search indexes in one project graph |
| Unit of change | Bindings and configuration per product | One stack.json, one plan diff |
| Agents | External tooling with account keys | Agents draft in sandboxes; people approve the plan |
| Bill | Per-product pricing across the developer platform | One credit balance for the whole project |
Frequently asked questions
Some will: a project in one European zone cannot beat an edge network on raw distance to a user in another continent. If global latency is your product, Cloudflare is the right tool. If your users and your data obligations are European, one zone is the simpler and more defensible shape.
Handlers become functions, long-running code becomes container workers, D1 or KV records land in key-value tables, and R2 objects land in buckets. Vectorize use becomes a vector index declared over those tables and buckets. Each move is an export and a re-declaration; nothing is imported automatically.
You lose the global edge network — that is real, and it is the trade. KERNSTACK gateway routes can mark a prefix CDN-enabled for delivery, but the platform claim is different: one declared project in one zone, not a planetary network.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.