cloudflare·Aug 3, 2026·3 min readCurated summary

Your agent needs a computer, not a container — introducing @cloudflare/computer

Cloudflare argues that scalable AI agents need their own computer-like environment—filesystem, shell, tools, and execution capabilities—rather than isolated access to ad hoc tools. Its early-preview `@cloudflare/computer` package abstracts across isolates, containers, and browsers while sharing a durable filesystem. The goal is to provide scalable, efficient compute for potentially hundreds of millions or billions of concurrent agents. ## Why Traditional Containers Do Not Scale - Coding agents work best when they can inspect files, run commands, install packages, modify code, and test their changes. - Giving every agent a dedicated container is too resource-intensive for large-scale deployments. - The industry is increasingly demanding CPU compute because agent workloads require substantial execution capacity in addition to GPU-based model inference. - Cloudflare believes agent infrastructure must move beyond conventional container-per-agent architectures. ## Isolates and On-Demand Containers - Cloudflare’s isolates start and stop quickly, scale horizontally, hibernate while idle, and can preserve agent state. - Durable Objects can host the agent loop and invoke containers only when heavier computation is necessary. - This architecture combines: - Isolates for lightweight, scalable coordination and file operations. - Containers for Linux environments, npm, native binaries, and other resource-intensive tasks. - Cloudflare wants to hide the complexity of combining these primitives from application developers. ## A Shared, Durable Filesystem - `@cloudflare/computer` gives each agent a declaratively initialized workspace containing the files and tools needed for its task. - Agents can select the most suitable execution environment: - Isolates for file manipulation, data processing, or Git operations. - Containers for commands requiring Linux, npm, or native binaries. - All environments operate on synchronized copies of the same source filesystem. - The filesystem can work with Git repositories, storage buckets, and arbitrary files. - File operations can be performed through Code Mode or Bash. - Operations are gated, audited, and observable, enabling fine-grained permissions and a record of agent activity. ## Using `@cloudflare/computer` - A workspace can be attached to any Durable Object to provide virtual filesystem and execution capabilities. - Installation uses: ```bash npm install @cloudflare/computer ``` - A `Workspace` is initialized with Durable Object storage and can be connected to an agent framework such as `@cloudflare/think`. - The example describes a bug-triage agent that: - Works in `/workspace/repo`. - Reproduces and investigates bugs. - Applies focused fixes when appropriate. - Runs verification commands. - Reports changes, commands, and verification results. - The package supports multiple execution backends, including Cloudflare Containers, and allows developers to implement custom backends. Cloudflare is presenting `@cloudflare/computer` as an open-source experiment and is seeking feedback from customers building agents at scale. Its practical recommendation is to use isolates as the default execution layer and attach containers only for tasks that genuinely require them, while sharing a controlled, durable workspace across both.

Read original(opens in new tab)

TypeScriptCloudflare WorkersDurable ObjectsIsolates+3

cloudflare·Aug 3, 2026·2 min readCurated summary

Workers RPC now works across Python and JavaScript

Workers RPC, originally based on Cap’n Proto RPC, is expanding from JavaScript-only communication to seamless JavaScript–Python interoperability through Cap’n Web. Workers can call methods, pass objects and functions, propagate exceptions, and use native language types without schemas, dependencies, or significant performance overhead. The result is a multi-language system that can be used much like a local library. ## Cross-Language RPC in Workers - JavaScript Workers can call Python Worker methods, and Python Workers can call TypeScript methods. - Objects, functions, streams, and live remote objects can be passed between Workers. - A Service binding is the only required configuration. - RPC calls return promises in JavaScript/TypeScript and futures in Python. - Exceptions propagate back to the call site. - Most calls run in the same thread, providing near-zero overhead compared with local execution. - The implementation is open source through `workerd` and `workers-runtime-sdk`. ## Automatic Type Conversion - RPC supports Structured Cloneable values as parameters and return values. - Common types are converted into native equivalents, such as JavaScript `Date` to Python `datetime`. - JavaScript objects can correspond to Python dictionaries, while Python keyword arguments can represent JavaScript options objects. - Functions can cross the language boundary; invoking a transferred function creates a reverse RPC call to its original Worker. ## Pyodide’s Role - Python Workers use Pyodide, a WebAssembly-compiled CPython runtime. - Pyodide’s Foreign Function Interface translates common values automatically: - Python `int` and `float` → JavaScript `Number` - Python `bool` → JavaScript `Boolean` - Python `dict` → JavaScript `Object` - Python `list` → JavaScript `Array` - Types that cannot be directly converted, such as custom classes and functions, are represented by proxies that forward property access and method calls. ## Handling Worker-Specific Objects - Standard Web API objects such as `Request`, `Response`, `Blob`, and `File` do not have direct Python equivalents. - Pyodide initially exposes these values as JavaScript proxy objects. - Although proxies remain functional, they expose JavaScript implementation details to Python developers and make the API less natural. - The project therefore requires an additional conversion layer to provide Python-friendly representations of Cloudflare Workers objects. ## Practical Implication Cross-language Workers RPC lets teams combine Python and JavaScript services without manually designing APIs or serialization formats. Developers can use each language’s native calling conventions while the runtime handles translation, proxies, and communication behind the scenes.

Read original(opens in new tab)

TypeScriptPythonJavaScriptCloudflare Workers+4

cloudflare·Aug 3, 2026·2 min readCurated summary

Cloudflare Workers and Containers now support inbound TCP connections and gRPC

