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

The post-quantum EO is an important milestone. Now it’s time to get to work

The post welcomes Executive Order 14409 as a major step toward post-quantum security, setting federal deadlines of 2030 for encryption and 2031 for authentication. It argues that the threat timeline has accelerated and that organizations must begin migration now, especially to prevent “harvest-now-decrypt-later” attacks. Cloudflare views the order as a strong foundation but believes agencies need clearer guidance and a coordinated migration roadmap. ## Federal Post-Quantum Requirements - The order primarily covers: - **High Value Assets (HVAs)**, such as systems containing sensitive employee records, classified intelligence, or federal financial data. - **High impact systems** rated “high” under FIPS 199, where compromise could cause severe harm. - Key deadlines include: - **July 2026:** Agencies name a post-quantum migration lead. - **September 2026:** Agencies inventory HVAs and high-impact systems, create migration plans, and submit them to OMB and the National Cyber Director. - **December 2030:** Key establishment must use post-quantum cryptography. - **December 2031:** Digital signatures and certificates must use post-quantum cryptography. - National Security Systems are excluded from these deadlines and remain on a separate NSA-managed schedule. - The order directly binds federal agencies, not state and local governments, critical infrastructure, academia, or civil society. ## Encryption and Authentication Are Separate Migrations - **Post-quantum encryption** protects key establishment and should begin immediately. - It prevents attackers from collecting encrypted data now and decrypting it after quantum computers become capable of breaking RSA and elliptic-curve cryptography. - This is especially important for government, financial, healthcare, defense, and telecommunications data with long-term value. - **Post-quantum authentication** protects digital signatures, certificates, software signatures, and system access. - It prevents future quantum computers from impersonating servers or forging trusted signatures. - Its primary threat emerges once a cryptographically relevant quantum computer exists. - The order’s 2031 authentication deadline suggests the U.S. government considers an operational quantum computer around that period a meaningful possibility. ## Standardized Cryptography Over Quantum Key Distribution - The order emphasizes NIST-standardized post-quantum algorithms. - The authors support this focus because Quantum Key Distribution requires specialized hardware and dedicated physical links, making it unsuitable for Internet-scale deployment. - Cloudflare reports that more than two-thirds of browser traffic reaching its network already uses post-quantum encryption. - Its Cloudflare One platform supports post-quantum protection across TLS, MASQUE, and IPsec, while broader post-quantum authentication deployment is still beginning. ## Why Authentication Is More Difficult - Post-quantum ML-DSA signatures are larger than traditional signatures, potentially reducing performance in systems such as short-lived TLS connections. - Cloudflare is working with Google Chrome on Merkle Tree Certificates to reduce this TLS overhead. - Authentication requires coordinated upgrades across a larger ecosystem: - Clients and servers - Certificate authorities - Certificate transparency logs - Root stores - Web browsers - By comparison, post-quantum key establishment is already more widely available and easier to deploy incrementally. Organizations should begin with asset inventories, risk assessments, and post-quantum key-establishment upgrades now rather than waiting for the federal deadlines. Authentication migration should also start early because its broader dependency chain and larger signatures make it the more complex transition.

Read original(opens in new tab)
Post Quantum CryptographyQuantum ComputingCryptographyElliptic Curve Cryptography+3
cloudflare3 min readCurated summary

How we found a bug in the hyper HTTP library

The Images binding’s migration to a local Unix-socket architecture exposed a rare race condition in Rust’s `hyper` HTTP library. Under slow-reader conditions, large image responses were truncated even though they returned `200 OK` and a full `Content-Length`, causing downstream processing or image decoding to fail. After six weeks of investigation, the issue was traced to premature socket shutdown and fixed with four lines of code. ## Images Bindings and the Request Path - Cloudflare’s Images service runs on Workers and uses `hyper` to manage HTTP connections. - The Images binding lets Workers send image data directly to the service, chain transformations, and receive the processed result as a stream. - The response path involved: - The Images service generating the complete encoded image. - `hyper` buffering the response. - Data moving through socket buffers managed by the kernel. - A client or intermediary reading the response. - If the reader was fast, `hyper` could flush the entire response and safely shut down the socket. - If the reader was slower, the socket’s outbound buffer filled, requiring `hyper` to pause and resume writing. ## Moving from FL to Local Unix Sockets - Initially, binding traffic passed through Cloudflare’s FL intermediary service. - In December 2025, the Images team replaced FL with an internal binding running on the same machine. - Unix sockets removed network and FL-processing overhead, including routing and DNS work. - The redesign improved performance and allowed the Images team to release binding changes independently. - The bug appeared within days of the rollout. ## Successful Responses with Truncated Bodies - The first report involved nested image-processing pipelines: - An inner Images binding composited large JPEG and PNG inputs from R2. - An outer URL-based pipeline resized, compressed, and transcoded the result. - The inner pipeline returned `200 OK` and a `Content-Length` for several megabytes, but delivered only a fraction of the body. - One response contained roughly 200 KB instead of the expected 3.3 MB. - The outer pipeline reported an end-of-file error because the body ended before the declared message length. - Depending on the image format, clients saw partially rendered images or completely broken images. ## Reproducing and Isolating the Race - Engineers recreated the nested setup, then removed layers until the failure occurred with the binding alone. - Batch testing produced failures reliably—for example, 19 of 25 requests in one run. - The amount of data received, approximately 200 KB, closely matched the production socket-buffer size. - This indicated that the failure was related to backpressure and socket-buffer exhaustion rather than the customer’s specific configuration. - Investigation eventually identified a race in `hyper` where the connection could be shut down before buffered response data had finished flushing. The incident demonstrates that HTTP success status codes do not guarantee complete response bodies when connection handling is incorrect. Systems streaming large payloads over sockets should test slow-reader and backpressure scenarios, and libraries should only close connections after all buffered data has been written.

