techlist.io
KREN

Cloudflare

196 posts

blog.cloudflare.com

Filter by tag

Cloudflare74Cloudflare Workers44Database Design32AI Agents24Zero Trust21Network Security16TypeScript16Model Context Protocol15Large Language Models15Durable Objects14Dns12Sqlite12+764
cloudflare3 min readCurated summary

Post-quantum encryption for Cloudflare IPsec is generally available

Cloudflare has made post-quantum encryption for its IPsec service generally available, using hybrid ML-KEM alongside classical Diffie-Hellman. The implementation protects WAN traffic against “harvest-now-decrypt-later” attacks and interoperates with Cisco and Fortinet hardware already deployed by customers. Cloudflare argues that broadly adopted, software-based standards—not specialized quantum key distribution hardware—are essential for achieving post-quantum security at Internet scale. ## Cloudflare IPsec and WAN Connectivity - Cloudflare IPsec is a WAN Network-as-a-Service connecting: - Data centers - Branch offices - Cloud VPCs - Cloudflare One SASE environments - Encrypted IPsec tunnels run over Cloudflare’s global IP Anycast network. - Customers receive simplified configuration, high availability, automatic traffic rerouting, and global network scale. ## Hybrid ML-KEM for IPsec - The new implementation uses hybrid ML-KEM, standardized as FIPS 203. - It addresses harvest-now-decrypt-later attacks, in which attackers collect encrypted traffic today and decrypt it once quantum computers can break current public-key cryptography. - ML-KEM is designed to run in software on standard processors and requires neither specialized hardware nor dedicated physical links. - The IETF draft `draft-ietf-ipsecme-ikev2-mlkem` combines: - A classical Diffie-Hellman exchange - A second ML-KEM exchange encrypted using keys derived from the first - Key material from both exchanges mixed into session keys for IPsec ESP traffic ## Interoperability with Network Hardware - Cloudflare initially tested its implementation against the strongSwan reference implementation. - General availability now includes interoperability testing with: - Cisco 8000 Series Secure Routers running version 26.1.1 or later - Fortinet FortiOS 7.6.6 or later - These devices can establish post-quantum Cloudflare IPsec tunnels without requiring new specialized networking hardware. ## Why IPsec Lagged Behind TLS - Hybrid ML-KEM reached TLS production roughly four years before a corresponding IPsec specification. - Cloudflare enabled hybrid post-quantum TLS key agreement in 2022, and more than two-thirds of human-generated TLS traffic to Cloudflare is now protected this way. - IPsec standardization moved more slowly partly because of continued interest in Quantum Key Distribution (QKD). - Cloudflare criticizes QKD as unsuitable for Internet-scale deployment because it: - Requires specialized hardware and dedicated physical links - Does not provide authentication - Has limited cross-vendor interoperability - The NSA, Germany’s BSI, and the UK’s NCSC have warned against relying solely on QKD. ## Standards and Compatibility Challenges - RFC 9370, published in 2023, allowed multiple parallel key exchanges with classical Diffie-Hellman but did not define the specific ciphersuites to use. - Some vendors introduced incompatible or non-NIST-standardized ciphersuites, creating “ciphersuite bloat.” - Cloudflare’s implementation does not currently interoperate with Palo Alto Networks’ earlier RFC 9370-based implementation. - The newer ML-KEM draft fills this gap by defining hybrid ML-KEM as a standardized exchange mechanism. - Cloudflare hopes continued industry convergence will eventually enable interoperability with additional vendors, including Palo Alto Networks. ## Remaining Post-Quantum Work - Hybrid ML-KEM currently protects key establishment and data confidentiality. - IPsec still needs standardized post-quantum authentication mechanisms to defend live systems against quantum-enabled active attackers. - Cloudflare’s broader goal is full post-quantum security by 2029. Cloudflare recommends prioritizing interoperable, software-based post-quantum cryptography over niche QKD deployments. Organizations using supported Cisco or Fortinet branch hardware can begin protecting IPsec WAN traffic against future quantum decryption threats now.

Read original(opens in new tab)
Post Quantum CryptographyMl KemIpsecDraft Ietf Ipsecme Ikev2 Mlkem+3
cloudflare3 min readCurated summary

Agents can now create Cloudflare accounts, buy domains, and deploy

Agents can now take an application from development to production by creating Cloudflare accounts, obtaining API tokens, purchasing domains, and deploying code. Cloudflare’s integration with Stripe Projects removes most manual setup while keeping humans involved for permissions, terms acceptance, and payment approvals. The underlying protocol combines service discovery, authorization, and tokenized payments so agents can provision infrastructure on a user’s behalf. ## Zero-to-production deployment - Users install the Stripe CLI, authenticate, and run: ```bash stripe projects init ``` - An agent can then build an application and deploy it to a new domain. - If no Cloudflare account exists, one is provisioned automatically. - If an account already exists, the user authorizes access through OAuth. - The agent can: - Create a Cloudflare account - Obtain an API token - Register a domain - Deploy the application to production - Humans are prompted only when approval, terms acceptance, or payment setup is required. ## The protocol: discovery, authorization, and payment - **Discovery:** Agents query a catalog of available provider services and select the resources needed for the user’s request. - **Authorization:** The orchestrating platform verifies the user’s identity and enables providers to create accounts, connect existing accounts, and issue credentials securely. - **Payment:** Tokenized payment credentials let providers charge the user without exposing raw card details to the agent. - The approach builds on OAuth, OIDC, and payment-tokenization standards. ## Service discovery through a catalog - Agents can inspect available services with: ```bash stripe projects catalog ``` - They can select Cloudflare Registrar with: ```bash stripe projects add cloudflare/registrar:domain ``` - Providers expose service catalogs through REST APIs returning JSON. - This gives agents the context to choose appropriate products without requiring users to know which provider offers them. ## Automatic account creation and authorization - Stripe acts as the identity provider and attests to the user’s identity. - Cloudflare creates a new account automatically when the user has none. - Credentials are securely stored by the Stripe Projects CLI but made available to the agent for authenticated Cloudflare API requests. - Existing Cloudflare users authorize the integration through a conventional OAuth flow. ## Controlled agent spending - Agents never receive the user’s raw credit card information. - Stripe supplies Cloudflare with a payment token for subscriptions and purchases. - Spending is initially capped at $100 per month per provider. - Users can raise the limit and configure Cloudflare Budget Alerts as needed. ## Broader platform integration - The protocol is not limited to Stripe Projects. - Any platform with signed-in users can act as the orchestrator and integrate with Cloudflare. - This enables coding-agent platforms to let users deploy directly to production without requiring separate dashboard logins, token copying, or manual account setup. - Cloudflare is also enhancing the experience through its Code Mode MCP server and Agent Skills. Cloudflare and Stripe’s integration makes infrastructure provisioning an agent-driven workflow while retaining safeguards around identity, consent, and spending. For platforms building coding agents, adopting the protocol could provide a frictionless path from generated code to a live, paid production deployment.