Cloudflare is expanding Workers to support low-latency, TCP-based applications such as real-time voice AI and gRPC services. New inbound socket handling lets Workers route connections through Durable Objects and Containers, while Cloudflare also enables full-duplex gRPC servers running in containers. Together, these capabilities allow developers to deploy language-agnostic TCP and gRPC services closer to users across Cloudflare’s global network. ## Inbound TCP with `connect(socket)` - Workers can now accept inbound TCP sockets through a new `connect()` handler. - The socket exposes readable and writable streams, allowing Workers to send, receive, and proxy raw bytes. - Connections can be routed: - Between Workers - From Workers to Durable Objects - From Durable Objects to Cloudflare Containers - Developers can pipe data in both directions to preserve full-duplex communication. - Containers can run arbitrary TCP servers written in any language, such as Python services listening on port `8080`. - Cloudflare Spectrum provides the TCP ingress layer and routes incoming connections to the selected Worker. ## Full-Duplex gRPC in Containers - Developers can deploy gRPC servers written in languages such as Go inside Cloudflare Containers. - Bidirectional streaming allows clients and servers to exchange messages over one persistent connection. - This is particularly useful for: - Real-time voice AI - Low-latency inference - Mobile and distributed applications - Streaming RPC workflows - A sample Go server sends an initial connection message, echoes incoming messages, and sends a closing message when the client disconnects. - Cloudflare’s network of more than 330 locations can bring gRPC workloads closer to users, reducing latency. ## gRPC APIs from Workers - Workers can serve unary and server-streaming gRPC APIs. - Workers can also call external gRPC servers. - Developers write the application using gRPC-Web, while Cloudflare automatically converts incoming and outgoing requests to standard gRPC. - This provides a simpler integration path for applications that need gRPC without managing raw protocol translation themselves. ## Availability - The features are being introduced through a private beta. - Interested developers must sign up to gain access. Cloudflare recommends these capabilities for applications requiring persistent, low-latency, bidirectional communication. The combination of Spectrum, Workers, Durable Objects, and Containers provides a flexible path for running raw TCP protocols and gRPC services close to end users.

Read original(opens in new tab)

Cloudflare WorkersGrpcDurable ObjectsTcp+3

cloudflare·Aug 3, 2026·3 min readCurated summary

Smaller, faster, safer: running Kimi and GLM at scale

Cloudflare improves the efficiency of serving large, long-context models by optimizing both GPU memory usage and request concurrency. Its approach combines FP8 KV-cache quantization, INT4 weight compression, and integrity checks for shared caches, while using separate prefill and decode pools to apply each optimization where it helps most. These techniques increase throughput and reduce costs without materially affecting model accuracy. ## Quantizing the KV Cache - Long-context models store attention keys and values in a KV cache, which often exhausts GPU memory before model weights do. - Cloudflare stores the cache in FP8 instead of BF16, cutting its size in half. - On Kimi K2.6, this increases available context from roughly 686,000 to 1.37 million tokens. - FP8 is slightly slower at the same concurrency because values must be converted during attention. - However, FP8 supports more concurrent requests: - BF16 runs out of memory at 32 requests. - FP8 reaches 2,192 tokens per second at 64 requests. - Peak throughput improves by about 41%, with roughly 30% lower cost per token. - Cloudflare keeps BF16 for prefill, where workloads are compute-bound. - Evaluation results show FP8 and BF16 produce effectively indistinguishable quality across reasoning, knowledge, tool-calling, and internal benchmarks. ## Compressing Model Weights - GLM 5.2 weights are compressed from FP8 to INT4 for the decode phase. - The checkpoint shrinks from 705 GB to 421 GB, while per-GPU memory in an eight-way deployment falls from about 88 GB to 52 GB. - The freed memory supports approximately 1.18 million tokens of KV cache. - INT4 improves decode performance because generation is memory-bandwidth-bound: - Single-request throughput rises from 60 to 92 tokens per second, a 55% gain. - Gains range from 16% to 27% at higher concurrency. - Prefill becomes slower with INT4 because compressed weights must be expanded before computation: - FP8 prefill: about 10,160 tokens per second. - INT4 prefill: about 8,660 tokens per second. - Cloudflare therefore uses FP8 for prefill and INT4 for decode. - Accuracy remains within 0.8 percentage points of the FP8 model across tested benchmarks. ## Protecting a Shared KV Cache - Greater memory efficiency allows hundreds of requests to share physical KV-cache pages, increasing the risk of page-allocation or bookkeeping errors. - Cloudflare assigns each cache page a changing tag whenever it is reallocated. - Requests record the pages and tags they expect, and the server validates these mappings before supported decode operations. - If a mismatch occurs, the request is aborted instead of reading incorrect data. - In production-style tests, integrity checking caused: - Less than 1% throughput reduction. - Less than 1% increase in p95 latency. - Validation runs as a separate batch check rather than inside the attention kernel, avoiding GPU synchronization races. - The feature is enabled per deployment, while deployments that do not use it incur no measurable overhead. ## Future Work - Cloudflare is expanding FP8 KV caches across its fleet. - It is testing NVFP4 weight compression on NVIDIA Blackwell GPUs. - The company is also working toward making cache integrity checks universally enabled at negligible cost. Together, these optimizations let Cloudflare serve larger models with more concurrent users, lower inference costs, and essentially unchanged model quality. Separating prefill and decode workloads is central to applying each precision choice where it delivers the best trade-off.

Read original(opens in new tab)

Gpu InferenceMixture Of ExpertsKv CacheContinuous Batching+4

cloudflare·Aug 3, 2026·3 min readCurated summary

Introducing the Billable Usage API: programmatic cost visibility for Cloudflare