Read original(opens in new tab)
Cloudflare WorkersRustHttpRace Condition+2
cloudflare2 min readCurated summary

Temporary Cloudflare Accounts for AI agents

Cloudflare introduced Temporary Cloudflare Accounts for AI agents, allowing them to deploy Workers without human-driven signup or authentication. With `wrangler deploy --temporary`, an agent receives a temporary account, API token, and deployment URL, then has 60 minutes to claim the account. If unclaimed, the account and its resources are automatically deleted. ## Why Frictionless Deployment Matters - Background agents often operate without a human available to complete OAuth, copy tokens, or approve MFA. - Temporary deployments support the agent’s rapid write → deploy → verify iteration cycle. - Throwaway environments let agents test code cheaply and independently. - Agent platforms increasingly need deployment workflows that work without requiring users to create accounts on unfamiliar services. ## How Temporary Accounts Work - The feature is integrated into Wrangler, Cloudflare’s CLI for creating, configuring, and deploying projects. - When an unauthenticated deployment encounters the normal signup barrier, Wrangler informs the agent about the `--temporary` option. - Running `wrangler deploy --temporary` provisions: - A temporary Cloudflare account - An API token for Wrangler - A claim URL that can be returned to the user - The temporary account can be reused for multiple deployments during the 60-minute window. ## Agent Deployment and Iteration - An agent can create a TypeScript “Hello World” Worker, deploy it, and use the returned preview URL to verify the result. - It can then modify the source and redeploy without repeating account setup. - Agents can use this loop to test and refine applications autonomously. ## Claiming or Expiring the Account - Users can open the claim link, sign up for or sign in to Cloudflare, and permanently take ownership of the temporary account. - Claiming includes associated Workers, databases, and other bindings. - Unclaimed accounts are automatically deleted after 60 minutes. ## Broader Agent Provisioning Efforts - Cloudflare is also working with Stripe on protocols for agents to create accounts, start subscriptions, register domains, and obtain deployment credentials without manual token or payment entry. - Its collaboration with WorkOS on `auth.md` aims to support agent-driven account creation through established OAuth standards. - Temporary accounts are positioned as one step toward making Cloudflare and other services easier for AI agents to use. Developers should update Wrangler and try `wrangler deploy --temporary` for autonomous, short-lived deployments, while consulting Cloudflare’s documentation for current limitations.

Read original(opens in new tab)
AI AgentsTypeScriptCloudflare WorkersStripe+4
cloudflare3 min readCurated summary

Build your own vulnerability harness

A scalable AI vulnerability program should be built around a model-agnostic harness rather than a single model, prompt, or agent session. The harness must preserve state, support resumable investigations, cross-check findings with different models, and trace issues across repositories. The authors recommend starting small with database-backed Recon, Hunt, and Validate stages, expanding only when operational bottlenecks justify it. ## Why a Harness Is Needed - Generic coding agents are poorly suited to large-scale security analysis because they: - Hold only one hypothesis at a time. - Exhaust their context windows while exploring real repositories. - Lose important information during context compaction. - Subagents help, but they do not provide the persistence, deduplication, resumability, and cross-run coordination required for security investigations. - The system should treat models as interchangeable components: - One model can discover vulnerabilities. - Another can independently validate them. - Different models expose different classes of bugs and reduce shared blind spots. - The harness, rather than any particular frontier model, is intended to be the durable investment. ## The Original Security-Audit Skill The authors began with an approximately 450-line skill designed to audit one repository in a single session. Its seven-phase workflow included: - Three parallel reconnaissance agents producing `architecture.md`. - Hunter agents attacking the code by vulnerability class. - Adversarial validators attempting to disprove findings. - A human-readable vulnerability report for surviving findings. - A schema-checked `findings.json` file. - Mechanical validation of referenced functions and line numbers. - A fresh agent independently re-verifying every finding before submission to an ingest API. This skill became the blueprint for the later pipeline: - Recon agents became the Recon stage. - Attack-class hunters became Hunt. - Adversarial reviewers became Validate. - Reports became structured findings. - Independent re-verification remained a separate validation step. ## Limitations of Single-Session Audits A single run found only about half of the bugs discovered across multiple runs, and it tended to find simpler vulnerabilities rather than subtle ones. Repeating the skill many times and manually diffing results quickly became impractical. The authors identified three major bottlenecks: - **Context exhaustion:** Long sessions cause the model to forget previously investigated bugs. The solution is to externalize state and use the model as a stateless computation engine. - **Poor persistence:** Crashes, rate limits, and connection failures can erase hours of progress if work is not stored incrementally. - **Lack of cross-repository reasoning:** Auditing one repository in isolation misses vulnerabilities at the interfaces between applications and shared components. ## Recommended Minimal Architecture The authors advise building only the infrastructure needed to address current problems: - Store Recon, Hunt, and Validate stages in a database. - Use a separate validator that cannot submit its own findings, reducing confirmation bias. - Defer cross-repository tracing until multiple important repositories need to be analyzed together. - Defer a dedicated deduplication agent until the system produces too much duplicate or low-quality output. - Begin with a well-tuned development skill, then add pipeline stages only when a specific limitation is slowing the work. ## Enterprise-Scale Direction A mature vulnerability harness should continuously scan a fleet of repositories, trace dependencies across them, and reduce thousands of raw candidates to a smaller queue of verified, actionable fixes. Frequent model interchange and independent validation are central to maintaining coverage as models change or become unavailable. The practical recommendation is to invest first in durable orchestration and state management, not allegiance to a particular model. A simple, resumable Recon–Hunt–Validate pipeline is the appropriate starting point, with cross-repository analysis and advanced deduplication added only as scale demands.

