cloudflare·Jul 30, 2026·4 min readCurated summary

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

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

Read original(opens in new tab)

Cloudflare WorkersServerlessContent Delivery NetworkCloudflare R2+3

cloudflare·Jul 6, 2026·3 min readCurated summary

Your Worker can now have its own cache in front of it

Workers Cache places a tiered Cloudflare cache directly in front of a Worker, allowing cacheable responses to be served without running the Worker or incurring CPU time. It is enabled with a single Wrangler configuration block and controlled through standard HTTP headers such as `Cache-Control` and `Cache-Tag`. The feature gives server-rendered applications a middle ground between expensive per-request rendering and slow, rebuild-dependent static generation. ## How Workers Cache Works - Enable it in Wrangler with: ```json { "cache": { "enabled": true } } ``` - Cacheable requests are checked against Cloudflare’s cache before the Worker runs. - Cache hits return immediately without invoking the Worker or consuming CPU time. - Cache misses execute the Worker, and cacheable responses are stored for later requests. - Caching follows the Worker across: - Custom domains - `workers.dev` - Service bindings - Preview environments - Workers for Platforms tenants - Responses use familiar HTTP controls: - `Cache-Control` for TTL and behavior - `stale-while-revalidate` for background refreshes - `Vary` for content negotiation - `Cache-Tag` for targeted invalidation ## Purging Cached Content - Workers can purge their own cache programmatically: ```js await ctx.cache.purge({ tags: ["product:123"] }); ``` - Purging can target cache tags or path prefixes. - `ctx.props` supports cache keys that are safe for multi-tenant applications. ## Why Server-Rendered Apps Need This - Originally, Workers were positioned in front of an origin and Cloudflare’s cache. - Modern frameworks such as Astro, Next.js, Remix, SvelteKit, and TanStack Start often make the Worker the application’s origin. - Without a cache in front, every request runs application code, even when the response has not changed. - This creates recurring rendering latency and CPU costs for server-rendered pages. ## A Middle Ground Between Static and Dynamic Rendering - Static-site generation provides fast responses but requires rebuilding and redeploying whenever content changes. - Rendering every request keeps content current but imposes latency and compute costs on every visitor. - Workers Cache enables on-demand rendering: - The first request renders and caches the page. - Subsequent requests are served from cache. - Expiration triggers a fresh render according to the configured TTL. - This delivers static-like speed without framework-specific systems such as Incremental Static Regeneration. ## Stale-While-Revalidate - `stale-while-revalidate` allows Cloudflare to serve an expired response immediately while refreshing it in the background. - Without it, the first request after expiration waits for the Worker to render the page again. - With it: - Users receive the stale response instantly. - The response includes `Cf-Cache-Status: UPDATING`. - The Worker refreshes the cached response asynchronously. - A typical policy is: ```http Cache-Control: public, max-age=300, stale-while-revalidate=3600 ``` This keeps content fresh for five minutes while allowing stale content to be served for up to an additional hour during background refreshes. Workers Cache is available to all Workers on every plan. For server-rendered applications, enabling it and defining appropriate HTTP cache headers provides a simple way to reduce latency and execution costs while retaining controlled content freshness.

Read original(opens in new tab)

Cloudflare WorkersWranglerHttp CachingStale While Revalidate+2

cloudflare·Jun 24, 2026·3 min readCurated summary

Unlocking the Cloudflare app ecosystem with OAuth for all