Read original(opens in new tab)
Database DesignCloudflareStripeOauth+4
cloudflare3 min readCurated summary

Shutdowns, power outages, and conflict: a review of Q1 2026 Internet disruptions

Q1 2026 saw a sharp increase in major Internet disruptions, especially government-directed shutdowns in Uganda, Iran, and the Republic of Congo. Power failures, military attacks, severe weather, cable damage, and technical problems also caused significant regional outages. The disruptions demonstrate how connectivity remains vulnerable to political decisions, conflict, infrastructure failures, and environmental events. ## Government-Directed Shutdowns ### Uganda’s Election Shutdown - Authorities ordered a nationwide shutdown ahead of the January 15 presidential election. - Public Internet access was suspended from January 13 through January 17, when partial service resumed after President Yoweri Museveni’s reelection was announced. - Traffic at the Uganda Internet Exchange Point fell from roughly 72 Gbps to 1 Gbps. - Full restoration was announced on January 26. - The shutdown was justified as a measure against misinformation, electoral fraud, and related risks. - It prompted lawsuits and criticism from digital rights groups, particularly because Uganda had also restricted connectivity during the 2021 election. ### Iran’s Prolonged Disruptions - Iran experienced two nationwide shutdowns during the quarter. - The first began January 8 and kept traffic near zero for much of the month, with only brief and limited restorations. - A sharp loss of announced IPv6 address space preceded the first traffic collapse, but IPv4 announcements remained relatively stable. This suggests filtering, rather than widespread route withdrawal, was the primary mechanism. - A second shutdown began February 28 as military strikes intensified. - Traffic fell below 1% of normal levels, while small amounts of Web and DNS traffic continued. - Continued IP announcements and limited connectivity support reports of aggressive filtering, including whitelist-based access and restricted “white SIM cards.” - Iran remained largely offline through the end of Q1, making the disruption one of the longest observed in recent years. ### Republic of Congo’s Election Disruption - Internet traffic dropped to near zero around March 15, during the country’s presidential election. - The outage lasted approximately 60 hours before service rapidly recovered on March 17. - Authorities did not provide an official explanation. - Similar election-related shutdowns had occurred in 2016 and 2021. ## Military Action and Infrastructure Damage ### Power-Related Outages in Ukraine - Russian attacks on energy infrastructure caused major connectivity declines in Dnipropetrovsk on January 7–8. - Regional traffic fell nearly 50% before recovering as electricity was restored. - A January 26 drone and missile attack on Kharkiv’s energy infrastructure caused another approximately 50% traffic reduction. - Connectivity gradually recovered on January 27. ### AWS Facilities in the Middle East - Drone strikes damaged Amazon Web Services facilities in the United Arab Emirates and Bahrain. - Two UAE facilities in the me-central-1 region were directly hit. - A Bahrain facility in the me-south-1 region was taken offline after nearby damage. - The incident illustrated that military conflict can affect not only consumer connectivity but also hyperscaler cloud infrastructure. ## Other Causes of Disruption - Cuba experienced three separate collapses of its national electrical grid, causing Internet outages. - Severe weather disrupted connectivity in Portugal. - Cable damage affected service in the Republic of Congo. - Verizon Wireless experienced a technical problem in the United States. - Brief, unexplained disruptions affected providers in Guinea and the United Kingdom. The quarter’s events show that Internet outages increasingly arise from a combination of intentional shutdowns, physical infrastructure damage, power instability, and conflict. Monitoring traffic, routing announcements, and regional infrastructure remains essential for distinguishing the causes and measuring the impact of these disruptions.

Read original(opens in new tab)
CloudflareIpv6Internet DisruptionsData Centers+4
cloudflare3 min readCurated summary

Making Rust Workers reliable: panic and abort recovery in wasm‑bindgen