Read original(opens in new tab)
AI AgentsVulnerability ScanningSecurity AuditLlm Orchestration+3
cloudflare3 min readCurated summary

Celebrating 12 years of Project Galileo

Project Galileo, launched by Cloudflare 12 years ago, provides free cybersecurity services to more than 3,400 civil society websites across 120 countries. Its anniversary report shows that journalists, human rights groups, and nonprofits face more frequent and intense attacks than other Internet users, especially during politically sensitive work. Cloudflare is responding with expanded research, case studies, partnerships, and a call for accessible security protections. ## Project Galileo’s Mission and Reach - The program protects journalists, human rights defenders, and nonprofit organizations from being forced offline. - It now supports more than 3,400 websites in 120 countries. - Cloudflare’s global network spans more than 335 cities in 125 countries, with over 20% of the web behind its infrastructure. ## Cyberattacks Targeting Civil Society Cloudflare’s first comprehensive annual report compares threats against civil society with attacks against Internet users more broadly. - DDoS attacks were the most common threat, often lasting for days or weeks. - Civil society organizations faced website vulnerability exploitation attempts at more than seven times the rate of other Cloudflare customers. - Media organizations were especially affected. - Journalists working in exile received nearly four times more malicious traffic than journalism organizations overall. - Almost 10% of emails processed for civil society organizations contained potential phishing material. - Attacks often coincided with investigative reporting, public advocacy, or other critical organizational activities. Cloudflare calls for affordable cybersecurity, greater transparency around cyberattacks and Internet shutdowns, and default integration of AI-aware and post-quantum protections. The company plans to publish the report annually to track changing threat patterns. ## Case Studies of Project Galileo Participants Sixteen case studies illustrate the varied security needs of participating organizations, including: - Digital rights groups such as SHARE Foundation. - Investigative and independent media organizations, including OCCRP, elTOQUE, and China Digital Times. - Organizations documenting conflict and human rights abuses, such as Ukraine War Archive. - Research and public-interest institutions including Our World in Data and the Bulletin of Atomic Scientists. - Environmental, legal, scientific, and humanitarian groups such as Sea Shepherd Brazil, Activist Rights, and the Royal Meteorological Society. ## Expanding the Partner Network Project Galileo depends on 59 civil society partners that review and approve applications. - Partners contribute local expertise and help identify organizations that need protection. - Previous collaborations produced initiatives such as email security with Protect.ngo and Internet measurement work through UNICEF’s Giga project. - Cloudflare has focused on expanding access beyond North America and Europe through regional events and partnerships. - Recent Asia-Pacific partners include EngageMedia and the OpenCulture Foundation. - The anniversary announcement introduces three additional partners serving journalists, including the International Center for Journalists and Media Cluster Norway. Project Galileo’s next phase combines threat intelligence, direct protection, regional partnerships, and specialized services for journalism organizations. Its broader recommendation is that reliable cybersecurity should be treated as essential infrastructure for civil society and public discourse.

Read original(opens in new tab)
AIPost Quantum CryptographyCybersecurityDdos+3
cloudflare3 min readCurated summary

Bringing more agent harnesses to Cloudflare, starting with Flue