Cloudflare opened self-managed OAuth to all customers so developers can build SaaS integrations, internal platforms, CI/CD workflows, and agentic tools without relying on difficult-to-manage API tokens. The expansion required improvements to permissions, consent, revocation, and phishing protections, as well as a major upgrade to the Hydra-based OAuth engine. Cloudflare used staged migrations, custom database changes, token-handling safeguards, and queued revocations to minimize disruption and preserve users’ security controls. ## Why Cloudflare Expanded OAuth Access - Previously, third-party OAuth integrations were limited to manually approved partners. - Other developers had to use API tokens, which are less convenient and poorly suited to delegated access. - Self-managed OAuth lets customers: - Request narrowly scoped permissions. - Give users clearer consent controls. - Revoke application access from the dashboard. - Build integrations and agentic tools using standard OAuth flows. - Cloudflare improved consent screens to identify the requesting application and its permissions, while making application ownership more visible to reduce phishing risks. ## Planning the Hydra Upgrade - Cloudflare used Hydra, an open-source OAuth engine, but its older deployment could not support the platform’s growing scale and new use cases. - The upgrade was split into two stages: - First, move to the latest 1.X release. - Then, perform the larger 2.X migration. - The 1.X database migrations created operational risks: - Standard index creation could take exclusive locks on critical tables. - Schema changes added columns and moved data between tables. - Hydra’s SDK used `SELECT *`, creating deserialization problems after schema changes. - Cloudflare rewrote migrations to use `CREATE INDEX CONCURRENTLY` and built a custom Hydra version that selected explicit columns. ## Designing a Blue-Green Migration - An in-place 2.X upgrade was rejected because of the volume of schema changes. - A blue-green deployment was chosen, but the migration would take several hours. - Disabling writes would prevent new authorizations and revocations, leaving users unable to manage application access during the upgrade. - Instead, Cloudflare kept writes enabled while reducing the amount of data that could be lost during the cutover: - Token expiry times were temporarily extended to multiple hours, reducing refresh-token writes. - Revocation events were written to Cloudflare Queues. - After switching to the green database, queued revocations could be replayed. - Preserving revocations was essential to prevent applications that users had disabled from regaining access. ## Lessons from the 1.X Upgrade - The custom migrations completed faster than expected without user impact. - A hard cutover was necessary because the old Hydra version could not read tokens created by the new version. - The new version introduced stricter refresh-token invalidation: - Reusing a refresh token invalidated the entire access and refresh-token chain. - This caused problems for high-volume clients such as Wrangler and MCP clients. - Cloudflare added refresh-token coalescing in the Worker routing layer: - Briefly caching requests allowed retries to be served without triggering invalidation. - Hydra 2.X provides a configurable refresh-token grace period, offering a more direct solution for safe retries. ## Executing the 2.X Upgrade - Cloudflare prepared a blue-green migration to avoid several hours of customer-facing downtime. - The strategy depended on reducing token writes, recording all revocations externally, switching databases, and replaying queued events afterward. - The provided article ends while beginning the detailed discussion of the 2.X execution. Cloudflare’s approach demonstrates that opening a security-sensitive platform to broad OAuth usage requires more than exposing an authorization endpoint. Safe adoption depends on explicit permissions, transparent consent, reliable revocation, backward-compatible token behavior, and migration plans that protect users even during infrastructure cutovers.

Read original(opens in new tab)

Cloudflare WorkersOauthWranglerDatabase Migrations+3

cloudflare·Jun 22, 2026·3 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

cloudflare·Jun 19, 2026·2 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)

Cloudflare WorkersAI AgentsTypeScriptStripe+4

cloudflare·Jun 10, 2026·3 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)

Cloudflare WorkersCloudflareZero TrustWeb Application Firewall+3

cloudflare·Jun 4, 2026·3 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)

Cloudflare WorkersCloudflareOpen SourceJavaScript+4

cloudflare·May 19, 2026·3 min readCurated summary

Announcing Claude Managed Agents on Cloudflare