Rust Workers historically treated Rust panics and aborts as fatal WebAssembly failures, potentially poisoning a Worker instance and causing unrelated requests to fail. Cloudflare’s latest work upstreamed into `wasm-bindgen` adds comprehensive recovery: `panic=unwind` preserves application state after recoverable panics, while abort handling ensures Rust code cannot run again after an unrecoverable abort. ## Initial Recovery Mitigations - Early Rust Workers used a custom panic handler to track failures and reinitialize the entire application before serving later requests. - JavaScript bindings were wrapped with Proxy-based indirection so every Rust entry point passed through recovery logic. - Generated bindings were modified to reinitialize the WebAssembly module after failures. - This approach shipped by default in `workers-rs` 0.6 and prevented persistent failure modes, but reinitialization could discard in-memory state. ## Panic Unwinding with WebAssembly Exception Handling - WebAssembly’s `wasm32-unknown-unknown` target traditionally defaults to `panic=abort`, turning panics into traps and `WebAssembly.RuntimeError` exceptions. - With WebAssembly Exception Handling support, Rust can be compiled using: ```bash RUSTFLAGS='-Cpanic=unwind' cargo build -Zbuild-std ``` - Unwinding allows Rust destructors to run, preserving state and cleaning up resources instead of terminating the entire instance. - `std::panic::catch_unwind` can translate a Rust panic into a recoverable `Result`. ## Changes to wasm-bindgen - The Walrus WebAssembly parser was updated to understand `try`/`catch` exception-handling instructions. - The descriptor interpreter was updated to evaluate code containing exception blocks. - Generated exports now catch Rust panics at the Rust–JavaScript boundary and expose them as `PanicError` exceptions. - Async exports reject their JavaScript promises with `PanicError`. - Exported functions use `extern "C-unwind"` so unwinding is explicitly permitted across the boundary. - A `MaybeUnwindSafe` trait checks `UnwindSafe` requirements only when compiling with `panic=unwind`. - For closures that cannot safely unwind, `Closure::new_aborting` provides an explicit alternative that terminates on panic rather than risking invalid state. ## Results of `panic=unwind` - Panics in exported Rust functions are caught by `wasm-bindgen`. - JavaScript receives a `PanicError`. - Async calls reject their promises instead of poisoning the Worker. - Rust destructors execute correctly. - The WebAssembly instance remains valid and reusable. - Stateful applications, including Durable Objects, can recover without losing all in-memory state. ## Abort Recovery - `panic=unwind` cannot handle aborts such as out-of-memory failures because aborts do not unwind. - The remaining recovery mechanism prevents Rust code from being re-entered after an abort, avoiding repeated execution in a corrupted WebAssembly state. - Together, unwinding and abort recovery prevent one failed request from poisoning sibling or future requests. The recommended approach is to use the latest `wasm-bindgen` and Rust Workers releases, enabling `panic=unwind` where state preservation matters while using explicit aborting closures when unwind safety cannot be guaranteed.

Read original(opens in new tab)
Database DesignRustWebassemblyWasm Bindgen+2
cloudflare3 min readCurated summary

Moving past bots vs. humans

The distinction between bots and humans is becoming too blurry to serve as the foundation of web protection. Browsers, accessibility tools, proxies, and AI agents can all behave differently while representing legitimate users, while human activity can also be malicious. Website owners should instead focus on intent, behavior, resource usage, and trust. ## The Web’s Original Balance - Browsers act as user agents, mediating between people and websites. - Websites rely on browser conventions to: - Present content correctly across devices. - Support purchases, logins, media, and accessibility. - Deliver advertising and control user experiences. - The web has historically balanced publisher interests with user freedoms through browser standards, extensions, and accessibility requirements. - AI agents disrupt this balance by fetching raw content without rendering pages like browsers. - Publishers often cannot tell whether a request supports one private summary or large-scale model training, making traffic and monetization less predictable. ## The Client-Server Model - Clients request resources from servers, which respond with the requested content. - Websites can scale through additional servers, caching, and CDNs. - The model’s openness allows many types of clients to interact with servers without requiring servers to understand their internal software. - That flexibility creates uncertainty: servers generally cannot see whether a response is: - Rendered for one person using a browser. - Automatically collected, archived, indexed, or reused by another system. ## Why Bot Management Exists - Websites must decide which requests they can afford to serve when capacity, CPU, or cost limits are reached. - Randomly dropping requests is possible but risks blocking legitimate users. - Access controls are also used to: - Separate attacks from normal traffic. - Manage non-malicious load. - Prevent data extraction and fake account creation. - Limit ad fraud and automated actions. - Web clients are unauthenticated by default, so services infer identity and intent from partial signals such as request volume and IP addresses. - A high-volume IP may indicate abuse, a VPN, or multiple users sharing one address, making simple bot-versus-human classifications unreliable. ## Toward Intent and Behavior-Based Protection - The important questions are whether traffic represents an attack, whether crawling is proportional to returned traffic, whether a login from a new country is expected, or whether advertisements are being manipulated. - “Bots” encompass two separate concerns: - Whether known crawlers should receive access when they provide little traffic or value in return. - Whether emerging clients behave unlike traditional browsers, affecting systems such as private rate limits. - Automation detection remains necessary, but protection systems should be designed for a future where automation is common among both legitimate and malicious actors. Website protection should evolve from identifying “bots” to evaluating intent, behavior, proportionality, and risk. The goal is not to determine whether a client is human, but whether its activity is expected, sustainable, and trustworthy.

Read original(opens in new tab)
AI AgentsBot ManagementWeb BrowsersZero Trust Security+4
cloudflare3 min readCurated summary

Building the agentic cloud: everything we launched during Agents Week 2026

Cloudflare’s Agents Week 2026 introduced a broad set of infrastructure primitives for building and operating AI agents at scale. The company argues that agents require a new cloud model—“Cloud 2.0”—with elastic compute, built-in security, persistent state, specialized tools, and support for agent-driven web traffic. Its announcements span compute environments, identity and networking, developer tooling, inference, voice, email, and memory. ## Compute for Autonomous Agents - **Artifacts** provides Git-compatible, versioned storage for code and data. It supports tens of millions of repositories, remote forking, and access through standard Git clients. - **Cloudflare Sandboxes**, now generally available, give agents persistent isolated computers with shells, filesystems, and background processes. Environments can start on demand and resume where they left off. - **Outbound Workers for Sandboxes** act as programmable, zero-trust egress proxies. They let developers inject credentials and apply dynamic outbound security policies without exposing secrets to agent-generated code. - **Durable Object Facets** allow dynamically generated Workers to create isolated Durable Objects with their own SQLite databases, enabling stateful applications built on the fly. - **Workflows** was rearchitected to support up to 50,000 concurrent executions and a creation rate of 300, making it more suitable for durable, long-running background agents. ## Security, Identity, and Private Networking - **Cloudflare Mesh** provides private network access for users, infrastructure, Workers, and autonomous agents. Combined with Workers VPC, it enables scoped access to private databases and APIs without manually configured tunnels. - **Managed OAuth for Cloudflare Access** lets agents authenticate to internal applications on behalf of users using RFC 9728 rather than insecure shared service accounts. - New identity controls include scannable API tokens, improved OAuth visibility, and resource-scoped permissions to support least-privilege access and automated credential protection. - Cloudflare outlined an enterprise architecture for governing **MCP** deployments using Access, AI Gateway, and MCP server portals. - **Code Mode** reduces MCP token costs, while new Cloudflare Gateway rules help detect unauthorized or “Shadow MCP” usage. ## The Agent Toolbox - A new preview of the **Agents SDK**, called Project Think, aims to provide a more complete platform for agents that can reason, act, and persist. - An experimental **voice pipeline** supports real-time speech-to-text and text-to-speech over WebSockets, requiring roughly 30 lines of server-side code. - **Cloudflare Email Service** entered public beta, allowing agents to send, receive, and process email as a native communication channel. - Cloudflare’s AI platform is becoming a unified inference layer supporting models from more than 14 providers, including third-party model bindings for Workers and an expanded multimodal catalog. - Cloudflare also described a custom infrastructure stack for serving large language models efficiently on its global network. - **Unweight**, a lossless inference-time compression system, reduces model footprints by up to 22%, improving GPU memory efficiency and potentially lowering inference cost and latency. - **Agent Memory** was introduced as a managed service for giving agents persistent memory, though the provided article excerpt ends before detailing its full capabilities. Cloudflare’s announcements collectively position Workers and related services as a platform for the agentic cloud: one capable of running agents, securing their access, preserving their state, and supplying the models and communication tools they need to operate continuously at Internet scale.