Cloudflare argues that production AI agents need more than an agent harness: they require platform primitives for durable state, execution, storage, and secure compute. It presents a three-layer stack—framework, harness, and runtime—and introduces Flue as the first framework built on the Cloudflare Agents SDK. Flue uses a declarative approach based on Pi, while Cloudflare supplies the infrastructure needed to resume interrupted work and run agents reliably at scale. ## The Three-Layer Agent Stack - **Framework — Flue** - Provides project structure, conventions, integrations, CLI commands, and developer experience. - **Harness — Pi or Project Think** - Runs the agentic loop: calls tools, processes results, manages context, and continues until a task is complete. - **Runtime/platform — Cloudflare Agents SDK** - Supplies compute, state, storage, durable execution, sandboxing, and workflow primitives. - Cloudflare’s goal is to make these runtime capabilities available to any harness or framework. ## Flue’s Declarative Agent Model - Flue 1.0 Beta is built on the Pi harness, which also powers OpenClaw. - Developers describe what an agent knows rather than explicitly scripting its orchestration. - An agent is defined through its: - Model - Skills - Sandbox - Instructions - This allows relatively compact agents to autonomously handle tasks such as reproducing and diagnosing bug reports. ## Flue’s Developer Experience - **Integrated channels** - Preconfigured integrations let agents work in Slack, GitHub, Linear, and Discord. - Channels handle event verification and dispatch boilerplate. - **Headless and UI-ready operation** - Agents can run as background processes. - `@flue/react` provides hooks for streaming agent state, tool execution, and messages into frontend applications. - **Ecosystem integrations** - Commands such as `flue add channel slack` generate Markdown blueprints that coding agents can modify and integrate into a project. ## Durable Execution with Durable Streams - Production agents face host crashes, LLM API timeouts, restarts, and interrupted tool calls. - Flue records prompts, tool responses, model decisions, and other execution events in an append-only log. - This durable event history prevents in-memory state from being lost. - If a process fails, another process can replay the log and resume from the exact point of interruption. ## Deployment Across Clouds - On Node.js, Flue agents run as long-lived processes on VMs, containers, GitHub Actions, or existing servers. - On Cloudflare, each agent runs in its own Durable Object. - This provides: - Isolated storage and compute - Automatic scaling - No need to provision servers or manage sticky sessions - Protection from noisy neighbors - Cloudflare deployments use Agents SDK features including `runFiber()`, `stash()`, and `onFiberRecovered()` for durable execution. - Sandboxed code execution uses `@cloudflare/codemode` and `@cloudflare/shell` with a durable workspace. ## Requirements for Production Agent Harnesses - An agent turn is a multi-step process that may involve token streaming, tool calls, human approval, or delegated subagents. - These operations can last seconds or minutes and may fail at any point. - Persisting only conversation history is insufficient because it does not preserve active execution state, pending tool calls, or the agent’s current position. - Cloudflare’s fiber-based primitives provide checkpointing so interrupted agent turns can recover instead of leaving users with stalled requests. Cloudflare’s recommendation is to treat the framework, harness, and runtime as separate but coordinated layers. Frameworks like Flue make agents easy to build, while the Agents SDK supplies the durable execution and infrastructure primitives required to operate them reliably in production.

Read original(opens in new tab)
Durable ObjectsCloudflare Agents SdkDurable ExecutionFlue+3
cloudflare3 min readCurated summary

Introducing the Cloudflare One stack- agent-powered deployment

Cloudflare’s One stack is a pair of agent skills designed to help organizations evaluate, migrate to, deploy, and operate Cloudflare One Zero Trust environments. It combines expert-curated guidance, migration logic, decision trees, and API tooling so agents can understand existing networks, recommend architectures, and safely implement changes. The goal is to reduce migrations that traditionally take months to a more guided and automated process. ## The Challenge of Zero Trust Migration - Teams must first understand their existing environment, including: - Applications and connectivity requirements - Authentication and authorization policies - Traffic flows - Assumptions embedded in current security and routing rules - Agents can automate many security workflows, but lack organization-specific knowledge about network topology and vendor configurations. - Cloudflare’s stack supplies the structured context and prescriptive guidance needed for agents to work more effectively with security infrastructure. ## What the Cloudflare One Stack Provides - The stack consists of two lightweight skill files: - `cloudflare-one` for general Cloudflare One planning, deployment, management, and troubleshooting - `cloudflare-one-migration` for translating and migrating from legacy SASE vendors - It incorporates knowledge gathered from Cloudflare employees with extensive customer deployment experience. - When combined with Cloudflare’s code mode MCP server, agents receive a typed interface to the Cloudflare API. - Agents can inspect live accounts and make changes through Cloudflare-recommended workflows rather than arbitrary API calls. ## Covered Cloudflare One Capabilities - VPN replacement and remote access through Cloudflare Access - User, device, network, and data security through Cloudflare Gateway - Connectivity using Cloudflare Tunnel, Mesh, and WAN - Migration from vendors such as Zscaler and Palo Alto Networks - Network diagram interpretation and generation - Translation of concepts between competing SASE platforms - Troubleshooting and operations using Digital Experience Monitoring and automated rule recommendations ## Guided Deployment and Migration - For VPN replacement, the agent can: - Inventory existing VPN applications - Determine the required connectivity model - Map applications to Access, Tunnel, or Mesh - Recommend a deployment sequence that reduces cutover disruption - Produce a configuration summary for human review - For Zscaler Private Access migrations, the agent can: - Convert application definitions into Cloudflare Access applications - Translate user groups and policies - Create equivalent resources through the Cloudflare API - Summarize completed work and identify items needing manual review - The migration logic is based on Cloudflare’s Descaler and Deskope programs, which have migrated enterprise customers from Zscaler and Netskope in hours rather than months. ## Operations and Troubleshooting - The stack can recommend security rules based on live account traffic. - It can automatically migrate Zscaler Private Access applications into self-hosted Cloudflare Access applications. - Agents can investigate anomalies in secure web gateway HTTP logs and create rules to address user issues. - The Digital Experience Monitoring toolkit can report on user stability and help improve latency in important scenarios. Cloudflare positions the One stack as a way to make Zero Trust deployment more accessible and repeatable. Organizations can use the skills with their existing agents, add internal context, and combine them with API tooling—but should still review generated plans and configurations before applying changes.

Read original(opens in new tab)
Model Context ProtocolZero TrustSaseCloudflare Access+4
cloudflare3 min readCurated summary

Cloudflare DMARC Management is now generally available