Cloudflare and Anthropic have integrated Claude Managed Agents with Cloudflare Sandboxes, separating Claude’s agent reasoning from the infrastructure that executes code. The integration adds customizable security controls, sandbox observability, private-service access, browser auditing, email, and custom tools. It supports both full microVMs for complex workloads and lightweight isolates for fast, large-scale execution. ## Claude Managed Agents and the “Brain vs. Hands” Model - Claude Managed Agents run on Anthropic’s platform and can: - Read and write files - Run commands and code - Browse the web - Use prompt caching, compaction, and agent-focused optimizations - The integration decouples: - **The brain:** Claude’s agent loop on Anthropic’s infrastructure - **The hands:** Code execution, tools, sandboxes, and connected services on Cloudflare - Self-managed execution gives organizations more control over security, compliance, infrastructure, and performance. ## Cloudflare-Based Agent Environments - A Workers-based control plane creates a sandbox for each Claude Agent session. - Sandboxes support: - Code execution and file operations - Application development and CLI tools - Persistent state across session sleeps - Developers can customize: - Sandbox instance sizes - Container images for VM-based sandboxes - Cloudflare provides detailed metrics and logs, dashboard monitoring, external log shipping to services such as Datadog or Splunk, and SSH access to running sandboxes. - A built-in UI helps track sandbox state and open interactive shell sessions. ## Scaling with Isolates and MicroVMs - Full microVMs are appropriate for agents that need Linux environments, developer tooling, or complete application stacks. - Cloudflare also offers lightweight V8 isolate sandboxes using Agents SDK, Dynamic Workers, and Codemode. - Isolates provide: - Millisecond-level startup - Lower infrastructure costs - File-system support and arbitrary code execution - Much higher concurrency than VM-based systems - Developers can select an “isolate” backend when configuring an agent. - Isolates are intended for workloads reaching tens of thousands of concurrent agents, while Cloudflare Containers provide microVM-based execution when stronger environment fidelity is required. ## Security and Agent Connectivity - The default deployment routes agent traffic through customizable outbound proxies. - Proxies can help: - Inject credentials outside the sandbox - Prevent agents from accessing raw secrets - Reduce data exfiltration risk - Monitor interactions with external services - Agents can connect to private internal services without exposing those services directly to the public Internet. - The integration also includes browser session controls, recordings, audit trails, and human-in-the-loop workflows. ## Built-In Agent Capabilities The deployment template includes several capabilities without requiring additional infrastructure: - Detailed sandbox metrics, logs, and SSH access - Custom sandbox images and resource sizing - Browser automation with observability - Individual email addresses and outbound email for agents - Custom tools implemented as functions and deployed directly - Flexible execution through either isolates or microVM-backed sandboxes Cloudflare’s recommendation is to use isolates for inexpensive, highly concurrent workloads and microVMs when agents require full Linux environments or complex development workflows. The integration is designed to let teams keep Claude’s reasoning on Anthropic while retaining control over execution, connectivity, security, and observability on Cloudflare.

Read original(opens in new tab)

Cloudflare WorkersZero Trust SecurityCloudflare SandboxesAgent Sdk+3

cloudflare·May 13, 2026·3 min readCurated summary

Browser Run: now running on Cloudflare Containers, it’s faster and more scalable

Browser Run was rebuilt on Cloudflare Containers to improve speed, reliability, and scale. The migration increased capacity to 60 browser launches per minute and 120 concurrent browsers—four times the previous limit—while cutting Quick Action response times by more than 50%. The main architectural changes were global Container deployment, regional pools of pre-warmed browsers, and replacing eventually consistent KV state with transactional D1 and batched Queue updates. ## Browser Run’s Role - Provides programmatic access to headless browsers on Cloudflare’s global network. - Supports: - End-to-end testing - Suspicious URL investigation - PDF rendering - Screenshots and content extraction - Web interaction for AI agents - The goal is to offer secure, responsible browser automation at massive scale. ## Why the Previous Infrastructure Was Limiting - Browser Run originally shared infrastructure with Browser Isolation (BISO). - BISO’s larger container images caused slower startup and development cycles. - Browser Run lacked optimal global distribution, affecting latency and resilience. - BISO’s long-running sessions conflicted with Browser Run’s short, bursty workloads. - These differences created scaling and availability bottlenecks. ## Gradual Migration to Containers - A Worker initially routed a small number of requests to Container-based browsers while others continued using BISO. - This dual-running setup allowed the team to: - Compare performance - Find implementation bugs - Validate stability - Rollout stages included: - Quick Actions - Free-account Workers browser binding connections - Pay-as-you-go accounts - Contract customers - Customers did not need to change code or redeploy Workers. ## Regional Pools for Lower Latency - Durable Object-enabled Containers can create the Durable Object near the request while starting the Container elsewhere. - This is acceptable for one-off commands but inefficient for WebSocket workflows involving many messages. - The team introduced regional pools of pre-warmed, Durable Object-backed browsers. - Requests are assigned to a nearby Durable Object–Container pair, reducing latency between: - The user and Durable Object - The Durable Object and browser Container - The design requires global browser-state observability so capacity can be allocated and reassigned as demand changes. ## Replacing KV with D1 and Queues - Workers KV was initially used to track browser availability. - Its eventual consistency and cache TTL—around 30 seconds or longer—caused race conditions: - A browser could appear available when another request had already claimed it. - Delayed state updates led to over-allocation and limited responsiveness to traffic spikes. - Browser state was moved to D1, whose SQLite transactions provide atomic assignment. - A browser is exclusively assigned to one user, preventing simultaneous claims through transactional updates. Example acquisition logic updates selected candidates to `picked` and returns their data in one operation: ```sql WITH candidate_pool AS (...) UPDATE containers SET status = 'picked' WHERE sessionId IN ( SELECT sessionId FROM candidate_pool ORDER BY RANDOM() LIMIT ?5 ) RETURNING data; ``` ## Batching State Updates - D1 shards are maintained by location. - Thousands of containers report their state every five seconds, which could overload the database if each update were written individually. - Queue-based batching groups 100 updates into a single write. - This increases theoretical capacity from roughly 5,000 containers per location to as many as 500,000. - The team reports a P95 batch-write latency of 0.1 ms. - Queue consumers use: - Maximum batch size: 100 - Maximum batch timeout: 1 second - Maximum retries: 1 The migration is live, requires no customer changes, and gives Browser Run more room to handle demand from AI agents and other high-volume browser automation workloads.