Read original(opens in new tab)
CloudflareDocker & ContainersServerlessGit+4
cloudflare4 min readCurated summary

The AI engineering stack we built internally — on the platform we ship

Cloudflare built an internal AI engineering stack that now supports AI coding tools for 93% of its R&D organization. The system combines centralized authentication and model routing with internal knowledge, automated review, and sandboxed agent execution. Cloudflare argues that building these capabilities on its own platform improved security, visibility, cost control, and developer velocity, while also serving as a proving ground for products it ships publicly. ## Adoption and Impact - Over the previous 30 days: - 3,683 employees used AI coding tools, representing 60% of the company and 93% of R&D. - AI tools generated 47.95 million requests. - 295 teams used agentic AI tools or coding assistants. - AI Gateway handled 20.18 million requests and routed 241.37 billion tokens. - Workers AI processed 51.83 billion tokens. - The four-week rolling average of merge requests increased from roughly 5,600 per week to more than 8,700. - The week of March 23 reached 10,952 merge requests, nearly twice the Q4 baseline. - Cloudflare’s initial focus was MCP servers, but the effort expanded to standards, code review, onboarding, and propagating changes across thousands of repositories. ## Architecture at a Glance Cloudflare organized the stack into three layers: - **Platform layer:** Authentication, model routing, inference, MCP access, and code execution. - **Knowledge layer:** System context and repository guidance through Backstage and `AGENTS.md`. - **Enforcement layer:** Automated quality controls using AI Code Reviewer and the Engineering Codex. The stack uses Cloudflare products including: - **Cloudflare Access** for zero-trust authentication. - **AI Gateway** for centralized LLM routing, cost tracking, bring-your-own-key support, and zero-data-retention controls. - **Workers AI** for open-weight model inference. - **Workers and Access** for an MCP Server Portal with single OAuth. - **Dynamic Workers** for sandboxed agent-generated code execution. - **Agents SDK and Durable Objects** for stateful, long-running agent sessions. - **Sandbox SDK** for isolated cloning, building, and testing environments. - **Workflows** for durable, multi-step processes. - **Backstage** for a 16,000-plus-entity knowledge graph. ## Centralized Authentication and AI Routing - Cloudflare Access authenticates users and enforces zero-trust policies. - Every LLM request passes through AI Gateway, providing a single control point for: - Provider credentials - Usage and cost attribution - Model selection - Data-retention policies - Provider permissions - In the past month, frontier providers handled 91.16% of requests, while Workers AI handled 8.84%. - Cloudflare routes requests through a proxy Worker rather than connecting clients directly to AI Gateway. - The proxy enables later additions such as per-user attribution, model catalogs, permission enforcement, and support for new coding tools without changing client configurations. ## Workers AI and Open-Weight Models - Workers AI runs open-source models on GPUs distributed across Cloudflare’s global network. - Keeping inference on the same network as Workers, Durable Objects, and storage reduces latency, network failures, and cross-cloud configuration. - Kimi K2.5, with a 256,000-token context window, tool calling, and structured outputs, processes more than 7 billion tokens per day for a Cloudflare security agent. - Cloudflare estimates that running this workload on Workers AI is 77% cheaper than using a mid-tier proprietary model. - Workers AI is also used for: - Documentation review in CI - Generating `AGENTS.md` files - Lightweight inference where latency matters more than maximum model capability - Cloudflare expects open-source models to handle an increasing proportion of its internal workloads. ## One-Command Client Configuration - Engineers begin setup with: ```bash opencode auth login https://opencode.internal.domain ``` - The command uses an OpenCode discovery endpoint at: ```text https://opencode.internal.domain/.well-known/opencode ``` - The Worker-hosted endpoint provides authentication and configuration information. - This mechanism is designed to configure providers, models, MCP servers, agents, commands, and permissions without requiring engineers to edit configuration files manually. ## Overall Recommendation Cloudflare’s experience suggests that organizations adopting AI coding tools should build a centralized control plane early: authenticate users consistently, route model traffic through one managed gateway, maintain shared system knowledge, and enforce quality through automated review and isolated execution. Using the same production platform for internal tooling can also expose product gaps and accelerate improvements to the platform itself.

Read original(opens in new tab)
Database DesignCI/CDOpen SourcePostgreSQL+4
cloudflare3 min readCurated summary

Orchestrating AI Code Review at scale

