PuppyIP Resource Center
Developer Tools & Networking 8 min Published 2026-10-02

Cloudflare K2 public beta: event replay, duplicate delivery, and Kafka boundaries

K2 is a durable event log with retention and replay, in public beta for Workers Paid. Multiple independent subscriptions can read the same stream, but it is not a ready-made Kafka replacement requiring no code changes, nor does it guarantee a business action happens only once. Design retention, idempotent processing, and acknowledgment timing before integration.

Cloudflare K2 Event streams Kafka Message delivery

Service eligibility and regional restrictions

PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.

Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.

Key Takeaways

  • The October 1, 2026 announcement confirms public beta; Workers Free is ineligible. K2 usage is unbilled during beta, but Workers Paid and other service charges remain.
  • The initial storage limit is 10 GB across all streams in an account, with up to 20 streams. The announcement lists a produce limit of 30 MB/s per stream.
  • Records default to seven-day retention, configurable from one hour to 30 days. Reads track position through subscriptions, which are independent of each other.
  • Consumption uses at-least-once delivery. A batch lease lasts five minutes: ack after successful processing, or nack on failure. produce retries can also write duplicate records.
  • Direct Kafka-client compatibility, push-based Worker consumers, Express tier, and key-based ordering are all future roadmap items, not currently released capabilities.

Distinguish a durable log from a one-off task queue

Cloudflare introduced K2 in its October 1 announcement for event processing that needs retention, replay, and multiple independent consumers. The product documentation defines it as a durable ordered log: producers append records, and consumers read and acknowledge their own progress through subscriptions.

For example, order events may feed risk controls, analytics, and fulfillment separately. Independent subscriptions read the same stream at their own pace, without records being deleted because another subscription read them. Choose K2 or Queues based on retention, replay, consumer model, and failure handling. Do not treat K2 as a renamed ordinary work queue or migrate a production pipeline without validation.

Separate eligibility, beta charges, and future pricing

The official getting-started guide requires Workers Paid and explicitly excludes Workers Free. The announcement says K2 usage is free during beta but gives no beta end date. This does not remove the subscription requirement or charges for Workers calling it or other services. This article has not verified account activation or actual billing.

The announcement gives anticipated pricing of $0.04/GB produced, $0.04/GB consumed, and $0.02/GB/month retained, explicitly using the phrase anticipated pricing. These are future expectations, not rates currently being charged. Recheck official prices and the effective date before billing begins, rather than promising fixed long-term costs.

Retention and limits determine how much history can be replayed

The current limits documentation sets a beta maximum of 10 GB across all streams per account and up to 20 streams. Retention ranges from one hour to 30 days, defaulting to seven days. The announcement also lists an initial produce limit of 30 MB/s per stream. The 10 GB limit is account-wide, not 10 GB for each stream. Request higher limits through the official process; do not assume an increase has already been granted.

A produce request allows up to 5 MB, and a single record approximately 1 MB. One consume call allows up to 10000 records and a response of up to 10 MB. Each stream supports up to 100 subscriptions, and each subscription up to 128 active leases. Estimate write volume, retention days, and consumer lag first. Data beyond retention is not a permanent backup; critical workloads need a separate, explicit archival policy.

At-least-once delivery requires application idempotency; ack is not automatic deduplication

The getting-started documentation says consumers hold a five-minute lease after receiving a batch. ack advances the subscription position after processing completes; a batch not acknowledged within its lease is redelivered. On failure, nack releases the lease without advancing position. If a response is lost, consuming again with the same worker_id can retrieve the original batch and refresh its lease. Receiving an event again is not grounds for creating another order or charging again.

produce batch writes are atomic, but K2 does not deduplicate production requests. Official guidance says to retry only when error.retryable is true, and retries may still store a duplicate batch. Stable business event IDs and checking idempotency before irreversible side effects are the application's responsibility. Do not ack before the business action succeeds or claim K2 guarantees exactly-once behavior.

Follow the official isolated test path and explicitly enable write authentication

The guide proceeds as follows: prepare the account ID and required K2 Config Write, K2 Produce, and K2 Consume permissions; create a test stream; send a small number of base64-encoded nonsensitive records to /produce; create a subscription starting at earliest; inspect /consume results; and /ack only after processing. A separate subscription can verify independent read positions. latest skips records already present when the subscription is created, so it cannot verify the historical sample just sent. This article has not created account tokens or streams or sent records.

The official creation example sets http.enabled and http.authentication to true. Documentation explicitly warns that if authentication is omitted, someone who knows the endpoint URL may be able to produce records directly. Explicitly enable authentication even in tests, and keep API tokens out of public pages and sample repositories. Use separate data to verify redelivery after nack and duplicate-event protection, record consumer progress, then decide whether to connect the application. Cleaning up a test stream deletes its records, so first confirm they need not be retained and follow official steps.

Kafka compatibility and lower latency remain roadmap items

The announcement puts greater write parallelism, message keys/key-based ordering, push-based Worker consumers, a low-latency Express tier, and Apache Kafka client drop-in support on the roadmap for the coming months. Do not point a Kafka client at K2 and claim current compatibility, or treat Express's target latency as a current SLA. The vendor-reported produce p99 of about one second is a measurement that this article has not independently repeated.

If integration fails, first check account eligibility, permissions, authentication, payload size, retention, and lease status, then consider network issues. Use the proxy connection troubleshooting checklist only with evidence such as TLS, connection timeouts, or proxy authentication errors. Network tools cannot increase account capacity, change delivery semantics, or provide unreleased Kafka compatibility. Update the same integration assessment when official pricing, limits, or compatibility features change.

Sources

Frequently Asked Questions

Can a free Workers account use K2?

The current official getting-started guide requires Workers Paid and excludes Workers Free. Free K2 usage during beta does not make the plan or other services free.

Is K2's 10 GB allowance per stream?

No. The current limits page specifies 10 GB across all streams per account during beta, with up to 20 streams per account.

Can K2 guarantee each order event is processed only once?

No. Consumption uses at-least-once delivery: expired leases or failures may cause redelivery, and produce retries may also duplicate writes. Applications need stable event IDs and idempotency protection.

How long is default retention, and do subscriptions take records away from each other?

Retention defaults to seven days and is configurable from one hour to 30 days. Independent subscriptions track their own progress. Another subscription's acknowledgment does not delete records, but retention limits still apply.

Can Kafka clients or Express tier be used directly now?

The announcement lists Kafka client drop-in support, Express tier, and push-based Worker consumers as roadmap items. This article has no evidence that they have launched.

Can anticipated future pricing be used as current billing rates?

No. The announcement says K2 usage is unbilled during beta. The $0.04/GB produced and consumed and $0.02/GB/month retained figures are anticipated pricing and must be rechecked before formal billing.