Read original(opens in new tab)

Cloudflare WorkersDurable ObjectsSqliteWebsockets+4

cloudflare·May 1, 2026·3 min readCurated summary

Introducing Dynamic Workflows: durable execution that follows the tenant

Dynamic Workflows extends Cloudflare’s durable execution system to multi-tenant and dynamically generated applications. While Dynamic Workers provide isolated runtime compute, Durable Object Facets provide tenant-specific storage, and Artifacts provide versioned source control, Dynamic Workflows lets each tenant supply its own long-running workflow code. The result is durable execution that can resume the correct tenant’s workflow after failures, hibernation, or delays of days. ## The Gap Between Durable and Dynamic Execution - Cloudflare Workflows turns a `run(event, step)` function into a durable program. - Workflow steps can: - Survive isolate recycling and failures - Sleep for hours or days - Wait for external events - Resume from the exact point where execution stopped - Workflows V2 supports up to 50,000 concurrent instances and 300 new instances per second per account. - Traditional Workflows assume the workflow class is included in the deployment and statically configured in `wrangler.jsonc`. - That model breaks for: - Multi-tenant SaaS platforms - AI-generated tenant applications - Repository-specific CI/CD pipelines - Agents that create their own durable plans - In these systems, workflow code varies by tenant, agent, repository, or request, so a single statically bound class is insufficient. ## Dynamic Workflows - `@cloudflare/dynamic-workflows` is a roughly 300-line TypeScript library. - It introduces a Worker Loader that: - Loads each tenant’s code dynamically - Routes workflow creation to the appropriate tenant - Ensures later workflow execution returns to that tenant’s code - The Loader creates a dynamic Worker with: - A tenant-specific module - A `TenantWorkflow` entrypoint - A wrapped `WORKFLOWS` binding - The dynamic entrypoint is registered as the workflow class in `wrangler.jsonc`. - Tenant code remains ordinary Cloudflare Workflows code and does not need to know it is being dynamically dispatched. ## Tenant Workflow Behavior - Tenants can use the normal Workflow APIs, including: - `env.WORKFLOWS.create(...)` - Workflow IDs and `.status()` - `.pause()` - Retries and durable steps - `step.sleep('24 hours')` - `step.waitForEvent()` - A tenant can define a standard `WorkflowEntrypoint` with a `run(event, step)` method. - The library’s primary responsibility is preserving the association between a workflow instance and the tenant implementation when the workflow resumes later. ## Three-Layer Execution Model - Dynamic Workflows consists of three layers: - The Cloudflare Workflows engine - The platform’s Worker Loader - The tenant’s dynamically loaded Worker code - A request first enters the Loader, which identifies the tenant and routes execution to its dynamic code. - The workflow engine then persists the workflow state and later invokes `run(event, step)`. - The Loader resolves the correct tenant implementation when execution resumes, even after delays or failures. Dynamic Workflows provides the missing durable-execution counterpart to Cloudflare’s dynamic compute, storage, and source-control primitives. It is particularly suited to platforms where customers or agents generate workflow code at runtime while still requiring standard durable guarantees.

Read original(opens in new tab)

Cloudflare WorkersDatabase DesignCI/CDTypeScript+4

cloudflare·Apr 17, 2026·3 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)

Cloudflare WorkersDatabase DesignSqliteEdge Computing+4

cloudflare·Apr 17, 2026·3 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)

Cloudflare WorkersReactTypeScriptAPI Design+3

cloudflare·Apr 16, 2026·3 min readCurated summary

Artifacts: versioned storage that speaks Git