Cloudflare built a CI-native AI code review system to reduce review bottlenecks without overwhelming engineers with noisy or generic model feedback. Instead of using one large prompt, it orchestrates up to seven specialized agents for areas such as security, performance, compliance, and documentation, then uses a coordinator to deduplicate and assess findings. The system now reviews tens of thousands of merge requests, approving clean changes and blocking serious bugs or vulnerabilities. ## Why Naive AI Review Wasn’t Enough - Traditional code review can leave merge requests waiting for hours and creates repeated context switching. - Commercial AI review tools provided useful functionality but lacked the flexibility and customization required across Cloudflare’s organization. - A basic “send the Git diff to an LLM” approach produced: - Vague recommendations - Hallucinated syntax errors - Repetitive advice such as adding error handling where it already existed - Complex codebases required specialized analysis rather than generic summarization. ## Specialized Agents and Coordination - The system launches up to seven focused reviewers covering: - Security - Performance - Code quality - Documentation - Release management - Internal Engineering Codex compliance - A coordinator agent: - Deduplicates overlapping findings - Evaluates the actual severity of issues - Produces one structured review comment - The system can actively block merges when it detects serious defects or security vulnerabilities. ## Plugin-Based Architecture - The platform uses composable plugins so it can support different: - Version-control systems - AI providers - Internal standards - Repository-specific requirements - Each plugin implements a `ReviewPlugin` interface with three lifecycle phases: - `bootstrap`: Runs concurrently and is non-fatal. - `configure`: Runs sequentially and is fatal if essential configuration fails. - `postConfigure`: Handles asynchronous work after configuration assembly. - Through `ConfigureContext`, plugins can: - Register agents and AI providers - Set environment variables - Inject prompt sections - Configure agent permissions - Plugins contribute through the context API rather than accessing the final configuration directly. - The core assembler combines these contributions into `opencode.json`. - This separation prevents unrelated components from becoming tightly coupled; for example, GitLab logic does not need to understand Cloudflare AI Gateway settings. ## Plugin Responsibilities - `@opencode-reviewer/gitlab` - Provides GitLab merge request data and a comment server. - `@opencode-reviewer/cloudflare` - Configures AI Gateway model tiers and fallback chains. - `@opencode-reviewer/codex` - Checks compliance with internal engineering RFCs. - `@opencode-reviewer/braintrust` - Adds distributed tracing and observability. - `@opencode-reviewer/agents-md` - Verifies that repository `AGENTS.md` instructions are current. - `@opencode-reviewer/reviewer-config` - Retrieves remote model overrides for individual reviewers. - `@opencode-reviewer/telemetry` - Tracks reviews asynchronously. ## Why OpenCode - Cloudflare already used OpenCode extensively and understood its behavior. - Its open-source implementation allows engineers to: - Investigate problems directly - Contribute fixes upstream - Extend the system through its SDK - Cloudflare engineers had contributed more than 45 upstream pull requests at the time of writing. - Its server-first design was especially important: - Review sessions can be created programmatically. - Prompts can be sent through an SDK. - Multiple concurrent sessions can be managed without scraping or wrapping a CLI interface. ## Coordinator Process - The coordinator runs OpenCode as a child process using `Bun.spawn`. - Its prompt is passed through `stdin` rather than a command-line argument. - This avoids Linux’s `ARG_MAX` limit, which previously caused `E2BIG` failures for unusually large merge requests containing extensive descriptions or logs. - OpenCode runs with `--format json`, emitting JSONL events through standard output. - This event-based interface allows the orchestration layer to collect and process results from concurrent reviewer sessions. A practical takeaway is to treat AI review as an orchestrated CI system rather than a single LLM prompt. Specialized agents, strict plugin boundaries, structured outputs, and observability are essential for making automated review reliable enough to influence merge decisions at organizational scale.

Read original(opens in new tab)
Database DesignLarge Language ModelsCI/CDGitlab+4
cloudflare3 min readCurated summary

Introducing the Agent Readiness score. Check to see if your site is agent-ready

Cloudflare argues that websites must evolve beyond browser and search-engine compatibility to become usable by AI agents. Its new Agent Readiness score evaluates whether sites support standards for discovery, content access, bot control, and agent capabilities. Early data shows adoption is extremely low, creating both a challenge and an opportunity for sites that adopt these standards early. ## Agent readiness across the web - Cloudflare analyzed the 200,000 most visited domains, excluding categories unlikely to need agent interaction. - The resulting Cloudflare Radar dataset tracks adoption of AI-agent standards and will be updated weekly. - robots.txt exists on 78% of sites, but most files target traditional search crawlers rather than AI agents. - Only 4% of sites declare AI usage preferences through Content Signals. - Just 3.9% support Markdown content negotiation via `Accept: text/markdown`. - MCP Server Cards and API Catalogs based on RFC 9727 appear on fewer than 15 sites, showing how early these standards remain. ## The Agent Readiness score Site owners can test their websites at **isitagentready.com**. Cloudflare scans the site and scores it across four dimensions: - **Discoverability:** robots.txt, sitemap.xml, and Link Headers under RFC 8288. - **Content:** Markdown for Agents. - **Bot Access Control:** Content Signals, AI-specific robots.txt rules, and Web Bot Auth. - **Capabilities:** Agent Skills, API Catalogs, OAuth discovery standards, MCP Server Cards, and WebMCP. - The tool also checks commerce standards such as x402, Universal Commerce Protocol, and Agentic Commerce Protocol, though these do not yet affect the score. - Each failed check includes a prompt that can be handed to a coding agent for implementation. The service itself supports agents through a stateless MCP server with a `scan_site` tool and publishes Agent Skills documents explaining how to implement each supported standard. ## Discoverability for AI agents - robots.txt helps agents understand crawl permissions and locate sitemaps. - Sitemaps provide a structured list of site paths, reducing the need to discover content by following every HTML link. - HTTP Link headers, defined by RFC 8288, expose important resources directly in responses without requiring agents to parse page markup. - Sites can use headers such as `rel="api-catalog"` to point agents toward machine-readable capabilities. ## Making content easier to read - `llms.txt` provides an LLM-oriented reading list at the site root, describing the site and linking to important content in a format designed for model context windows. - Markdown content negotiation lets agents request a clean Markdown version of a page with `Accept: text/markdown`. - Cloudflare measured token reductions of up to 80% compared with HTML, improving speed, cost, and the likelihood that agents can consume an entire document within their context limits. Cloudflare’s recommendation is to evaluate sites with the Agent Readiness tool and adopt the relevant standards incrementally. With current adoption so low, early support can make a site significantly easier for AI agents to discover, understand, authenticate with, and use.