Cloudflare is launching a Billable Usage API to make account spending accessible to automation, not just human-facing dashboards. The single endpoint reports usage and costs across products such as Workers, R2, D1, Workers AI, Vectorize, Images, and Stream. Its FOCUS-inspired schema is designed to integrate with FinOps tools, although full FOCUS conformance is still planned. ## Billable Usage API - Endpoint: - `GET /accounts/{account_id}/billable-usage` - Optional date filters: - `from=YYYY-MM-DD` - `to=YYYY-MM-DD` - Requires a Cloudflare API token with appropriate billing access. - Returns HTTP 200 with a standard Cloudflare JSON envelope: - `result` - `success` - `errors` - `messages` - Usage and cost data currently refresh daily, with more real-time reporting planned. ## Usage and Cost Data Each result row represents one product and charge period. - `ServiceName` and `ServiceFamilyName` identify the product and product family. - `ChargePeriodStart` and `ChargePeriodEnd` define the covered period. - `PricingQuantity` and `ConsumedUnit` show billable usage, such as requests, GB-months, or GB-seconds. - `ContractedCost` reports the charge in `BillingCurrency`. - `CumulatedPricingQuantity` and `CumulatedContractedCost` provide running billing-period totals. - `ZoneId` and `ZoneName` identify the relevant zone when usage is zone-specific. - Results can be filtered by date and include billing-period metadata such as `BillingPeriodStart`. ## FOCUS-Compatible Schema Cloudflare adopted naming that closely follows the FinOps Open Cost and Usage Specification (FOCUS). - Exact or near matches include: - `BillingCurrency` - `ChargePeriodStart` and `ChargePeriodEnd` - `ServiceName` - `ConsumedQuantity` and `ConsumedUnit` - `PricingQuantity` - `ContractedCost` - `ServiceFamilyName` is similar to FOCUS’s `ServiceCategory`, but uses Cloudflare’s native grouping. - `ZoneId` and `ZoneName` serve a role similar to `ResourceId` and `ResourceName`. - `CumulatedContractedCost` is a convenience field; FOCUS generally treats cumulative calculations as query-time operations. - The API is not yet fully FOCUS-compliant because some required columns are missing. ## Vantage Integration Cloudflare partnered with Vantage to bring Cloudflare costs into multi-provider FinOps workflows. - Vantage connects with a read-only Cloudflare API token granting Billing Read access. - It retrieves Billable Usage data daily and breaks spending down by: - Product - Zone - Account - Cloudflare costs appear alongside AWS, Azure, AI, and SaaS provider costs in: - Cost Reports - Budgets - Cost Alerts - Supported workflows include cross-provider allocation, anomaly detection, and FinOps-agent or MCP queries. ## Motivation for Programmatic Cost Visibility As agents increasingly deploy Workers, provision R2 buckets, and manage D1 databases, they can also create unexpected spending. Cloudflare argues that programmatic infrastructure management requires programmatic cost visibility, enabling automated monitoring, allocation, alerts, and optimization. The API is intended as a foundation for agent-driven and FinOps tooling, while Cloudflare works toward more real-time data and complete FOCUS conformance.

Read original(opens in new tab)

Model Context ProtocolCloudflareCloudflare WorkersFinops+3

cloudflare·Aug 2, 2026·2 min readCurated summary

Welcome to Agents Week

The post introduces “Agents Week” by reframing the question from what an Agent Cloud should be to what agents themselves need. Unlike today’s human-oriented cloud and web, an Agent Cloud must provide agent-native primitives while also translating between existing human-designed systems and an emerging agent-shaped web. The week will explore how infrastructure, development, security, organizational access, and web interactions should evolve for agents. ## Why the Existing Cloud Falls Short - Today’s cloud and web assume a human is monitoring and interacting with them. - Interfaces are built around attention, visual dashboards, clicking, reading, and human decision-making. - Agents have different priorities: speed, structure, reliable access, and the ability to operate continuously without fatigue or distraction. ## Two Responsibilities of an Agent Cloud - Build an agent-native foundation with primitives designed for agents from the beginning rather than adapted from human tools. - Serve as a translation layer between: - The existing human-shaped web and infrastructure. - The agent-shaped systems being developed for the future. ## Topics for Agents Week The series will examine: - Storage, compute, and execution primitives required by agents. - An agentic development lifecycle, or “ADLC,” that reduces or removes humans from routine development loops. - Secure ways for employees and agents to access organizational systems of record and perform meaningful work. - The evolution of the agentic web, including discovery, access, and payments. - How humans and agents will work together during the transition to agent-oriented systems. ## Invitation to Ask Agents Directly The post encourages readers to ask their own agents what they need from an Agent Cloud instead of relying only on human assumptions. Suggested areas include cloud infrastructure, development processes, secure enterprise access, and web interactions, with readers invited to share their agents’ responses. In practical terms, designing an Agent Cloud requires starting with agents’ operational needs while supporting compatibility with the human-oriented systems that still dominate today.

Read original(opens in new tab)

AI AgentsCloud ComputingSdlcAgent Cloud+2

cloudflare·Jul 31, 2026·3 min readCurated summary

An API for MoQ: provision your own isolated relays

