Cloudflare launched K2 in public beta, a serverless event-streaming service that stores a durable log on R2 instead of running a Kafka cluster

Cloudflare opened a public beta of K2 today, a serverless event-streaming service on its Developer Platform. Producers send events to a stream and consumers read them in order, either by splitting work across a consumer pool or by giving each consumer its own subscription. The service runs on Workers Paid accounts.

K2 solves the same problem a Kafka deployment usually solves: a durable buffer that lets producers and consumers scale on their own, so a slow consumer or an outage does not drop events. Cloudflare says it built K2 because its own Basin Pipelines needed a durable buffer at the edge, where running a traditional Kafka cluster across 335 cities does not fit how its servers work: small slices of each machine, machines that come and go, and networking over the public internet.

How K2 stores a log on object storage

K2 implements a partitioned, durable log on top of R2 object storage. R2 does not support append operations, so the service accumulates writes in memory on an edge server, then writes each batch as a segment file. Ordering and strictly incrementing offsets come from R2's atomic operations, without a separate coordination service.

Cloudflare lists the trade this design makes. Writes to R2 are slower than writes to a local disk, and the service waits for a batch to accumulate before starting the write. On the initial release, Cloudflare puts the result at one second of produce latency at the 99th percentile of response times. In exchange, Cloudflare gets R2's 11-nines durability and separates compute from storage, so each can scale on its own.

Beta limits and planned pricing

K2 is available to accounts with a Workers Paid subscription. During the beta the limits are 10 GB of storage per stream and 30 MB per second of produce throughput, with a form for teams that need higher limits. Usage is free during the beta.

Once billing begins, Cloudflare anticipates charging four cents per gigabyte produced, four cents per gigabyte consumed, and two cents per gigabyte retained per month. These are Cloudflare's own stated prices for the end of beta; a team should check them against the live docs before putting them in a budget.

Streams, queues or pipelines

The post names two existing Cloudflare primitives K2 overlaps with. Cloudflare Queues are built around tracking individual items of expensive work, with per-item retries, delays and dead-letter handling. K2 is built around high-scale data movement, long-term retention and fan-out consumption, where messages travel in batches and the batching raises producer latency. Basin Pipelines is for ingesting events and writing them to R2 or Iceberg tables; K2 is for custom processing or writing to other places.

A team running Kafka today for buffering has a managed option that charges only for what it stores and moves. The gap is write-side: beta throughput caps at 30 MB per second per stream and produce latency sits at one second at the 99th percentile. The roadmap Cloudflare published names higher write parallelism, message keys with key-based ordering, push-based worker consumers, a lower-latency tier, and drop-in support for Apache Kafka clients. Nothing on that roadmap has a date, so a team weighing a migration should read the beta limits as the current product.

Source

• Primary source: Cloudflare: Announcing Cloudflare K2, serverless event streams, 1 October 2026