Artifacts is a distributed, versioned filesystem designed for AI agents and other high-volume compute environments. It creates repositories programmatically while remaining compatible with standard Git clients, enabling isolated repositories for agent sessions, sandboxes, and large numbers of forks. Cloudflare argues that Git’s familiar data model—commits, history, diffs, and branching—can serve as a general-purpose state-management primitive beyond traditional source control. ## A Git-Compatible Filesystem for Agents - Artifacts repositories can be created through the Workers API or REST API. - Applications receive a Git remote and authentication token, allowing agents to clone and use repositories with ordinary Git commands. - Repositories can be created dynamically for: - Individual agent sessions - Sandbox instances - Large-scale forked environments - Non-Git clients such as Workers, Lambda functions, and Node.js applications can use the API directly or language-specific SDKs. - Existing repositories can be imported from sources such as GitHub, then independently forked for isolated or read-only work. ## Why Git Fits Agent Workflows - Most AI coding agents already understand Git, including common workflows and edge cases. - Git’s object and commit model works well for storing: - Source code and configuration - Session prompts and agent history - Other large collections of small, versioned data - Git provides built-in capabilities for: - Tracking state over time - Reverting changes - Comparing versions - Forking from historical points - Using Git avoids requiring agents to learn a new protocol, CLI, or specialized tool. ## Beyond Source Control - Artifacts can persist an entire agent session’s filesystem and history without requiring dedicated block storage. - Cloudflare uses per-session repositories to: - Restore sandbox state - Share sessions with other people - Time-travel through both prompts and filesystem changes - Fork a session from any point for collaboration or debugging - The same semantics can support non-code data, such as customer-specific configuration that needs rollback, cloning, or diffing. - Cloudflare expects non-Git use cases to be as important as conventional repository workflows. ## Implementation on Cloudflare - Artifacts are built on Durable Objects, which provide isolated, stateful compute capable of supporting millions of repository instances. - The system uses an in-house Git implementation written in Zig and compiled to WebAssembly for Cloudflare Workers. - The implementation was designed to be: - Small - Broadly Git-compatible - Extensible for features such as notes and Git LFS - Efficient in a Workers environment Artifacts is currently available in private beta for paid Workers customers, with a public beta planned for early May. It is intended as a practical way to give agents and applications disposable, persistent, and fully versioned environments without abandoning the Git ecosystem.

Read original(opens in new tab)

Cloudflare WorkersDatabase DesignTypeScriptGit+4

cloudflare·Apr 12, 2026·3 min readCurated summary

Welcome to Agents Week

Cloudflare argues that AI agents require a fundamental shift in Internet and cloud infrastructure. Unlike traditional one-to-many applications, agents create unique, ephemeral execution environments for individual users and tasks, making current container-based economics and scaling inadequate. The company positions lightweight V8 isolates, alongside containers and browser support, as the foundation for making agents practical at global scale. ## The Internet Was Built for Applications, Not Agents - Cloud infrastructure evolved during the smartphone era to serve many users through a finite number of application instances. - Microservices, containers, Kubernetes, load balancing, and replication all support this one-to-many model. - Agents differ because an LLM dynamically determines code paths, tool usage, and task duration. ## One User, One Agent, One Task - Each agent may need its own execution environment, filesystem, tools, and state. - Coding agents currently use containers with access to Git, Bash, filesystems, and arbitrary binaries. - As agents spread to assistants, analysts, customer service, and planning tasks, the number of simultaneous environments could grow dramatically. ## The Scale Challenge - If 100 million US knowledge workers used agents at 15% concurrency, infrastructure would need about 24 million simultaneous sessions. - At 25–50 users per CPU, that implies roughly 500,000 to 1 million server CPUs in the US alone. - Multiple agents per person and global adoption would increase demand by orders of magnitude. ## Isolates as Agent Infrastructure - Cloudflare’s Workers platform uses V8 isolates instead of containers. - Isolates start in milliseconds, use only a few megabytes of memory, and provide secure sandboxing. - They can be up to 100 times faster to start and up to 100 times more memory-efficient than containers. - Dynamic Workers can create execution environments on demand, run code, and discard them at a scale of millions per second. - This efficiency could make one-agent-per-user economics viable beyond expensive coding assistants. ## The “Horseless Carriage” Phase - Early agent infrastructure often adapts existing systems instead of using designs built specifically for agents. - Agents use headless browsers to navigate human-oriented websites, though structured protocols such as MCP could provide direct service access. - Many MCP servers simply wrap REST APIs, despite LLMs often being better at writing and executing code than making long sequences of tool calls. - CAPTCHAs and behavioral fingerprinting ask whether a requester is human, while agent systems need identity, authorization, and permission controls. - Full containers are frequently used for tasks that require only a few API calls and a response. ## Supporting Both Old and New Models - Infrastructure transitions rarely happen all at once; technologies such as IPv4/IPv6, HTTP/2/HTTP/3, and TLS 1.2/1.3 coexist. - Cloudflare plans to support existing agent workloads while developing more efficient primitives. - Containers remain important for coding agents that need filesystems, Git, Bash, and arbitrary binaries. - Cloudflare is also expanding container-based sandbox environments and browser-rendering capabilities for services that do not yet support agent-native protocols. Cloudflare’s broader recommendation is to build infrastructure that can serve today’s container-based agents while moving toward lightweight, ephemeral isolates designed for billions of specialized agent sessions.