Cloudflare has moved MoQ from an open testing network toward production use by adding isolated relays and authentication. Its provisioning API and dashboard let applications create globally available relay scopes and issue separate publisher and subscriber credentials, without deploying infrastructure. The beta supports MoQ Transport drafts 14 and 16 and is currently free. ## MoQ and Its Architecture - MoQ is an open IETF publish/subscribe protocol built on QUIC, the transport used by HTTP/3. - Publishers send named data streams, while subscribers request those streams through relays. - Relays copy data to subscribers without inspecting its contents, enabling efficient fan-out. - The same system can support live video, video calls, low-latency messaging, and other real-time workloads. - Using CDN-based relays avoids the cost and complexity of operating specialized media servers. ## From Open Preview to Production - Cloudflare’s initial MoQ preview exposed an unauthenticated relay on servers in more than 330 cities. - Over 1,000 clients continue to use the open endpoints daily for testing and development. - The lack of authentication made the preview unsuitable for applications requiring confidentiality or role-based permissions. - For example, live auction applications need broadcasters to publish while viewers can only subscribe. ## Isolated Cloudflare Relays - Provisioning a relay creates an isolated scope across Cloudflare’s existing global network rather than starting a VM, container, or dedicated process. - Each scope separates an application’s namespaces, tracks, and objects from those of other applications. - Clients connect through an Anycast endpoint, with Cloudflare handling global routing. - Relays become available within seconds, without regional capacity planning, load balancers, or server management. - Cloudflare compares the model to creating a virtual host rather than deploying a new web server. ## Provisioning API and Access Tokens - The control-plane API manages relay configuration and credentials but does not handle the media flowing through relays. - A relay defines the isolated application scope. - Tokens grant `publish`, `subscribe`, or both operations for a specific relay. - Tokens can have expiration times and can be revoked independently. - Creating a relay automatically returns: - A token capable of publishing and subscribing. - A subscribe-only token intended for viewers. - Additional narrowly scoped tokens can be created through the API or dashboard. - Current tokens apply to an entire relay; Cloudflare is working with the MoQ community on more granular authorization. ## Using the API and Dashboard - A relay can be created with one authenticated API request containing its name. - Tokens can be added through an endpoint such as `/moq/relays/$RELAY_ID/tokens`. - The dashboard workflow is available under **Media > Realtime > MoQ Relay**. - Applications should provide broadcasters with publish-capable credentials and viewers with subscribe-only credentials. ## Connecting Clients - Clients send their token when opening a MoQ session. - The relay enforces the token’s permitted operations. - Cloudflare’s open-source `moq-rs` tools can be used with media generated by tools such as `ffmpeg`. Cloudflare’s authenticated, isolated MoQ relays make the protocol more practical for production real-time applications. Developers can use the API or dashboard to provision a globally distributed relay and manage separate, expiring credentials without operating their own media infrastructure.

Read original(opens in new tab)

CloudflareJwtCdnWebrtc+3

cloudflare·Jul 30, 2026·4 min readCurated summary

Dogfooding at scale: migrating cdnjs to Cloudflare’s Developer Platform

cdnjs now runs entirely on Cloudflare’s Developer Platform after a migration intended to improve maintainability rather than performance. Despite the rise of bundlers and modern JavaScript tooling, cdnjs still serves about 9 billion requests per day because it is free, familiar, immutable, auditable, and widely used by both developers and AI coding assistants. The migration replaces a fragmented GCP, GitHub, VM, and Cloudflare setup with a unified architecture built around Workers, R2, Workflows, Queues, D1, KV, Cache, and Containers. ## cdnjs’s Scale and Continued Relevance - cdnjs serves roughly: - 108,000 requests per second - 9 billion requests per day - Traffic across more than 330 Cloudflare data centers - A 98.6% cache-hit rate - It is used by approximately 12% of websites and holds a 48.3% share of the JavaScript CDN market. - Its simple `<script>`-tag model remains popular because: - URLs and versions are consistent and immutable. - Libraries are available without accounts, API keys, or rate limits. - Files include Subresource Integrity hashes. - The project is open source and community-driven. - AI assistants frequently generate cdnjs URLs because they appear throughout years of tutorials, documentation, GitHub repositories, and Stack Overflow answers. ## Why the Existing Architecture Became a Problem - Cloudflare moved cdnjs file serving to Workers and KV in 2020, improving resilience and enabling pre-compressed Brotli and gzip assets. - The publishing pipeline remained on GCP because Cloudflare previously lacked suitable tools for: - Fetching large package archives - Running CPU-intensive processing - Coordinating multi-step jobs over hours - The old pipeline combined GCP Functions, Google Cloud Storage, Pub/Sub, a git-sync VM, GitHub, Workers KV, and a bare-metal origin. - New features and bug fixes required coordinating deployments across multiple platforms, while observability required manually stitching together unrelated logs. ## Problems with the Legacy Pipeline - **No shared tracing** - Package updates could pass through several systems without a common correlation ID. - Partial failures could leave KV updated while GitHub remained stale, with no alert indicating the divergence. - **Split-brain storage** - File content existed both in Workers KV and a GitHub repository. - Neither system was cleanly authoritative, making reconciliation difficult. - **Storage-driven orchestration** - GCP Cloud Functions triggered one another through object-created events. - Storage effectively acted as a message queue without dead-letter handling, backlog visibility, or reliable replay. - **Operational fragmentation** - npm polling required 26 separately deployed Cloud Functions, one for each alphabetic shard. - Health monitoring required checking all 26 deployments and their logs. - **An oversized GitHub repository** - The repository exceeded 1.1 TB of packed storage. - GitHub could no longer generate archive downloads reliably. - Cloning and forking became impractical. - A 274-entry `.gitignore` accumulated to exclude releases the pipeline could not reject properly. - **Security overhead** - Cloud Functions, a VM, container images, storage buckets, and service-account credentials all required patching, auditing, and protection. - Retiring these components reduced the attack surface and eliminated recently exposed vulnerabilities. ## The New Cloudflare-Based Architecture - The rebuilt system uses Cloudflare’s Developer Platform end to end. - **R2** becomes the single source of truth for file content. - It can store large assets that previously did not fit comfortably in KV, including source maps, large bundles, and font packages. - Its S3-compatible API makes the catalog accessible to external tools and mirrors. - The broader platform combines: - Workers for request handling - Workflows for orchestration - Queues for reliable asynchronous processing - R2 for durable object storage - D1, KV, Workers Cache, and Containers for supporting services - Centralizing the pipeline should make processing state observable, reduce deployment complexity, and eliminate inconsistencies between edge storage and the GitHub repository. ## Practical Conclusion The cdnjs migration demonstrates that a globally critical, high-volume open-source service can evolve from a collection of legacy systems into a unified serverless platform. Its continued value comes not only from speed, but from being free, predictable, immutable, and easy for both humans and automated tools to consume.