Cloudflare DMARC Management is now generally available as a free service for Cloudflare customers. Its redesigned dashboard helps organizations understand email authentication, investigate sending sources, and safely move from monitoring to full DMARC enforcement. The goal is to reduce spoofing and improve deliverability without requiring consultants or manual XML report analysis. ## Why Email Authentication Matters - **SPF** identifies the servers and services authorized to send mail for a domain. - **DKIM** adds a cryptographic signature so recipients can verify message integrity. - **DMARC** combines SPF and DKIM results and determines whether failed messages should be delivered, quarantined, or rejected. - **BIMI** can display a brand logo in supported inboxes when a domain has a sufficiently strong DMARC policy. - Correctly configured records help block spoofed messages and improve legitimate email delivery. ## DMARC Has Become Essential - Google, Microsoft, and Yahoo have introduced stricter authentication requirements. - Domains with missing or incorrect SPF, DKIM, or DMARC records increasingly face spam placement or outright rejection. - Poor email authentication can lead to brand impersonation, missed communications, and lost revenue. ## The Risks of Reaching Enforcement - DMARC policies typically progress from: - `p=none`: monitor activity without blocking messages - `p=quarantine`: send suspicious messages to spam - `p=reject`: block unauthenticated messages - Tightening the policy too quickly can disrupt legitimate mail from forgotten third-party services. - Moving too slowly leaves the domain vulnerable to spoofing and deliverability problems. - Organizations must analyze aggregate XML reports and identify every legitimate sending source before enforcing stricter policies. ## Deeper Report Visibility and Source Investigation - Reports now show: - Source IP addresses - Sending service names - DMARC, SPF, and DKIM alignment results - Users can open an IP address in Cloudflare’s Investigate tab to view: - Reputation data - Geolocation - ASN information - Known malicious associations - This turns DMARC reports into an investigation tool for distinguishing legitimate infrastructure from unauthorized senders. ## Unified Authentication Record Status - A single view reports the status of DMARC, DKIM, SPF, and BIMI records. - Each record receives a pass, warning, or fail result based on automated analysis. - The dashboard identifies issues such as: - Multiple SPF records - SPF lookup-limit problems - Permissive `+all` settings - Missing SPF mechanisms - Malformed DKIM keys - Missing BIMI records when the domain qualifies for one - Recommendations are presented in plain language with actionable remediation steps. Cloudflare’s recommendation is effectively to use DMARC Management to identify all sending sources, correct authentication records, and gradually move toward `p=reject` with greater confidence and less risk of interrupting legitimate email.

Read original(opens in new tab)
CloudflareDnsThreat IntelligenceDmarc+4
cloudflare2 min readCurated summary

Growing the Cloudflare AI team with talent from Ensemble AI

Cloudflare is bringing key members of Ensemble AI onto its team to improve AI infrastructure and inference efficiency. Ensemble’s work on model compression, structured neural architectures, and parameter-efficient fine-tuning complements Cloudflare’s Workers AI platform. The combined effort aims to make powerful AI models faster, cheaper, and easier to deploy globally. ## Incorporating Ensemble AI’s Expertise - Ensemble AI has focused on reducing the memory, compute, and deployment costs of large language and multimodal models. - Its NdLinear technology replaces standard transformer linear layers while preserving multidimensional structure such as attention heads, channels, and spatial dimensions. - NdLinear-LoRA reduces the number of trainable parameters needed to fine-tune large models. - These techniques complement quantization and vector quantization to improve model efficiency without significantly sacrificing quality. ## Improving AI Inference Economics - Cloudflare Workers AI provides serverless GPU-powered inference across Cloudflare’s global network. - Lower model size, memory usage, and compute requirements can improve throughput, GPU utilization, and overall inference costs. - These improvements are increasingly important for agents, multimodal applications, personalization, fine-tuning, retrieval, and reinforcement learning. - The Ensemble team will contribute to Cloudflare’s existing work, including the Infire inference engine, Unweight tensor compression, and systems for running very large language models. ## Supporting Next-Generation Workloads - Developers increasingly need AI infrastructure that is reliable, affordable, globally distributed, and close to end users—not merely access to models. - Cloudflare’s network, serverless platform, and Workers AI provide a foundation for deploying AI with less operational complexity. - Combining Cloudflare’s infrastructure with Ensemble’s efficient model architectures should enable lower-cost, higher-performance AI deployments at scale. Cloudflare’s stated goal is to make advanced AI workloads more accessible by improving the economics and efficiency of inference across its platform.

Read original(opens in new tab)
Large Language ModelsMachine LearningQuantizationCloudflare Workers Ai+4
cloudflare3 min readCurated summary

Scaling Security Insights: how we achieved a 10x increase in global scanning capacity

