The Cloudflare-Only Bet: What an All-Workers Platform Gains and Gives Up
Piskes runs as 17 apps and roughly 41 Workers on one runtime, by deliberate choice — here's what that buys you and what it rules out.
Most "why we chose X infrastructure" posts are written after the fact, to justify a decision that's already load-bearing and can't easily be reversed. This one is more useful read the other way: Piskes runs entirely on Cloudflare — 17 Next.js apps and roughly 41 Workers, all sharing one D1 database — because that was set as a constraint up front, not discovered as a limitation later. It's worth being precise about what that constraint actually gets you, and what it costs, because both halves are real.
The decision, stated plainly
There is no server fleet behind Piskes. No Kubernetes cluster, no Helm charts, no VMs to patch at 2am. Every app is a Cloudflare Worker with its own wrangler.toml; every backend service is a Worker too. The one piece of the system that isn't Cloudflare-native — a Go REST API — is deliberately being narrowed over time, not expanded; new functionality goes onto Workers, not onto a new Go service. That's a constraint the team set for itself: ship fast, no VPS, no new Go, all Cloudflare. It wasn't backed into.
What you get
One deploy model. Every one of the 17 apps and ~41 Workers deploys the same way — wrangler deploy --env production, from its own directory, with its own wrangler.toml. There's no app that deploys differently because it happens to run on a different substrate. That uniformity is what makes it realistic to hold every one of those services to the same operational bar.
One guardrail set. Because everything runs on the same runtime, the same pre-commit and pre-push checks apply everywhere — tenancy guards on by-id routes, audit-log coverage on delete routes, runtime-import checks that catch code that would work under Node but break under workerd. A platform that mixed runtimes would need a different rule set per runtime, and rule sets that only apply to some of the codebase are the ones that quietly stop being enforced.
Global edge placement by default. A Worker runs close to the request without anyone choosing a region for it. For most of what these apps do — serving pages, handling API calls, running short-lived agent tool calls — that's a real latency win, and it comes for free rather than as a scaling project someone has to build.
No fleet to operate. There's no patching cadence, no capacity planning for a VM pool, no "which servers still have the old build" class of bug. Scaling is Cloudflare's problem, not an on-call rotation's.
What it costs
No on-premises option. If a prospective customer's security policy requires software to run inside their own network boundary, Piskes cannot offer that today. That's not a roadmap gap being worked on quietly — it's the direct consequence of building entirely on a shared multi-tenant edge platform. A vendor architecture built this way and an on-prem deployment story are close to mutually exclusive; you don't back into the second one from the first without a substantially different product.
No region pinning. Some customers — often for regulatory or data-residency reasons — need to say "our data lives in the EU" or "our data never leaves Vietnam" and have that be a verifiable, contractual fact. Checking every wrangler.toml in this repo for a location hint or jurisdiction setting turns up nothing, because that capability doesn't exist yet. Workers and D1 don't give you the same first-class regional pinning primitives that, say, a managed Postgres deployment on a specific cloud region does. If a deal requires data residency as a hard requirement, that's a real gap today, not a formality.
Dependency on one vendor's platform primitives. Choosing Workers, D1, R2, and Durable Objects as the foundation means the architecture is written against Cloudflare's specific APIs, not a portable abstraction layer. Moving off Cloudflare later would mean rewriting the data layer, not swapping a config value. That's a real form of the same lock-in conversation that comes up when evaluating any vendor's stack — and it's worth naming rather than waving away, especially given how much attention vendor lock-in is getting from enterprise buyers right now. Recent surveys put the number of IT leaders confident they could switch a primary vendor without material disruption in the single digits — which is exactly the number that should make any vendor's own infrastructure choices worth asking about, including this one.
Why this trade was made deliberately, not accidentally
The honest version of this story isn't "we evaluated every infrastructure option and Cloudflare won on every axis." It's narrower: for a team building 17 apps and dozens of backend services with a small team, one runtime, one deploy tool, and one enforced rule set was judged more valuable than the flexibility multi-cloud or on-prem support would have bought — enough that it was written down as a constraint rather than left as an assumption someone might quietly violate under deadline pressure.
That trade won't be right for every buyer. A regulated customer that needs region-pinned data residency, or an enterprise that requires an on-prem deployment as a condition of the contract, should know now — not discover it during procurement — that neither is on the table today. For everyone else, the same choice that rules those two things out is also what makes it realistic to hold 17 apps and 41 Workers to one consistent operational standard instead of 17 different ones.
What would change this
Region pinning is more plausible to add later than an on-prem mode is — it's a matter of Cloudflare's own primitives maturing and the platform adopting them, not a different architecture. An on-prem deployment story would be a genuinely different product, not an incremental addition to this one. Neither is being promised on a timeline here; both are worth asking about directly if either is a hard requirement for your evaluation, rather than assuming either is coming.