Read original(opens in new tab)

Cloudflare WorkersServerlessContent Delivery NetworkCloudflare R2+3

cloudflare·Jul 29, 2026·3 min readCurated summary

Post-quantum authentication to origins is now supported

Cloudflare has added post-quantum authentication to Authenticated Origin Pulls (AOP) and Custom Origin Trust Store (COTS), enabling fully post-quantum-secure mutual TLS between Cloudflare and customer origins. The implementation uses ML-DSA signatures, with ML-DSA-44 recommended for most deployments. This marks the first milestone in Cloudflare’s roadmap toward full post-quantum security by 2029. ## Why Cloudflare-to-Origin Authentication Is Different - A proxied request typically involves: - Visitor to Cloudflare - Cloudflare to the customer’s origin - Post-quantum encryption already protects both connections. - Authentication requirements differ for the origin connection because: - Cloudflare controls the client side and can use connection pooling to amortize signature costs. - Cloudflare and customers already have an account-based trust relationship. - Custom PKIs can be used without relying on public WebPKI constraints such as intermediate certificates and Certificate Transparency. - Cloudflare is pursuing Merkle Tree Certificates for visitor-to-Cloudflare authentication, but ML-DSA can be deployed sooner for origin connections. ## ML-DSA Support - Cloudflare supports all FIPS 204 ML-DSA parameter sets: - ML-DSA-44 - ML-DSA-65 - ML-DSA-87 - ML-DSA-44 is recommended for most applications because it offers the best performance while providing NIST category 2 security strength. ## Custom Origin Trust Store - In Full (strict) SSL mode, Cloudflare validates origin certificates against trusted public CAs and Cloudflare’s Origin CA. - COTS lets customers replace that default trust store with a set of customer-controlled CAs. - Customers can now upload ML-DSA CAs. - Cloudflare will trust origin certificates that chain to those ML-DSA CAs. - COTS requires Advanced Certificate Manager. ## Authenticated Origin Pulls - AOP enables mutual TLS, allowing origins to require requests to come from Cloudflare. - It is available on all Cloudflare plan levels. - Per-zone and per-hostname AOP configurations now support ML-DSA certificates and private keys. - Private keys must be uploaded in FIPS 204 seed format. - The global AOP configuration does not yet support this capability and will require additional work. ## Preventing Downgrade Attacks - Simply supporting post-quantum algorithms is not enough if classical authentication methods remain trusted. - An attacker with the ability to forge classical credentials could force a connection to downgrade to a quantum-vulnerable mechanism. - Origins must therefore remove trust in classical authentication mechanisms where appropriate. - Cloudflare’s AOP and COTS configuration guidance explains how to prevent these downgrades. ## Configuration Requirements - Certificate generation requires OpenSSL 3.5.0 or later. - ML-DSA private keys must use the FIPS 204 seed-only encoding. - Customers configure: - An ML-DSA CA and origin certificate chain for COTS - An ML-DSA client certificate and private key for AOP - Configuration can be performed through the Cloudflare API, with dashboard instructions available in the developer documentation. Cloudflare customers needing post-quantum protection for origin connections should combine ML-DSA-based COTS and AOP, explicitly remove trust in classical alternatives, and use ML-DSA-44 unless their security requirements justify a larger parameter set.

Read original(opens in new tab)

CloudflarePost Quantum CryptographyMl DsaOpenssl+4

cloudflare·Jul 28, 2026·3 min readCurated summary

Natural disasters and government interference: examining Q2 2026’s major Internet disruption event

Cloudflare’s Q2 2026 outage review shows how dependent Internet connectivity remains on physical infrastructure, government policy, and complex technical systems. Disruptions ranged from typhoons, earthquakes, and power failures to shutdowns, war-related data-center damage, DNSSEC errors, and submarine cable cuts. Despite these failures, regional networks generally remained resilient, with Cloudflare Radar revealing both the scale and distinctive patterns of each outage. ### Natural Disasters and Power Failures - Super Typhoon Sinlaku passed north of Guam in April, causing power and water disruptions. - Internet traffic fell as much as 80% below expected levels on April 13–14. - Two earthquakes in northern Venezuela on June 24 produced an immediate drop in HTTP traffic. - The decline was especially visible at Fibex Telecom, CANTV, and VNET. - A nationwide power outage in Tanzania on June 27 caused Internet traffic to collapse for at least five hours. - These events demonstrate that storms, earthquakes, and electricity failures can produce similar connectivity impacts, reinforcing the need for redundancy in power, routing, and physical network paths. ### Government Shutdowns and Geopolitical Conflict - Iran began restoring Internet access on May 26 after an 88-day near-total blackout. - Traffic initially recovered to about 40% of pre-outage levels, later reaching 90% before settling near 59%. - Connectivity returned closer to the country’s recent pre-shutdown baseline, rather than fully normal levels. - AWS’s `me-central-1` region in the UAE continued to experience reduced traffic after drone strikes damaged infrastructure in the UAE and Bahrain. - The disruption affected applications hosted in the region even when those applications themselves remained operational. - Iraq imposed three exam-related shutdowns, while Sudan imposed ten. - Sudan’s outages generally lasted about 3.5 hours. - Iraq’s shutdowns lasted roughly 90 minutes. - These incidents illustrate how governments can deliberately switch off, throttle, or selectively restore national connectivity. ### DNSSEC Failure in Germany - On May 5, a DNSSEC key rollover at DENIC caused invalid signatures for Germany’s `.de` domain. - DNS resolvers validating DNSSEC rejected `.de` responses and returned `SERVFAIL`, making affected websites unreachable worldwide until service was restored at 23:15 UTC on May 5. - Cloudflare observed an increase in `.de` queries because failed responses could not be effectively cached, forcing repeated lookups and retries. - Users experienced the incident as widespread website unavailability rather than as an obvious cryptographic or DNS problem. ### Cable and Infrastructure Vulnerabilities - A submarine cable cut in Saint Lucia further demonstrated how regional connectivity can depend on a small number of physical links. - Together with the German DNSSEC failure, the incident shows that routine infrastructure maintenance and single physical-path failures can have effects far beyond the location where the fault occurs. Cloudflare’s findings underline the importance of network redundancy, careful operational procedures, and continuous monitoring. Internet outages may have very different causes, but their effects on users can look remarkably similar: sudden loss of access to communication, applications, and essential information.