Security Insights needed a 10x throughput increase to scan all customers more frequently and detect risks sooner. The existing system was overwhelmed by Kafka backlogs, slow processing, database inefficiencies, and API timeouts. Cloudflare improved capacity by introducing parallel and lane-based processing, optimizing bulk database writes, and addressing regional latency between its API and database. ## Scaling Kafka Processing - Scans are scheduled and published to Apache Kafka. - Go-based checker services consume these messages, inspect accounts, zones, and DNS records, and send findings to an internal API. - Kafka’s partition ordering limits each consumer group to one active consumer per partition. - Slow messages could block all subsequent messages in the same partition. - Adding partitions was avoided because it would increase resource usage for shared Kafka brokers. ## Introducing Parallel Processing - Checkers were changed to consume messages in batches. - Each message in a batch is processed concurrently in its own goroutine. - This increased throughput without requiring additional Kafka partitions. - The trade-offs were higher memory usage and potentially more work to repeat after a process crash. ## Separating Slow and Fast Work - Some scans took seconds or milliseconds, while unusually large accounts or zones could take minutes or hours. - These slow messages caused head-of-line blocking for faster work. - Consumer groups and checkers were split into: - A fast lane for predictable, short-running scans - A slow lane for messages expected to require substantially more time - Fast-lane consumers skipped slow messages, allowing normal scans to continue without delay. ## Optimizing Postgres Writes - The API originally executed one insert/upsert transaction per insight. - A request containing up to 500,000 insights could therefore generate hundreds of thousands of database round trips. - Bulk insertion with `COPY` into a temporary table was tested but caused bloat in Postgres system tables. - The final hybrid approach used: - `UNNEST` for smaller batches - `COPY` for batches above a configured threshold - This delivered millisecond-level performance for small writes and completion within seconds for very large writes. ## Diagnosing API Timeouts - Client-side timeouts increased as scan volume grew. - Checkers sometimes spent 20–90% of their processing time waiting on a single API call. - Throughput initially rose but then deteriorated under heavy load. - The root cause was network latency: - Postgres was hosted in Portland, Oregon. - The API ran active-active in Portland and Amsterdam. - Requests routed to Amsterdam incurred roughly 50 milliseconds of network round-trip latency. - Amsterdam database queries held client connection-pool connections much longer—nearly three seconds on average versus about 10 milliseconds in Portland. - The connection pool became exhausted, causing requests to wait for available connections and creating uneven Kafka lag across partitions. Cloudflare’s results came from improving the full processing pipeline rather than relying on a single infrastructure change. Parallelize message handling, isolate slow workloads, batch database writes, and place latency-sensitive services close to their databases to achieve large throughput gains and more frequent security scanning.

Read original(opens in new tab)
PostgreSQLApache KafkaDistributed SystemsAPI+4
cloudflare3 min readCurated summary

Route public traffic to private applications with Cloudflare

Cloudflare is extending its application security, performance, and programmability services to applications hosted on private networks. Its new Application Services for Private Origins allows public traffic to reach private origins through existing connectivity such as IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh—without public IP exposure, inbound firewall rules, or `cloudflared` on the origin. The feature is entering closed beta for eligible Enterprise customers. ## Unifying Public and Private Application Traffic - Private applications—including internal APIs, AI backends, MCP servers, and operational tools—can now use: - WAF - Bot management - Rate limiting - Caching - Traffic acceleration - Rewrites - Workers - Cloudflare treats private IPs as valid origin targets for public hostnames. - The model supports four traffic combinations: - Public users to public applications - Private users to public applications - Public users to private applications, which is shipping now - Private users to private applications, planned for the future ## Reusing Existing Private Connectivity - The feature builds on Cloudflare’s existing private networking layer. - Supported connectivity models include: - Cloudflare Tunnel - Cloudflare One Client - IPsec and GRE tunnels - CNI links - Cloudflare Mesh - Customers can manage routing through Cloudflare’s dashboard and APIs rather than maintaining separate networking stacks. - Workers VPC bindings and Spectrum private-origin routing also use this shared connectivity layer. ## Application Services for Private Origins - Customers can enable **Use private network routing** on a proxied A or AAAA DNS record. - Cloudflare continues applying WAF, rate limiting, caching, bot management, and transform rules at its edge. - Only the final connection differs: Cloudflare sends traffic through the customer’s private network instead of over the public Internet. - Private routing is automatically enabled for: - RFC 1918 IPv4 ranges such as `10.0.0.0/8` - RFC 6598 CGNAT ranges such as `100.64.0.0/10` - RFC 4193 IPv6 unique-local addresses such as `FC00::/7` - Public IPs reachable only through a private network can be configured manually. ## API Configuration - Private routing is represented as an additional DNS record attribute: ```json { "type": "A", "name": "app.example.com", "content": "10.0.0.50", "ttl": 300, "proxied": true, "use_private_routing": true } ``` - Cloudflare’s Origin API returns the `use_private_routing` flag. - When the proxy sees that flag, it passes the request to Cloudflare’s private networking layer, which selects the appropriate private path. ## Beyond HTTP - The same routing approach supports non-HTTP services. - Potential origins include: - TCP databases - UDP logging endpoints - Private APIs accessed by Workers - Spectrum can extend the model to TCP and UDP services, while Workers VPC enables direct access from serverless code. Cloudflare’s recommendation is effectively to use existing private connectivity as the transport layer while centralizing application security, performance, and routing at Cloudflare’s edge. The feature is currently limited to eligible Enterprise customers in closed beta.

Read original(opens in new tab)
CloudflareCloudflare WorkersZero TrustWeb Application Firewall+3
cloudflare3 min readCurated summary

Defend against frontier cyber models: Cloudflare's architecture as customer zero