Read original(opens in new tab)
Database DesignAI AgentsCloudflareMarkdown+4
cloudflare4 min readCurated summary

Shared Dictionaries: compression that keeps up with the agentic web

Shared dictionaries address a growing web-performance problem: pages are getting heavier, being rebuilt more frequently, and fetched repeatedly by agents. Instead of retransmitting entire assets after every deployment, servers can compress new versions against files already cached by the browser and send only the differences. The approach could dramatically reduce bandwidth and CPU use, though adoption depends on browser support, security safeguards, and complex server-side implementation. ## The Problem: More Shipping Means Less Caching - Web pages have become 6–9% heavier annually due to frameworks, interactivity, and media. - Agentic crawlers and other automated tools increasingly request full pages; they accounted for nearly 10% of Cloudflare requests in March 2026, up about 60% year over year. - AI-assisted development leads to more frequent deployments and experiments. - Small code changes can cause bundlers to re-chunk assets and generate new filenames, forcing clients to download entire bundles again. - Conventional compression reduces the size of each response but cannot exploit the fact that the client already has most of the previous version. - Frequent deployments therefore create substantial redundant bandwidth and CPU usage. ## How Shared Dictionaries Work - A compression dictionary is shared knowledge between the client and server. - The server compresses a new response using content the client already possesses as a reference. - The client uses that same reference to reconstruct the complete file. - Brotli includes a built-in dictionary of common web patterns, while Zstandard can generate custom dictionaries from representative content. - Gzip lacks a prebuilt or custom dictionary and discovers patterns only during compression. ## Delta Compression for Versioned Assets - Shared dictionaries use the previously cached resource as the compression dictionary. - The initial response includes a `Use-As-Dictionary` header, telling the browser to retain the resource for future compression. - On a later request, the browser sends an `Available-Dictionary` header identifying what it has cached. - The server sends only the differences between the old and new versions. - A 500 KB JavaScript bundle with a one-line change could become only a few kilobytes on the wire. - The technique is especially useful for versioned JavaScript bundles, CSS, framework updates, and other incrementally changing assets. - Each release can use the immediately preceding version as its dictionary, allowing savings to continue across many deployments. - Custom and dynamic dictionaries for non-static content remain an area for future development. ## Lessons from SDCH - Google introduced Shared Dictionary Compression for HTTP (SDCH) in Chrome in 2008. - Although early adopters reported significant performance improvements, SDCH had serious security and architectural issues. - Compression side-channel attacks such as CRIME and BREACH demonstrated that attackers could infer secrets by injecting content and observing compressed response sizes. - SDCH also conflicted with the Same-Origin Policy and CORS because of its cross-origin dictionary model. - Its specification did not adequately define interactions with APIs such as the Cache API. - Chrome removed SDCH in 2017 after adoption failed to materialize. ## The Modern Standard and Remaining Challenges - RFC 9842, Compression Dictionary Transport, addresses major SDCH shortcomings. - Dictionaries are restricted to responses from the same origin, reducing conditions that enabled earlier side-channel attacks. - Chrome and Edge support the standard, while Firefox is working toward support. - Implementing the system requires servers to: - Generate or select dictionaries. - Advertise them with correct headers. - Detect `Available-Dictionary` requests. - Delta-compress responses dynamically. - Fall back cleanly for clients without dictionary support. - Cache behavior becomes more complicated because responses vary by both content encoding and dictionary availability. Cloudflare plans to offer a beta of its shared compression dictionary support on April 30, 2026. The technology is promising for frequently deployed applications and agent-heavy traffic, but broad benefits will depend on cross-browser adoption and careful handling of security and caching complexity.

Read original(opens in new tab)
Web PerformanceHttpDelta CompressionShared Compression+4
cloudflare3 min readCurated summary

Introducing Flagship: feature flags built for the age of AI

AI-generated code is moving toward autonomous production deployment, making safety and controlled rollout essential. The post argues that feature flags provide the guardrails: agents can deploy disabled code, test it with limited cohorts, monitor results, and roll back automatically. Cloudflare’s new Flagship service is designed for this workflow, evaluating flags at the edge through Workers, KV, and Durable Objects. ## Feature Flags for Autonomous Deployment - Agents can ship code behind an off flag without affecting users. - They can enable features for themselves or small test cohorts, observe metrics, and expand or disable rollouts. - Humans define boundaries while flags limit the blast radius. - This separates not only deployment from release, but also routine shipping decisions from constant human attention. ## Problems with Feature Flags on Workers - Hardcoded flags are initially convenient because Workers deploy quickly. - Over time, flags become fragmented across teams, with no central visibility or audit trail. - Troubleshooting may require searching version history with tools such as `git blame`. - Calling an external flag service adds a network request to every user request, potentially introducing significant latency. - This undermines the advantage of running applications close to users at the edge. ## Why Local Evaluation Is Difficult on Workers - Traditional local-evaluation SDKs download rules into a long-lived process. - Worker isolates may be created and evicted between requests, requiring repeated initialization. - Serverless environments therefore need a distribution system with edge-local reads and managed synchronization. - Flagship uses Cloudflare KV to provide this distribution without persistent connections or per-request external calls. ## How Flagship Works - Flagship is built on Workers, Durable Objects, and KV, without external databases or centralized evaluation servers. - Durable Objects provide a globally unique, SQLite-backed source of truth for flag configuration and changelogs. - Changes are synchronized to KV within seconds and replicated throughout Cloudflare’s network. - Evaluations read configuration from KV at the edge and execute targeting and rollout logic inside the Worker isolate. - Both flag data and evaluation logic remain close to the request. ## Worker Binding and Typed Evaluation - Workers connect Flagship through a `wrangler.jsonc` binding containing a binding name and `app_id`. - The binding supports typed methods including: - `getBooleanValue()` - `getStringValue()` - `getNumberValue()` - `getObjectValue()` - `*Details()` methods return the value, matched variant, and selection reason. - Evaluation errors return the supplied default value. - Type mismatches throw exceptions because they indicate application bugs rather than temporary service failures. ## OpenFeature Integration - Flagship is built on OpenFeature, the CNCF standard for feature-flag evaluation. - It supports Workers as well as Node.js, Bun, Deno, and browser environments. - The service is currently available in closed beta. Flagship is positioned as an edge-native feature-flag system for safely automating deployment and rollout. For Cloudflare Workers, its direct binding avoids network round-trips while providing centralized configuration, targeting, auditability, and controlled release mechanisms.