Read original(opens in new tab)

AWSCloudflare RadarDnssecInternet Infrastructure+3

cloudflare·Jul 27, 2026·3 min readCurated summary

We’re open sourcing our privacy proxy CLI

Oblivious HTTP (OHTTP) is difficult to debug because requests pass through multiple parties, use binary HTTP encoding, and depend on several RFC-defined cryptographic steps. Cloudflare created and open-sourced `pvcli`, a CLI that simplifies testing and troubleshooting privacy protocols by exposing each stage of the process. Released under Apache-2.0, the tool is designed for production-scale debugging and community contributions. ## Why OHTTP Debugging Is Complex - OHTTP ensures that no single party can know both the client’s identity and the requested content. - It relies on two non-colluding servers: - A **relay** that sees the client but not the request contents. - A **gateway** that decrypts the request but does not see the client’s identity. - A typical request proceeds through several stages: - The client retrieves the gateway’s public key. - The client encrypts the request and sends it to the relay. - The relay forwards the anonymized request to the gateway. - The gateway decrypts it and contacts the target. - The response travels back through the gateway and relay before being decrypted by the client. - Every stage can introduce failures, making it difficult to identify whether the problem lies with the client, relay, gateway, or target. ## Why Cloudflare Built `pvcli` - Privacy products such as Privacy Proxy and Privacy Gateway introduced increasing operational complexity and customer-specific requirements. - Engineers frequently had to create one-off clients to test customer deployments. - Diagnosing failures required determining which protocol step had failed and which party was responsible. - OHTTP’s binary formats made manual inspection especially error-prone. - `pvcli` consolidates privacy-protocol functionality into one familiar CLI with support for different protocols and architectures. ## Debugging OHTTP Manually - Engineers first fetch the gateway’s public key, receiving a long hexadecimal binary payload. - They must manually parse fields according to RFC 9458, including: - The key entry length. - The public key identifier. - The asymmetric encryption method, such as DHKEM with X25519 and HKDF-SHA256. - The gateway’s public key. - Supported symmetric encryption algorithms, such as HKDF-SHA256 and AES-128-GCM. - The original HTTP request must then be converted into binary HTTP according to RFC 9292. - Engineers manually verify encoded fields such as: - The request method (`POST`). - The HTTPS scheme. - The target hostname. - The request path and headers. - The JSON body. - Finally, they need custom scripts to encrypt the binary request and construct the OHTTP wrapper request. ## Using `pvcli` - A complete OHTTP request can be issued with a single command: ```bash pvcli --ohttp \ --first-hop https://relay-cloudflare.ohttp.info \ --proxy https://gateway.ohttp.info \ -X POST \ --header "content-type: application/json" \ --data '{"test":1}' \ https://target.ohttp.info/anything ``` - The tool handles the relay, gateway, encryption, binary HTTP encoding, and target request flow. - It provides a clearer view of each protocol step, replacing manual hexadecimal parsing and bespoke scripts with a repeatable debugging workflow. `pvcli` is a practical way to test live OHTTP deployments, isolate failures across the relay and gateway chain, and reduce the risk of mistakes when inspecting binary protocol data.

Read original(opens in new tab)

CryptographyCliOblivious HttpBinary Http+3

cloudflare·Jul 24, 2026·4 min readCurated summary

BGP ORIGIN attribute manipulation and its impact on the Internet