Frontier cyber models primarily change the speed and scale of attacks, not the fundamental stages of intrusion. They can rapidly discover vulnerabilities, generate exploit variations, and adapt around defenses, making architectural resilience more important than patch speed alone. Cloudflare’s approach is to use layered controls, limit the reach of compromised identities, and turn broad network visibility into faster defensive action. ## What Frontier Cyber Models Change - Models such as Mythos can accelerate: - Vulnerability discovery across large codebases and open-source dependencies - Exploit-chain reasoning - Proof-of-concept generation - Reconnaissance and attack variation - Traditional intrusion stages—reconnaissance, initial access, lateral movement, persistence, and exfiltration—remain, but attackers can execute them faster and at greater scale. - Attackers need only one exploitable opening, while defenders must identify and secure all of them. - AI-generated fixes can introduce regressions, meaning faster patch creation does not eliminate testing and review constraints. ## Three Threats Driving the Architecture ### Faster Vulnerability Discovery - Frontier models can search widely used open-source libraries and frameworks at scale. - A library flaw is only exploitable when attacker-controlled input can reach the vulnerable code and surrounding protections are insufficient. - The most concerning risk is the gap between attacker discovery and defender awareness. - Organizations should assume attackers are already using these models against their code if they are not doing so themselves. ### Higher Exploit Volume and Adaptation - Models can generate thousands of exploit variants and conduct reconnaissance at comparable scale. - Signature-based defenses may still block many variants sharing the same underlying pattern. - The greater danger is adaptive behavior: a model can probe a WAF, learn which payloads are blocked, and rewrite attacks until they evade the rule. ### Limiting Impact After Exploitation - No security architecture prevents every compromise. - The critical question is how far an attacker can move using a single identity, route, or credential. - If one compromise provides unrestricted access, the surrounding architecture—not just the original vulnerability—is the fundamental weakness. ## Visibility as a Defensive Advantage - Cloudflare observes roughly one-fifth of global web traffic, providing real-time insight into: - Mutating attack payloads - Emerging patterns - New attacker tooling and campaigns - Cloudforce One converts this network visibility into threat intelligence, tracked adversaries, campaigns, and indicators of compromise. - The key challenge is reducing the delay between discovering a threat and applying an effective mitigation across defensive systems. ## Practical Recommendation Organizations should run frontier models against their own code, strengthen layered detection, and design systems so that a single compromised identity or credential cannot provide unrestricted access. Architecture, containment, and rapid use of threat intelligence are essential complements to patching.

Read original(opens in new tab)
CloudflareVulnerability ManagementAi SecurityWeb Application Firewall+2
cloudflare3 min readCurated summary

Turning Cloudflare’s threat indicators into real-time WAF rules

Cloudflare now lets security teams turn live Threat Events intelligence into proactive WAF rules. Instead of manually blocking known malicious IPs, organizations can filter traffic by threat actor, targeted industry or country, attack type, and recency. The integration separates always-on detection from mitigation, allowing teams to validate intelligence before enforcing blocks without sacrificing visibility. ## Always-on Threat Detection - The system builds on Cloudflare’s always-on Attack Signature Detection framework. - Threat intelligence runs continuously in the background and enriches HTTP requests with metadata before a WAF action is taken. - This removes the traditional “log versus block” trade-off: teams can observe detections in analytics and later create blocking rules. - Cloudforce One subscribers can review threat actors, targeted industries, and traffic patterns before enabling mitigation. - Detection is designed to add negligible latency. - The initial release supports IP-based matching, with planned support for JA3 fingerprints and domain-based indicators to identify attackers who rotate IP addresses. ## New WAF Intelligence Fields Cloudflare exposes threat context through fields that can be used in WAF custom rules and rate-limiting policies: - `cf.intel.ip.attacker_names`: Known threat groups, such as `CRAVENFLEA`. - `cf.intel.ip.target_industries`: Industries previously targeted by the IP. - `cf.intel.ip.attacker_countries`: Countries associated with the threat event. - `cf.intel.ip.target_countries`: Countries targeted by the event. - `cf.intel.ip.datasets`: Intelligence sources or attack categories, such as `ddos` and `waf`. Because an IP may have multiple associated actors, industries, or datasets, these values are arrays. Rules use `any()` with the `[*]` wildcard to match individual values. ## Example WAF Rules - Block IPs involved in DDoS activity against France: ```text any(cf.intel.ip.target_countries[*] == "FR") and any(cf.intel.ip.datasets[*] == "ddos") ``` - Block BLACKBASTA-associated traffic targeting banking and financial services: ```text any(cf.intel.ip.target_industries[*] == "Banking & Financial Services") and any(cf.intel.ip.attacker_names[*] == "BLACKBASTA") ``` - Apply broad protection against traffic originating from Iran: ```text any(cf.intel.ip.attacker_countries[*] == "IR") ``` ## Deployment Through Existing Workflows - The fields are available in the WAF rule builder for custom rules and rate limiting. - Teams can configure them through the Cloudflare API or Terraform. - Rules can be automated across individual domains or an entire account. - Security Analytics records matches, including the triggered rule and the specific intelligence indicator involved. - Threat Events users can create Saved Views—such as IPs targeting the financial sector within the last seven days—and convert them into WAF rules with one click. ## Global Distribution and Performance - Cloudflare compresses threat intelligence datasets into a high-performance format. - The data is distributed to Cloudflare data centers worldwide. - The WAF can therefore evaluate threat indicators at the edge without requiring local IP lists or introducing significant request latency. - The post begins to describe this lookup process as O(1), but the provided content ends before explaining the implementation in detail. Cloudflare’s integration gives teams a practical path from threat intelligence to enforcement: investigate indicators, validate them in analytics, and deploy precise WAF or rate-limiting rules through the UI, API, or Terraform. Teams should use the always-on visibility to tune criteria before blocking, while preparing for future indicators such as JA3 fingerprints and malicious domains.

Read original(opens in new tab)
TerraformInfrastructure As CodeThreat IntelligenceSecurity Analytics+3
cloudflare3 min readCurated summary

Your AI bill is out of control. Cloudflare can fix it now.

