Kedge, a platform for running stateful serverless applications across multiple global regions, launched on Hacker News as a Show HN post by its creator, who previously spent four years helping build Fly.io. The platform pairs forkable VM snapshots (think of them as pre-loaded templates that can be instantly cloned) with copy-on-write memory sharing, and runs its global coordination layer on an eventually-consistent SQLite database. Users are billed per second on actual resource consumption, not on pre-allocated capacity. kedge.dev

At the core of Kedge's architecture is a VM orchestrator that can spin up code sandboxes or scale service instances in 3 milliseconds. It does this by keeping a tree of warm pools — pre-started virtual machines held in reserve — and forking snapshots from them on demand. Those VMs share memory pages using a copy-on-write technique, meaning a page of memory is only duplicated when one instance actually modifies it, which keeps memory usage low across many similar instances. The global control plane runs on an eventually-consistent SQLite database, an unusual choice for a distributed systems control plane; most platforms in this category rely on consensus-based stores like etcd or Consul, which use agreement protocols to keep nodes in sync.

Kedge exposes statefulness through two built-in tools: a replicated SQLite database queryable from any instance via /shared.db, and a /shared/ filesystem adapter. Both are powered by syzy, an open-sourced local-first replication system that uses CRDTs (Conflict-free Replicated Data Types — data structures designed so that concurrent edits from multiple writers can be merged automatically without conflicts), backed by object storage. It is available at github.com/wjordan/syzy. The creator cited the essay "The Serverless Server" on Fly.io's engineering blog as the conceptual inspiration for the platform.

Beyond raw compute orchestration, Kedge supports server-rendered HTML applications where data attributes bind forms, buttons, and values to records in the app database. A Hacker News clone demo, complete with story submission, votes, comments, and authentication, was built in roughly 60 lines of Markdown plus CSS and is documented at kedge.dev/docs/html-apps#kedger-news. The platform also supports static sites, serverless functions, full-stack apps, and databases deployed close to users. kedge.dev

Kedge's billing model is granular. Users are billed per second on actual resources consumed rather than allocated capacity: CPU charges apply only for scheduled milliseconds, memory tracks active resident pages, and storage bills only for bytes used. Listed rates are $15 per vCPU-month, $5 per GB-month for memory, $0.05 per GB-month for storage, and $0.01 per GB for egress. Idle apps scale to zero and pay only for storage. The platform uses a credits-based billing system with a $5/month free tier. Users can log in via GitHub OAuth or by running ssh kedge.dev from a terminal. kedge.dev

At the time of the Show HN launch, Kedge's preview ran in 11 regions with no billing system yet implemented; the pricing page was described as an estimate. The current kedge.dev site, dated July 29, 2026, now lists concrete rates and the credits-based free tier, suggesting the billing infrastructure has matured since the initial launch. Hacker News kedge.dev

The broader context here is how Kedge's architectural choices compare to the prevailing serverless paradigm. Most serverless platforms optimize for stateless request handling — each request is processed independently, and any data that needs to persist is offloaded to a separate managed database or object storage. Kedge inverts that assumption: statefulness is built in as a first-class feature, replicated across regions via CRDTs, and accessible through a familiar SQLite interface rather than a proprietary SDK. The 3-millisecond VM spin-up time, if it holds under production load, narrows the cold-start gap that has been a persistent pain point for serverless since AWS Lambda popularized the model.

The choice of SQLite as both the control plane substrate and the user-facing database is also notable. SQLite has been steadily moving from embedded-only use cases into distributed and server contexts, driven by improvements in WAL (Write-Ahead Logging) mode, litestream-style streaming replication, and now CRDT-based multi-writer replication as exemplified by syzy. Kedge is betting that an eventually-consistent SQLite layer is sufficient for a global control plane, sidestepping the operational complexity of consensus-based systems. Whether that bet pays off at scale, particularly under network partition scenarios where nodes temporarily lose contact with each other, is an open question.

The copy-on-write memory sharing approach has precedent in systems like Firecracker's microVM snapshotting and Crosvm, though Kedge's combination of forkable snapshots with a tree of warm pools is its own formulation. The memory density gains from shared pages matter most for workloads with many small, similar instances, which aligns with the platform's target use case of fine-grained serverless functions and per-instance state.

In this author's view, Kedge's most interesting contribution is not any single component but the composition: a globally replicated SQLite database, server-rendered HTML bindings, sub-10ms instance creation, and per-second billing on actual usage, all presented as a unified platform. The 60-line Hacker News clone is a legitimate demonstration of how much boilerplate a tight integration between rendering, data, and deployment can eliminate. The unresolved question is whether an eventually-consistent SQLite control plane and CRDT-based replication can handle the consistency demands of production workloads at scale. For now, the platform is early, the billing model is freshly concrete, and the architecture choices are clear enough to evaluate on their merits.