BGP’s ORIGIN attribute is intended to describe how a route entered the protocol and should remain unchanged after being set by the originating AS. However, the investigation found that roughly 70% of observed paths had an ORIGIN value different from the original, often because transit providers manipulate it to influence route selection and attract traffic. This widespread practice turns a supposedly stable routing signal into a tool in a revenue-driven competition between networks. ## What the BGP ORIGIN Attribute Means - ORIGIN describes how a route was injected into BGP, rather than identifying the originating Autonomous System. - It has three values: - **IGP (0):** The route originated within the AS. - **EGP (1):** A historical value associated with the obsolete Exterior Gateway Protocol. - **INCOMPLETE (2):** The route was learned through an unknown or external mechanism. - Across routes visible through RIPE RIS and RouteViews: - 89.8% used IGP. - 3.5% used EGP. - 6.7% used INCOMPLETE. - When Local Preference and AS_PATH length are equal, BGP prefers the lower ORIGIN value, making IGP preferable to EGP and INCOMPLETE. - RFC 4271 states that ORIGIN is generated by the originating speaker and **should not be changed** by other speakers. ## How Providers Use ORIGIN Manipulation - A transit provider can rewrite a route’s ORIGIN to IGP, making its path more attractive during BGP route selection. - In the example: - AS64501 announces a route with ORIGIN INCOMPLETE. - AS64502 and AS64503 propagate the route to AS64504. - AS64503 changes the ORIGIN to IGP. - Because both paths have equal AS_PATH lengths, AS64504 selects the path through AS64503. - This manipulation redirects traffic—and potentially transit revenue—toward the provider that altered the attribute. - Some operators also rewrite routes to EGP or INCOMPLETE to make them less preferred than customer routes. - The practice has been discussed at RIPE and LACNIC meetings and has contributed to proposals recommending that ORIGIN be deprecated. ## Measuring ORIGIN Rewriting - The researchers announced: - Three IPv4 prefixes. - Three IPv6 prefixes. - Each prefix used a different ORIGIN value: IGP, EGP, or INCOMPLETE. - Announcements were made from multiple peering locations using BGP Anycast. - After propagation, the prefixes were withdrawn to trigger BGP path hunting, exposing additional routes. - Researchers analyzed: - MRT UPDATE messages from RIPE RIS and RouteViews. - Local BMP data from their border routers. - BGPKIT tools for parsing the data. - UPDATE messages were chosen over routing-table snapshots because they reveal more paths during both announcements and withdrawals. ## Visibility Challenges - Public collectors cannot observe every AS involved in a route’s propagation. - The growth of hyperscalers, CDNs, and direct local peering has flattened the traditional transit hierarchy. - As a result, many paths bypass publicly visible transit networks. - Conclusions about which AS changed an attribute therefore carry some uncertainty, especially beyond directly observed peers. ## Direct-Peer Findings - The first analysis examined two-AS paths such as `ASX AS13335`, where ASX was a direct peer of the researchers. - Because the researchers controlled the original ORIGIN value, any different value observed from a direct peer indicated that peer had rewritten it. - Among 352 IPv4 direct peers: - Three ASes consistently changed routes to EGP. - Four changed routes to INCOMPLETE, potentially attempting to deprioritize them. - One contacted operator confirmed that it rewrote peer- and provider-learned routes to EGP so customer routes would be preferred. - Several ASes advertised both the original ORIGIN and IGP for non-IGP prefixes, likely because they received the routes at multiple locations and altered the value to steer traffic through preferred sites. - Combining these behaviors, the researchers found that nearly 10% of direct peers were rewriting ORIGIN, while the broader experiment detected changes on approximately 70% of observed paths. Network operators should treat ORIGIN rewriting as a significant deviation from BGP’s intended behavior, since it can alter routing decisions, distort traffic engineering, and create commercial incentives for further manipulation.

Read original(opens in new tab)

BgpIpv6Autonomous SystemsIpv4+4

cloudflare·Jul 23, 2026·3 min readCurated summary

Introducing Cache Response Rules

Cache Response Rules let Cloudflare modify an origin response after it arrives but before it is stored in cache. They address response-header problems—such as accidental `Set-Cookie`, restrictive `Cache-Control`, or problematic validators—that can unnecessarily reduce cacheability. This provides an origin-independent fix while preserving the distinction between request-time and response-time caching decisions. ## When Caching Decisions Are Made - CDN caches aim to serve content from the edge and contact the origin only on misses. - Origin response headers determine: - Whether content can be cached - How long it remains fresh - When it should be revalidated - Whether it should be cached at all - Common problems include: - `Set-Cookie` on static assets such as `/static/app.js`, making them uncacheable - `Cache-Control: no-cache` on content that is safe to cache at the CDN - Browser-oriented cache directives that are unsuitable for Cloudflare - Overly aggressive `ETag` values causing repeated revalidation - These issues often require coordination between separate origin and CDN teams, delaying simple fixes. ## Cache Response Rules - Run after the origin responds but before Cloudflare writes the response to cache. - Can: - Rewrite `Cache-Control` directives - Strip `Set-Cookie`, `ETag`, and `Last-Modified` - Manage cache tags for purging - Apply entirely within Cloudflare, without requiring origin code changes. - They solve problems that request-time rules cannot, because response headers are unavailable until after the origin request completes. ## The Missing Piece in Cloudflare’s Cache Controls - Earlier caching behavior was largely handled through Page Rules, which combined caching with unrelated features. - Cloudflare later introduced more focused controls, including: - Cache Rules - CDN-Cache-Control - Custom cache keys - Other cache-specific settings - Most existing controls operate during the request phase. - Before contacting the origin, Cloudflare can evaluate only request information such as the URL, headers, file extension, geography, and device type. - Previously, response-header problems required: - Changing the origin - Deploying a Worker to re-fetch and rewrite responses - Accepting a lower cache hit ratio ## Two Phases, Two Questions - **Cache Rules** run before the origin request and determine: - Whether the response is eligible for caching - What cache key identifies the object - How it should be cached, including TTL and stale-serving behavior - **Cache Response Rules** run after the origin response and determine whether caching behavior should be adjusted: - Remove headers that make content ineligible - Change origin cache directives - Set cache tags - When the two rule types conflict, the Cache Response Rule takes precedence. - Response rules cannot change the cache key, since that must already be established during the request phase. - They can make an otherwise eligible response non-cacheable with `no-store`, or make content eligible by removing `Set-Cookie`, but they cannot recover the latency of a request that was already excluded from caching at request time. Cache Response Rules complement rather than replace Cache Rules. Use request-phase rules for cache eligibility, keys, and general caching behavior; use response-phase rules to correct origin headers before they damage cacheability.

Read original(opens in new tab)

CloudflareCachingCdnCache Response Rules+2

cloudflare·Jul 21, 2026·3 min readCurated summary

How the 2026 World Cup affected Internet traffic