Cloudflare argues that uncontrolled AI spending stems from shared API keys, poor attribution, and defaulting to the most expensive models. Its AI Gateway now adds dollar-based spend limits, while a closed beta combines Cloudflare Access with identity-based budgets and routing. The goal is to make AI costs visible, attributable, and controllable without disrupting workflows. ### The AI Spending Problem - Companies encouraged aggressive AI adoption before establishing budgets or monitoring. - Shared API keys make it difficult to identify whether costs came from employees, teams, training pipelines, or runaway CI jobs. - Without routing rules or spending limits, users often choose frontier models for tasks that could use cheaper alternatives. - Visibility and controls are necessary to measure AI ROI and prevent waste. ### What AI Gateway Provides AI Gateway sits between applications and providers such as OpenAI, Anthropic, and Google. - Unified billing across providers and models. - Centralized logging of requests, token counts, and costs. - Response caching and rate limiting. - Content guardrails that can block PII and secrets before they reach models. - Previously, however, it lacked detailed attribution and budget controls. ### Dollar-Based Spend Limits - Budgets are measured in dollars rather than tokens and track cumulative request costs in real time. - Limits can be scoped by: - Model - Provider - Custom attributes such as user, team, or application - Budgets support daily, weekly, or monthly windows, including fixed and rolling periods. - When a limit is reached, requests can be blocked by default. - Dynamic Routes can instead redirect requests to a cheaper fallback model. - Spend limits are available in open beta across all AI Gateway plans through the dashboard or API. ### Identity-Driven Attribution and Policies Cloudflare Access can attach verified identity information to AI Gateway requests. - Authenticated user identities are extracted from Access JWTs and added as request metadata. - Organizations can track usage by employee, team, identity-provider group, or service. - Per-user budgets can give different spending limits to individual contributors and senior engineers. - Team policies can control which models different groups may use. - Access service tokens provide named identities for CI/CD pipelines and autonomous agents. - Logs include details such as email address, IdP group, or service-token name for export to analytics systems. - Configuration uses Cloudflare Access applications and existing identity-provider groups, without requiring custom Workers or manual JWT parsing. ### Cloudflare’s Internal Use - Cloudflare routes millions of requests and billions of tokens through AI Gateway each month. - It uses identity metadata to attribute costs, understand team usage, and manage budgets. - The company is making this internal approach available through the closed beta for identity-driven budgets and policies. Organizations should route AI traffic through a gateway, assign verified identities, set dollar-based budgets, and use model fallback rules to balance cost control with developer productivity.

Read original(opens in new tab)
CI/CDOauthCloudflare AccessIdentity Provider+4
cloudflare3 min readCurated summary

VoidZero is joining Cloudflare

VoidZero, the company behind Vite, Vitest, Rolldown, Oxc, and Vite+, is joining Cloudflare, with its entire team moving over. The projects will remain open source, MIT-licensed where applicable, vendor-agnostic, and community-driven. Cloudflare says the acquisition will provide more engineering resources while preserving portability and independent community governance. ## Open Source and Vendor Neutrality - Vite and the other VoidZero projects will continue to be developed in the open. - Applications built with Vite will remain deployable anywhere, not only on Cloudflare. - Evan You and the VoidZero team will continue leading the projects. - Cloudflare plans to invest engineering resources rather than redirect the projects toward its own platform. - Cloudflare is committing $1 million to a Vite ecosystem fund for maintainers and contributors, administered by the Vite core team. ## Vite as a Shared Foundation - Vite underpins a broad range of frameworks and tools, including Vue, SvelteKit, Nuxt, Astro, Solid, Qwik, Angular, React Router, and TanStack Start. - The authors describe Vite as a neutral foundation for the JavaScript ecosystem rather than a framework tied to one provider. - Cloudflare’s earlier investment in Astro is presented as an example of how it intends to support open-source projects while keeping them portable. ## The Environment API and Cloudflare Integration - Cloudflare and Vite began collaborating in 2024 on the Vite Environment API. - The API allows server-side code to run in non-Node.js runtimes during development. - Cloudflare’s Vite plugin runs application code locally inside **workerd**, the same open-source runtime used by Workers in production. - Services such as Durable Objects, D1, KV, R2, Workflows, Workers AI, Agents, Service Bindings, and Workers RPC can therefore be tested locally using the production runtime model. - The approach keeps Vite’s integration generic: other runtimes can implement their own provider-specific plugins without requiring a Cloudflare-specific development server. - Vite reportedly reaches about 129 million weekly downloads, while the Cloudflare Vite plugin approaches 14 million. ## AI-Driven Development - AI agents now use development tools directly, including project scaffolding, dev servers, testing, linting, formatting, error handling, and deployment workflows. - Agent-driven development increases the importance of: - Fast builds and tests - Fast linting and formatting - Structured, actionable errors - Consistent command-line interfaces - VoidZero’s tools—Vitest, Rolldown, Oxc, Oxlint, and Oxfmt—are designed for repeated, automated feedback loops. - Vite+ combines these tools behind a unified CLI and configuration model, reducing complexity for both developers and agents. - Cloudflare is using the tools internally: its dashboard runs on Vite, Oxlint is reducing engineering effort, and the Flue agent framework is adopting Vite and the official Cloudflare plugin. Cloudflare’s stated priority is to preserve the trust and portability that made Vite widely adopted. The practical takeaway is that the acquisition is intended to expand Vite’s resources and runtime integrations without turning it into a Cloudflare-only platform.

Read original(opens in new tab)
CloudflareOpen SourceJavaScriptCloudflare Workers+4