Read original(opens in new tab)
Database DesignCloudflare WorkersSqliteEdge Computing+4
cloudflare3 min readCurated summary

Agents that remember: introducing Agent Memory

Cloudflare’s Agent Memory is a managed, retrieval-based service designed to give AI agents persistent memory without continuously expanding their context windows. It addresses context rot by extracting useful information from conversations, retaining it across sessions, and retrieving synthesized answers when needed. The service is intended for production agents that run for weeks or months, where fast ingestion, affordable retrieval, and durable knowledge matter more than benchmark performance alone. ## The Challenge of Agent Memory - Larger context windows—even beyond 1 million tokens—do not eliminate context rot; excessive context can reduce model quality. - Aggressive pruning creates the opposite risk: removing information the agent may need later. - Existing memory systems vary widely: - Managed services versus self-hosted frameworks - Raw database or filesystem access versus purpose-built APIs - Full-context approaches versus retrieval-based systems - Benchmarks such as LongMemEval, LoCoMo, and BEAM help compare systems but may encourage overfitting to clean datasets that do not reflect long-running production workloads. ## Cloudflare’s Retrieval-Based Approach - Agent Memory is a managed service with an opinionated API. - It extracts and retrieves relevant information instead of exposing agents directly to a filesystem or database. - This approach is intended to: - Reduce token usage and cost - Improve retrieval performance - Support temporal reasoning, supersession, and instruction following - Keep memory operations out of the agent’s main reasoning context - Cloudflare expects programmatic querying to be useful for specialized edge cases, but not as the default interaction model. ## Memory Profiles and Core Operations Memory is organized into named profiles that can be shared across sessions, agents, and users. - `ingest`: Processes a conversation and extracts memories, typically during context compaction. - `remember`: Stores one important fact explicitly, often through direct model tool use. - `recall`: Runs the full retrieval pipeline and returns a synthesized response. - `list`: Lists stored memories. - `forget`: Removes a specific memory. For example, an agent can ingest a conversation containing a user’s preference for pnpm and dark mode, explicitly remember an operational fact such as an increased API rate limit, and later recall that the user prefers pnpm over npm. ## Integration and Supported Architectures - Agent Memory is available through a binding in Cloudflare Workers. - Agents running outside Workers can use the REST API. - The Cloudflare Agents SDK integrates it with session compaction, memory creation, and retrieval. - It can support: - Individual coding or personal agents - Self-hosted frameworks and managed agent services - Autonomous background agents that must survive restarts - Custom agent harnesses - Shared knowledge between engineers, agents, and tools - Shared profiles can preserve coding conventions, architectural decisions, and other organizational knowledge that might otherwise be lost during context pruning. ## Practical Recommendation Agent Memory is positioned as a default persistent-memory layer for production agents: use ingestion during compaction, explicit remembering for critical facts, and retrieval when the agent needs historical context. Its private beta is particularly aimed at long-running, multi-session workloads where maintaining useful memory is more important than simply fitting more text into the context window.

Read original(opens in new tab)
ReactTypeScriptCloudflare WorkersAPI Design+3
cloudflare3 min readCurated summary

Redirects for AI Training enforces canonical content

Cloudflare argues that AI training crawlers often ignore deprecation notices, `noindex`, and canonical tags, causing outdated documentation to enter training data. Its new Redirects for AI Training feature converts qualifying canonical tags into HTTP 301 redirects for verified AI training bots, sending them to current content instead. The feature is intended to enforce content freshness without affecting human visitors, search crawlers, or AI agents. ## The Problem with Deprecated Content - Cloudflare’s older Wrangler documentation includes deprecation banners, `noindex`, and canonical tags. - AI training crawlers consumed deprecated and current documentation at roughly the same rate. - Unlike humans, crawlers may ingest the entire page, treating warnings as ordinary text. - Blocking crawlers with `robots.txt` creates a dead end and does not tell them where the replacement content is. - Outdated content can persist in trained models even after the original page has been updated. ## Canonical Tags as Redirect Instructions - The HTML `<link rel="canonical">` tag identifies the authoritative version of a page. - Canonical tags appear on an estimated 65–69% of websites and are often generated automatically by CMS platforms. - Cloudflare’s feature uses this existing content hierarchy rather than requiring separate redirect rules. - For verified AI training crawlers, a non-self-referencing canonical becomes an HTTP `301 Moved Permanently` redirect. ## How Redirects for AI Training Works - Cloudflare identifies eligible requests using `cf.verified_bot_category`. - The AI Crawler category includes bots such as GPTBot, ClaudeBot, and Bytespider. - Cloudflare inspects the requested page’s HTML: - If it has a canonical URL on the same domain, the crawler is redirected there. - Self-referencing canonicals do not trigger redirects. - Cross-origin canonicals are excluded. - Human traffic, search crawlers, and AI Assistant or AI Search bots are unaffected. ## Limitations and Alternatives - The feature cannot remove outdated material already ingested into training datasets. - It does not cover unverified crawlers. - AI Agents visiting deprecated pages are not redirected. - Traditional redirect rules can work for a small number of paths, but they require manual maintenance, user-agent tracking, and rule capacity. - Canonical-based enforcement stays aligned with content changes automatically. ## Cloudflare’s Documentation Test - In March 2026, legacy Workers documentation received thousands of crawls from OpenAI, Anthropic, and Meta. - An AI assistant provided the deprecated Wrangler syntax `kv:key put` instead of the current `wrangler kv key put`. - After enabling the feature, 100% of AI training crawler requests for pages with non-self-referencing canonicals were redirected during the first seven days. - Cloudflare expects this to improve future AI answers, though the impact depends on training pipelines and recrawl timing. ## Enabling the Feature - In the Cloudflare dashboard, go to **AI Crawl Control → Quick Actions → Redirects for AI training** and enable the toggle. - Path-specific controls are available through Configuration Rules and Cloudflare for SaaS. - Cloudflare also added AI crawler response-status analysis to Radar’s AI Insights page, covering 2xx, 3xx, 4xx, and 5xx responses. Website owners with canonical tags can use the feature to automatically steer verified AI training crawlers toward current content. It is most useful for sites with frequently changing documentation and many deprecated URLs, but it should complement—not replace—ordinary redirects, access controls, and content maintenance.