Read original(opens in new tab)

Cloudflare WorkersDatabase DesignLarge Language ModelsKubernetes+4

cloudflare·Mar 24, 2026·3 min readCurated summary

Sandboxing AI agents, 100x faster

Cloudflare argues that AI-generated code needs secure execution, but traditional containers are too slow, memory-intensive, and difficult to scale for consumer-scale agents. Its Dynamic Worker Loader uses lightweight V8 isolates to create disposable, isolated sandboxes in milliseconds, with controlled access to APIs and no internet connectivity. The result is a sandbox roughly 100 times faster and substantially more memory-efficient than containers, provided agents can write JavaScript. ## Why Containers Fall Short - AI-generated code cannot safely run directly through `eval()`, since prompts could cause the model to introduce vulnerabilities. - Containers provide isolation but typically: - Take hundreds of milliseconds to start - Consume hundreds of megabytes of memory - Require warm instances to reduce latency - May encourage unsafe container reuse - These limitations make containers poorly suited to running a fresh sandbox for every request or user agent. ## Dynamic Worker Loader - Cloudflare’s Dynamic Worker Loader lets a Worker instantiate another Worker dynamically from runtime-provided code. - The host can: - Supply generated JavaScript modules - Expose selected APIs through RPC stubs - Disable or intercept outbound internet access - Invoke methods exported by the dynamically loaded Worker - The feature is in open beta for paid Workers users. ## Faster, Smaller Isolates - Dynamic Workers use V8 isolates, the same sandboxing technology underlying Cloudflare Workers. - Isolates: - Start in a few milliseconds - Use only a few megabytes of memory - Are approximately 100 times faster and 10–100 times more memory-efficient than typical containers - A new isolate can be created for one request and discarded afterward without maintaining a pool of warm sandboxes. ## Scalability and Latency - Dynamic Worker Loader has no container-style global concurrency or sandbox-creation limits. - It relies on the infrastructure that already scales Cloudflare Workers to millions of requests per second. - Each request could theoretically load its own isolated sandbox, even at very high concurrency. - Dynamic Workers commonly run on the same machine or thread as their parent Worker, avoiding network round trips and warm-sandbox lookup delays. - They are available across Cloudflare’s global network. ## JavaScript as the Agent Runtime - The main limitation is that agent-generated code should generally be JavaScript. - Workers also support Python and WebAssembly, but JavaScript is faster to load for short-lived snippets. - Cloudflare argues this is acceptable because: - LLMs can generate major programming languages - JavaScript has extensive training data - JavaScript was designed for web-based sandboxed execution ## TypeScript APIs for Agent Tools - Agents still need access to external capabilities such as chat systems and APIs. - TypeScript interfaces provide a concise way to describe these programming APIs. - Compared with MCP’s flat tool schemas or verbose OpenAPI specifications, TypeScript can express: - Methods and parameters - Return types and promises - Objects such as messages - Subscription and disposal behavior - This gives agents precise API knowledge with fewer tokens and lets them write direct code rather than issuing numerous tool calls. Dynamic Worker Loader is presented as a practical foundation for secure, disposable AI-agent execution: use V8 isolates for low-latency sandboxing, expose only narrowly defined TypeScript/RPC capabilities, and block network access unless explicitly required.

Read original(opens in new tab)

Cloudflare WorkersLarge Language ModelsTypeScriptJavaScript+4