The 2026 World Cup demonstrated how a rare shared global event can reshape Internet behavior across countries. Cloudflare used traffic data from its global network to show that match timing, teams, and major storylines significantly affected online activity. Overnight matches often doubled traffic, while games during normal active hours could reduce browsing as people focused on watching. ## Measuring “Normal” Internet Activity - Cloudflare established a baseline using the median traffic from the previous four weeks. - Traffic changes were expressed as a log₂ ratio: - `0` means normal activity. - `+1` means traffic doubled. - `−1` means traffic fell to half its normal level. - This approach made traffic changes comparable between high-volume and low-volume countries. ## Kickoff Time Shaped Online Behavior - The largest traffic changes occurred during matches played between midnight and 8 a.m. local time. - Fans staying awake or waking early caused traffic to rise well above normal, sometimes by more than 2x. - Daytime matches had little effect because viewers were likely already online. - Evening matches produced a smaller increase on weekdays, but could also cause traffic to fall when people stopped browsing to watch. - In Bosnia and Herzegovina: - A 2 a.m. match caused traffic to more than double. - An evening match reduced traffic to roughly 70% of normal. - Brazil and Japan showed opposite patterns during the same match: - Japan’s overnight viewing produced traffic around twice its usual level. - Brazil’s daytime match coincided with traffic about 40% below normal. ## Matches With the Greatest Global Impact - Cloudflare measured traffic during the two hours after kickoff. - For each match, it calculated the absolute deviation from normal across countries and then used the median result. - Simultaneous matches were excluded because their effects could not be reliably separated. - The most impactful match was Argentina vs. Switzerland, with traffic changing by a factor of about 1.26. - France vs. Spain followed at 1.21. - The highest-impact games included quarterfinals, knockout matches, and some round-of-32 games—not only the final or semifinals. ## Argentina Led the Teams Drawing Global Attention - Argentina produced the largest average worldwide traffic impact, at 1.17x normal activity. - France, Brazil, Portugal, Morocco, Spain, and Norway also ranked highly. - Argentina’s appeal was linked to its status as defending champion and the possibility that the tournament could be Lionel Messi’s final World Cup. - Haiti and Iraq appeared as outliers because matches involving major teams caused especially large changes relative to their usual traffic levels. ## More Traffic to Sports Betting Websites - Requests to gambling-related websites increased after the tournament began compared with the preceding month. - Before the World Cup, betting traffic followed a regular weekly cycle. - Once matches began nearly every day, that weekly pattern flattened into a more consistent level of activity. Overall, the data shows that the World Cup affected Internet use in two distinct ways: inconvenient kickoff times brought previously offline fans online, while matches during normal usage hours often diverted people away from their usual browsing. For analyzing global events, normalized, country-by-country traffic measurements provide a clearer picture than raw request volumes alone.

Read original(opens in new tab)

DnsData AnalysisCloudflare RadarHttp Traffic+2

cloudflare·Jul 20, 2026·3 min readCurated summary

Cloudflare Internal DNS is now generally available

Cloudflare Internal DNS is now generally available as a unified platform for public and private DNS. It combines recursive resolution, authoritative private zones, DNS policy enforcement, and Zero Trust controls on Cloudflare’s global network. The goal is to eliminate fragmented DNS systems and simplify split-horizon management without duplicated configurations or synchronization drift. ## Problems with Traditional Internal DNS - Organizations often manage public DNS, internal DNS, and cloud-provider DNS separately. - Separate control planes create inconsistent policies, limited visibility, and operational overhead. - Split-horizon DNS typically requires parallel environments that can drift and cause outages. - Legacy appliances introduce hardware refresh cycles and scaling constraints. ## Unified DNS and Zero Trust - Public and private DNS share one platform, API, audit trail, and policy layer. - Internal DNS is included for Enterprise customers using Cloudflare Gateway. - Gateway policies determine which users and devices can resolve specific DNS views. - Private name resolution becomes part of the broader Zero Trust architecture. ## Internal DNS Architecture Cloudflare Internal DNS has two main components: - **Gateway Resolver** - Performs recursive resolution and evaluates DNS policies. - Can filter queries or redirect them to different upstream sources. - Provides centralized logging, auditing, and policy management. - **Internal Authoritative DNS** - Serves records for private zones using Cloudflare’s authoritative DNS infrastructure. - Stores resources such as internal applications, databases, and service endpoints. The main configuration objects are: - **Internal Zones:** Authoritative records for private resources. - **DNS Views:** Resolution contexts containing one or more zones. - **Resolver Policies:** Gateway rules that route matching queries to a specific view. - **Zone references:** Allow one shared zone to be reused across multiple views without duplicating records. ## Query Resolution and Change Propagation - Queries first reach the Gateway Resolver for policy evaluation. - Matching policies route queries to an internal DNS view. - Blocked queries are dropped. - Unmatched queries use public resolution through 1.1.1.1. - Views can fall back to public DNS when a name is not found internally. - Changes from the dashboard, API, or Terraform use the same DNS Records API. - Records are validated, persisted, replicated globally, and propagated within seconds as caches are invalidated. ## Getting Started - Enterprise customers using Gateway can access Internal DNS from **Networking → Internal DNS**. - Initial setup generally requires: - Creating an internal zone and records. - Creating a DNS view and associating the zone. - Creating a Gateway resolver policy that routes users or devices to the view. - Terraform is supported and follows the same API ingestion and propagation path. ## Connectivity Cloud Integration - Internal DNS works with Cloudflare One Client, DoH, DoT, standard DNS, PAC files, and Cloudflare WAN. - Cloudflare WAN enables devices across branches, data centers, cloud environments, and remote networks to resolve internal names without installing the client on every device. - The service extends Cloudflare’s existing Connectivity Cloud rather than operating as an isolated DNS product. Cloudflare’s recommendation is to consolidate public DNS, private DNS, and DNS security policies on one control plane, particularly for organizations already using Cloudflare Gateway or WAN.

Read original(opens in new tab)

Zero TrustDnsTerraformCloudflare Gateway+4