Read original(opens in new tab)
CloudflareAi TrainingRobots.TxtHttp 301+4
cloudflare3 min readCurated summary

Unweight: how we compressed an LLM 22% without sacrificing quality

Unweight is Cloudflare’s lossless compression system for LLM weights, reducing model size by 15–22% while preserving bit-exact outputs. It targets the memory-bandwidth bottleneck in GPU inference by compressing weights in HBM and decompressing them directly into fast on-chip memory before tensor-core computation. On Llama-3.1-8B, the approach saves roughly 3 GB of VRAM and enables more models to run per GPU. ## The GPU Memory Bottleneck - LLM inference is often limited by memory bandwidth rather than computation. - Each generated token requires reading the model’s weights from GPU high-bandwidth memory (HBM). - NVIDIA H100 tensor cores can process data far faster than HBM can supply it. - Smaller weights reduce the amount of data transferred across the memory bus. - Decompression must be carefully integrated: if it adds latency that cannot overlap with matrix multiplication, token generation becomes slower. ## Why Lossless Compression Matters - Quantization commonly converts 16-bit values into 8- or 4-bit integers. - Because quantization is lossy, it can change model behavior and response quality unpredictably. - Unweight instead preserves exact outputs and does not require specialized hardware. - Existing systems were unsuitable because they focused on CPU decompression, custom FPGA hardware, or consumer GPUs rather than Hopper-generation GPUs and production inference. ## Compressing BF16 Weights - BF16 values contain: - A sign bit - An 8-bit exponent - A 7-bit mantissa - Sign and mantissa values appear largely random and are difficult to compress. - Exponents are highly predictable: the 16 most common exponent values account for more than 99% of weights in a typical layer. - Unweight applies Huffman coding to exponent bytes while leaving sign and mantissa bits unchanged. - Rare exponents are handled by storing an entire row of 64 weights verbatim, avoiding per-element branching during decoding. ## Selective Compression of Model Layers - Unweight compresses the MLP gate, up, and down projection matrices. - These matrices represent roughly two-thirds of model parameters and generate substantial memory traffic during decoding. - Attention weights, embeddings, and layer norms remain uncompressed. - The exponent compression produces about 30% savings in the targeted streams and approximately 20% reduction in total MLP weight size. - Overall model-size reductions reach 15–22%. ## Direct GPU Decompression - Model weights normally reside in large but slower HBM and are staged into small, fast shared memory before computation. - Conventional approaches decompress full matrices back into HBM and then run standard matrix multiplication, creating additional memory traffic. - Unweight decompresses weights in shared memory and feeds them directly to tensor cores. - Different execution strategies are used depending on the weight matrix and batch size. - An autotuner selects the fastest strategy for each workload. ## Results and Availability - Tests on Llama-3.1-8B achieved: - Around 30% compression for MLP weights - 15–22% reduction in total model size - Approximately 3 GB of VRAM savings - The savings allow more models to fit on each GPU, potentially reducing inference cost and improving global deployment coverage. - Cloudflare is publishing a technical paper and open-sourcing the GPU kernels. Unweight demonstrates that lossless, inference-time compression can improve GPU utilization without changing model behavior. The practical recommendation is to compress the portions of a model that dominate memory traffic while integrating decoding directly into the GPU execution path.

Read original(opens in new tab)
Database DesignLarge Language ModelsRustModel Inference+4
cloudflare2 min readCurated summary

Agents Week: network performance update

Cloudflare reports that it became the fastest network in 60% of the world’s 1,000 largest networks by December 2025, up from 40% during Birthday Week 2025. The improvement came from both expanding its global points of presence and optimizing connection-handling software. Cloudflare says it is continuing to target the remaining networks where competitors still lead. ### Measuring Network Performance - Cloudflare analyzes the 1,000 largest networks by estimated population, using APNIC data. - It measures TCP connection time—the time required to complete a TCP handshake—as a practical indicator of users’ perceived Internet speed. - Rankings use the **trimean**, a weighted average of the 25th percentile, median, and 75th percentile, reducing the influence of outliers. - Data comes from Real User Measurements: browsers loading Cloudflare error pages silently download small files from Cloudflare, Amazon CloudFront, Google, Fastly, and Akamai under real network conditions. ### Expanding Points of Presence - New locations in Constantine, Algeria; Malang, Indonesia; and Wroclaw, Poland brought Cloudflare physically closer to users. - In Wroclaw, free-user average round-trip time fell from 19 ms to 12 ms, a 40% improvement. - In Malang, Enterprise traffic improved from 39 ms to 37 ms, a 5% reduction. - However, new locations alone did not account for the increase from 40% to 60% of networks. ### Improving Connection Handling - Cloudflare optimized the software responsible for connection establishment, SSL/TLS termination, traffic management, and proxying. - HTTP/3 adoption and changes to congestion-window management reduced processing time. - Improvements in CPU and memory efficiency allow the global network to handle connections more effectively. - Cloudflare compares this to improving both the efficiency of highway toll booths and the routing of traffic between them. ### Results by December 2025 - Cloudflare was the fastest provider in 60% of the largest networks. - Between September and December 2025, it became fastest in: - 40 additional countries - 261 additional networks - 54 additional U.S. autonomous systems (ASNs) - During December, Cloudflare was on average 6 ms faster than the next-fastest provider. Cloudflare’s conclusion is that continued gains in network reach and software efficiency can produce measurable improvements for users. It plans to focus on the remaining networks where it is narrowly behind competitors, with the long-term goal of being fastest worldwide.

Read original(opens in new tab)
CloudflareHttp3Network PerformanceLatency Optimization+4