You’ve probably noticed that building a globally distributed app feels like a punishment. You start with a simple idea, and before you know it, you’re juggling a stateless serverless function, a managed database, a CDN, and a dozen config files that all have to talk to each other. The promise of serverless was freedom from infrastructure. The reality? You traded one kind of complexity for another.
I spent four years at Fly.io helping build that vision. I wrote about the ‘Serverless Server’ – a way to make serverless feel like a real server. But I kept hitting a wall. The wall was state. How do you give a serverless function a database that’s fast, local, and globally replicated without turning it into a PhD thesis in distributed systems?
Then I built Kedge. And I think I cracked it.
Here’s the twist nobody’s talking about: The future of cloud computing isn’t more complex distributed systems. It’s a return to simple, local-first architectures that just happen to be globally replicated by the platform underneath. Think CGI scripts and SQLite, but with a magic layer that makes them work everywhere.
Kedge is a globally distributed platform for stateful serverless apps. The key insight is ridiculous in its simplicity: use forkable VM snapshots that can create code sandboxes in 3 milliseconds. A tree of warm pools – Linux kernel, base runtime, your app – means your code is ready to run anywhere, instantly. Shared memory via copy-on-write means you can pack hundreds of these VMs on a single machine without breaking a sweat.
But the real magic is the database. Instead of forcing you to choose between a fast local SQLite and a slow global database, Kedge gives you both. It uses an eventually-consistent, multi-writer CRDT-based replication system built on top of SQLite. Your app queries a local replica for low-latency reads, while the platform handles the messy global sync in the background. You don’t need to manage instance placement, volume replication, or any of that nonsense. It’s like having a globally distributed database that you never have to think about.
And the demo? I built a full Hacker News clone – story submission, votes, comments, auth – in about 60 lines of Markdown plus CSS. That’s it. Data attributes bind forms and buttons directly to records in the database. The schema is compiled at deploy time. The app is stateful, server-rendered, and runs in 11 regions. Sixty lines of Markdown for a globally distributed app. If that doesn’t make you rethink everything you know about cloud development, I don’t know what will.
This isn’t just a tool. It’s a statement. We’ve been told that building for the edge means embracing complexity. That you need Kubernetes, or a distributed database, or a whole team of SREs. Kedge says: no. You need a developer experience that doesn’t suck. You need to write code, not orchestrate infrastructure. You need to feel empowered, not overwhelmed.
Is it production-ready? Not yet. It’s a preview, and there’s no billing. But the philosophy is solid. The architecture is open source (the replication layer is on GitHub). And the feedback so far has been electric. People are excited because this is what serverless should have been from the start.
So here’s my bet: The next wave of cloud computing won’t be about more complex systems. It will be about removing the complexity that we’ve been told is inevitable. Kedge is a bet that simplicity wins. And I’m all in.
FAQ
Q: Isn't eventual consistency a dealbreaker for many apps?
A: It depends on your use case. If you need strict ACID transactions across the globe, you're probably not reading this. But for most modern web apps – social feeds, collaborative tools, e-commerce – eventual consistency is perfectly fine. Kedge gives you fast local reads and handles the sync in the background. The trade-off is worth it for the simplicity.
Q: How does Kedge compare to something like Fly.io or Cloudflare Workers?
A: Kedge is closer to Fly.io in spirit, but with a key difference: it's built from the ground up for stateful serverless. Fly.io uses VMs too, but you still need to manage your own database placement. Kedge gives you a built-in replicated SQLite that's local to each instance. No external database needed. Cloudflare Workers are stateless – you have to bring your own state via Durable Objects or KV. Kedge's approach is simpler and more familiar for many developers.
Q: Is this just a toy for demos, or can it handle real traffic?
A: The preview is running in 11 regions and has been designed for production use. The orchestration layer is fast – 3ms VM creation – and the replication system is built on battle-tested CRDT techniques. The real question is how it scales under heavy write contention. That's part of what the preview is testing. The architecture is promising, but it's still early. I'd say it's worth trying for real projects, but keep an eye on the open-source replication layer for the gory details.