Cloudflare Workers

44 posts

cloudflare3 min readCurated summary

Evolving Cloudflare’s Threat Intelligence Platform: actionable, scalable, and ETL-less

Cloudflare’s Threat Intelligence Platform (TIP) is designed to turn massive volumes of security telemetry into actionable intelligence without relying on traditional ETL pipelines. Its sharded, SQLite-backed architecture uses Durable Objects and edge-based GraphQL to provide near-real-time analysis across millions of events. By combining automated telemetry with analyst investigations, the platform aims to help security teams understand threats and block them proactively. ## Motivation for Building the Platform - Cloudflare began developing the TIP after launching Cloudforce One in 2022 and discovering that existing tools could not adequately track adversary infrastructure. - The platform models the full threat lifecycle, connecting: - Threat actors to malware - Cases to indicators - Events to broader campaigns - It is designed for: - Multiple datasets and tenants - Group-based and tenant-to-tenant sharing - Extensibility and edge-scale performance - Visual analysis and automated response - Cloudflare Workers allow the platform to evolve with the runtime and support features such as Smart Placement, higher CPU limits, and Hyperdrive. ## Beyond the SIEM - The TIP complements rather than replaces a SIEM: - SIEMs focus on real-time log aggregation and alerting. - The TIP provides long-term retention, specialized threat schemas, and historical context. - Analysts can enrich alerts with: - Indicator history - Known threat-actor associations - Campaign relationships - Risk scores and intelligence context - Findings from analysts feed new indicators of compromise back into the platform. - This feedback loop keeps intelligence current and helps organizations move from reactive investigation to proactive defense. ## Sharded Storage Without ETL Bottlenecks - Cloudflare distributes Threat Events across many logical shards instead of using one centralized database. - Each shard is a Durable Object with a private SQLite database, providing transactional consistency and avoiding a single database bottleneck. - Cloudflare Queues handle asynchronous ingestion, helping absorb high-volume attack spikes. - R2 stores data for long-term retention, while SQLite maintains a hot index for fast access. - Because data is available directly in the platform’s operational store, complex ETL pipelines and synchronization delays are avoided. ## Parallel Queries at the Edge - GraphQL runs in the same Worker-based system that powers the Threat Events platform, keeping data live from ingestion through querying. - Queries are fanned out to relevant Durable Objects in parallel rather than executed against one large table. - The platform first verifies permissions and excludes shards that cannot contain matching events, such as shards outside the requested date range. - Results from multiple shards are aggregated with `Promise.all`, enabling low-latency searches across global datasets. - Smart Placement positions query Workers near the Durable Objects they access, reducing tail latency. Cloudflare’s approach combines edge-native storage, parallel execution, and analyst-driven enrichment to make threat intelligence both scalable and actionable. The practical goal is a unified system that explains not only what is malicious, but also why it matters and how to automatically prevent it.

Read original(opens in new tab)
cloudflare3 min readCurated summary

How Cloudy translates complex security into human action

Cloudy is Cloudflare’s LLM-powered explanation layer for Cloudflare One, translating complex security detections into clear, actionable guidance. It helps security teams understand why emails or SaaS findings were flagged and helps end users make better decisions in real time. Its integration with Phishnet aims to reduce unnecessary SOC submissions while preserving strong protection against genuine threats. ## Turning Complex Detections into Human Guidance - Email and CASB systems analyze numerous signals, including sender reputation, authentication, links, infrastructure, behavior, misconfigurations, and exposed data. - Traditional detections may correctly identify risk without clearly explaining the reasoning. - Cloudy converts machine-learning outputs into concise explanations for both administrators and nontechnical users. - For Email Security, it explains why messages are classified as Malicious, Suspicious, Spam, Bulk, or Spoof. - For CASB, it is intended to clarify the risk and remediation path for SaaS findings. ## The Challenge for Email Users and SOC Teams - Users increasingly serve as an additional defense layer against social engineering and impersonation attacks. - Periodic security training and phishing simulations do not provide enough context when users encounter real messages. - This creates two problems: - Some users report nearly every questionable email, overwhelming SOC queues. - Others interact with risky messages because no clear warning appears at the moment of decision. - Excessive reporting creates backlogs and slows investigations of genuinely dangerous emails. ## Cloudy in Phishnet - Cloudy will be integrated into the Phishnet reporting workflow for Microsoft. - When users report a message, they will receive a simplified, plain-language explanation of the relevant security signals. - The goal is to help users decide whether a message is truly suspicious and reduce unnecessary escalations. - This allows SOC teams to focus on messages requiring investigation while making users more effective participants in security operations. ## How the Explanation Pipeline Works - A Phishnet report triggers a Cloudflare Workers-based workflow. - The workflow aggregates outputs from multiple detection models, including: - Sender reputation - Domain and infrastructure characteristics - SPF, DKIM, and DMARC authentication results - Link and content analysis - Behavioral indicators - Workers AI processes these structured signals using purpose-built prompts. - The prompts generate a natural-language explanation rather than changing the original message classification. - The experience is optimized for end users, avoiding overly technical terms such as ASNs, IP reputation, and raw authentication failures. ## Translating Technical Signals - An SPF failure becomes: “This email failed a sender verification check.” - A DKIM failure is explained as a failed message-integrity check that may indicate tampering. - A DMARC failure indicates that the sender’s domain could not confirm the email’s legitimacy. - These translations preserve the meaning of the underlying detections while making them understandable to nontechnical recipients. Cloudy’s practical value is its ability to connect sophisticated security analysis with immediate human decision-making. Embedding understandable explanations directly into Phishnet should improve user judgment, reduce SOC noise, and make complex detections more actionable without altering the underlying security verdict.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Beyond the blank slate: how Cloudflare accelerates your Zero Trust journey

Cloudflare argues that a Zero Trust platform’s blank-slate flexibility can become an adoption barrier when customers must configure countless policies and security controls themselves. Project Helix addresses this by codifying Cloudflare experts’ best practices into automated Terraform templates, delivered through a simple web interface. The result is a faster, more consistent way to deploy a secure Cloudflare One baseline within minutes rather than hours. ## The complexity barrier of a blank slate - Cloudflare One offers extensive capabilities across DNS protection, network security, Secure Web Gateway, TLS inspection, DLP, antivirus scanning, and Zero Trust Access. - Tenants are generally provisioned with minimal defaults because enabling advanced protections immediately could disrupt existing traffic and applications. - Customers must therefore manually activate numerous settings, policies, and routing changes. - Some features require coordinated configuration: - Enabling private application access by hostname requires both a platform setting and a specific CGNAT range in the client’s split-tunnel configuration. - Traffic from applications such as Zoom may need to bypass Cloudflare and go directly to the Internet. - Captive portal exceptions can be important for users connecting from hotels, airlines, and other public networks. - Initial setup guides and scenario-based wizards helped, but customers using multiple scenarios still had to complete each workflow separately. ## Project Helix: Turning expertise into automation - Cloudflare gathered deployment knowledge from Solutions Engineers, Professional Services Engineers, and partners. - The team documented desired proof-of-concept and production outcomes, including: - Baseline DNS, network, and HTTP security protections - TLS inspection - QUIC and HTTP/3 security - Remote Browser Isolation for risky categories such as newly registered domains - Visibility and controls for AI applications - Tenant Control policies restricting users to approved SaaS instances - Helix packages these recommendations in a repeatable, codified format that can be applied with a button click. - This avoids relying on individually maintained documentation or the memory of experienced administrators. ## Problems with manual deployment - Configuring the complete baseline on a new tenant can take several hours. - Documentation must be continually updated as Cloudflare features and best practices change. - Repetitive manual steps increase the risk of configuration errors and inconsistent deployments. - Manual work also makes it harder for less experienced users to benefit from Cloudflare One’s full capabilities. ## Terraform, Workers, and ephemeral provisioning - Helix uses scalable Terraform templates to define Cloudflare One settings, configuration snippets, and security policies. - A web interface hosted on Cloudflare Workers accepts basic customer inputs and executes the Terraform configuration. - Cloudflare Containers support the provisioning workflow. - The process uses no persistent storage, reducing risks associated with retaining Terraform logs or authentication tokens. - Within minutes, users can deploy an advanced baseline configuration and review additional recommended policies to enable. ## Layered security configuration - Helix begins with DNS security policies that: - Support corporate DNS for Zero Trust - Block malicious or questionable categories before they resolve - It then applies network policies to protect users across ports and protocols. - The broader configuration also incorporates traffic-routing exceptions, application controls, and user-experience improvements such as captive portal handling. Project Helix’s practical recommendation is to replace manual, blank-slate configuration with expert-designed, automated baselines. This lets customers adopt Cloudflare One’s advanced protections quickly while preserving the flexibility to customize policies for their own environments.

Read original(opens in new tab)
cloudflare3 min readCurated summary

The truly programmable SASE platform

Cloudflare argues that true SASE programmability goes beyond APIs, Terraform, webhooks, and alerts. It means intercepting security events, enriching them with external context, and making real-time decisions through custom logic. By running Cloudflare One and its Developer Platform on the same global edge network, Cloudflare aims to let customers apply programmable, low-latency policies without stitching together separate infrastructure. ## What “Programmability” Means - Traditional programmability supports configuration and automation, such as sending Slack alerts when policies trigger. - True programmability allows security systems to: - Inspect an event before access is granted. - Query external systems for additional context. - Make or change an access decision in real time. - Example: a request to a regulated application could be checked against a learning management system to confirm that the user’s compliance training is current. Expired or missing certification would result in denial and redirection to training. ## Cloudflare’s Programmable SASE Architecture - Cloudflare’s network spans more than 330 cities and reaches approximately 95% of Internet-connected users within 50 milliseconds. - Cloudflare One and the Developer Platform run on the same infrastructure and use shared network primitives. - This enables Workers to extend inline services such as Access without requiring separate cloud infrastructure. - Customers can: - Call external risk APIs. - Add dynamic request headers. - Validate browser attributes. - Route traffic according to custom business logic. - Running custom logic at the edge reduces latency and avoids the operational overhead of webhook-based integrations and disconnected systems. ## Custom Actions in Security Policies - Conventional gateways generally limit policy outcomes to actions such as allow, block, isolate, or quarantine. - Cloudflare is expanding policies to support managed and custom actions. - Potential uses include: - Injecting headers based on user identity claims. - Obtaining real-time verdicts from external risk engines. - Restricting access based on location or working hours. - Updating risk lists based on scheduled analysis of user activity. - Custom actions can invoke a Worker when a Gateway HTTP policy matches, giving the code access to request context and allowing decisions in milliseconds. - Managed actions will offer templates for common use cases such as IT service management, redirects, and compliance workflows. ## Automated Device Session Revocation - One customer needed periodic re-authentication for Cloudflare One Client users, similar to traditional VPN session expiration. - Cloudflare’s built-in session controls were application-specific rather than global and time-based. - The customer implemented a scheduled Worker that: - Queries the Cloudflare Devices API. - Handles cursor-based pagination to retrieve registrations. - Calculates how long each device has been inactive. - Deletes registrations exceeding a configured inactivity threshold. - Forces affected users to authenticate again through their identity provider. - The example also supports environment-based configuration and a dry-run mode for testing before revocations are applied. Cloudflare’s recommendation is to treat SASE policies as programmable decision points rather than fixed allow-or-block rules. Combining Cloudflare One with edge Workers can provide faster, more context-aware security automation while reducing integration complexity.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Modernizing with agile SASE: a Cloudflare One blog takeover

The post argues that changing work patterns, AI agents, and Internet-based perimeters require organizations to move beyond fragmented legacy networks toward “agile SASE.” It presents Cloudflare One as a composable platform that combines networking and security on a global connectivity cloud, using single-pass processing to avoid service-chaining bottlenecks. Cloudflare positions this architecture as a faster path to modernization, beginning with focused use cases rather than a large-scale “big bang” migration. ## The Case for Agile SASE - Hybrid work and AI-driven traffic are making traditional corporate perimeters and office-based networks obsolete. - Legacy firewalls, VPN concentrators, and hardware appliances create a “fragmentation penalty.” - Technical debt accumulates through: - Conflicting firewall rules - Manual patching - Aging hardware - Infrastructure unable to handle AI-scale traffic - First-generation SASE platforms often shifted fragmentation from physical hardware into isolated cloud and operational silos. - The resulting problem is not a shortage of security data, but difficulty enforcing consistent policies across a borderless enterprise. ## Cloudflare One’s Single-Pass Architecture - Cloudflare describes zero trust as the security model and Cloudflare One as the platform for implementing it. - The platform converges networking and security through a global connectivity cloud spanning more than 300 cities. - Security checks can run simultaneously on every server rather than processing traffic sequentially through separate services. - This avoids service chaining, which can introduce latency and operational complexity. - Cloudflare frames the result as a programmable, composable platform rather than a collection of acquired or loosely connected tools. ## Five Themes for Network Modernization The company’s planned technical series focuses on: - **A new network standard:** Building a programmable, future-ready Internet foundation. - **Identity beyond passwords:** Combining human and device verification instead of relying only on credentials. - **Signal over noise:** Using AI to convert large volumes of security data into actionable guidance. - **The autonomous edge:** Improving performance and reducing friction as part of the security strategy. - **A unified vision:** Showing how enterprises and partners can standardize on Cloudflare One at scale. ## Programmability and Developer Integration - Cloudflare One runs alongside Cloudflare Workers, allowing teams to write code that responds to security events in real time. - This extends policy enforcement beyond simple allow/block decisions. - Organizations can automate more sophisticated security and operational workflows. - Cloudflare argues that this flexibility helps technology teams support faster business growth while improving protection. ## Practical Starting Points The post recommends beginning with focused modernization projects: - **Remote access:** Replace maintenance-heavy VPNs with clientless access and faster zero trust adoption. - **Email protection:** Detect phishing, Business Email Compromise, and related multi-channel threats with AI-powered controls. - **DNS filtering:** Block malicious websites for hybrid workers using DNS protection based on the 1.1.1.1 resolver. - **AI governance:** Identify shadow AI usage and control how organizational data enters generative and agentic AI systems. - **Branch networking:** Treat offices and coffee-shop workspaces as remote sites, reducing dependence on dedicated hardware. Organizations evaluating SASE should favor platforms that provide consistent policy enforcement, programmable controls, and incremental adoption. Cloudflare’s recommended entry point is to start with a specific need—such as VPN replacement or AI governance—and expand toward a unified connectivity and security architecture.

Read original(opens in new tab)
cloudflare4 min readCurated summary

How we rebuilt Next.js with AI in one week

Vinext is an experimental, Vite-based reimplementation of Next.js built in one week by one engineer and an AI model. It preserves much of Next.js’s API and project structure while avoiding the fragile process of adapting Next.js/Turbopack output for serverless platforms. Early results suggest builds can be up to 4× faster, client bundles up to 57% smaller, and Cloudflare Workers deployment can be handled with a single command. ## The Deployment Challenges of Next.js - Next.js provides an excellent developer experience but relies on a bespoke build and deployment toolchain. - Deploying to platforms such as Cloudflare, Netlify, or AWS Lambda requires reshaping Next.js output. - OpenNext addresses this problem but must reverse-engineer build artifacts, making it vulnerable to changes between Next.js versions. - Next.js’s planned adapters API improves deployment support but does not solve the underlying Turbopack dependency. - `next dev` runs only in Node.js, making it difficult to develop against platform-specific APIs such as Durable Objects, KV, and AI bindings. ## Vinext’s Vite-Based Architecture - Vinext reimplements the Next.js API surface directly on Vite rather than wrapping or adapting Next.js output. - Existing `app/`, `pages/`, and `next.config.js` files can be reused. - Developers install it with `npm install vinext` and replace `next` scripts with `vinext`. - It supports: - Routing - Server-side rendering - React Server Components - Server actions - Caching - Middleware - Hot module replacement - Vite’s Environment API allows the output to run across different platforms. ## Early Performance Results - Benchmarks compared vinext with Next.js 16 using the same 33-route App Router application. - Type checking and ESLint were disabled for Next.js to focus on compilation and bundling. - Static pre-rendering was disabled with `force-dynamic` for a fairer comparison. - Early results showed: - Production builds up to 4× faster - Gzipped client bundles up to 57% smaller - The results measure build performance, not serving performance, and come from a single test application. - The authors describe the figures as directional because both vinext and its supporting tools are still evolving. - Vite’s architecture and the upcoming Rust-based Rolldown bundler are identified as major sources of potential performance gains. ## Cloudflare Workers Deployment - `vinext deploy` builds the application, generates Worker configuration, and deploys it automatically. - Both the App Router and Pages Router are supported. - Applications retain client-side hydration, interactive components, navigation, and React state. - A Cloudflare KV cache handler provides Incremental Static Regeneration: ```ts import { KVCacheHandler } from "vinext/cloudflare"; import { setCacheHandler } from "next/cache"; setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE)); ``` - The cache layer is pluggable, allowing alternatives such as R2 or future Cache API improvements. - Because development and deployment can both run in `workerd`, applications can use Durable Objects, AI bindings, and other Cloudflare services without Node.js compatibility workarounds. ## Broader Ecosystem Potential - Although Cloudflare Workers is the initial target, roughly 95% of vinext is platform-independent Vite code. - Its routing, SSR pipeline, module shims, and React Server Components integration are not Cloudflare-specific. - A proof of concept reportedly ran on Vercel in under 30 minutes. - The project is open source and invites other hosting providers to contribute deployment targets. ## Experimental Status - Vinext is less than a week old and has not been tested under meaningful production-scale traffic. - The authors recommend caution before adopting it for critical applications. - Its test suite already includes more than 1,700 Vitest tests and 380 Playwright end-to-end tests, including tests ported from Next.js and OpenNext. - The project reportedly cost approximately $1,100 in AI-token usage to build. Vinext is best viewed as a promising experimental alternative rather than a drop-in replacement ready for every production workload. Teams interested in platform-native development and faster Vite-based builds can evaluate it carefully, while waiting for broader compatibility and real-world validation.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Code Mode: give agents an entire API in 1,000 tokens

Code Mode addresses a central MCP problem: giving agents broad tool access without overwhelming their context windows. Instead of exposing thousands of individually described tools, it provides a typed SDK and lets agents write sandboxed JavaScript to search specifications and execute API calls. Cloudflare’s new MCP server applies this approach to its entire API using only `search()` and `execute()`, reducing context usage by 99.9% to roughly 1,000 tokens. ## The Context-Window Problem - MCP makes external tools available to AI agents, but each tool’s description consumes model context. - Large APIs can require enormous token budgets merely to describe their endpoints. - A conventional MCP server for the Cloudflare API would consume approximately 1.17 million tokens. - This can exceed the context window of even advanced foundation models. ## Code Mode as a Compact API Interface - Agents write code against a typed SDK rather than selecting from thousands of separate tools. - Generated code serves as a compact, composable plan. - Agents can: - Explore available operations. - Chain multiple API calls. - Handle pagination and errors. - Return only the data needed for the task. - The tool footprint remains fixed as the underlying API grows. ## Cloudflare’s Two-Tool MCP Server - The server exposes only: - `search()` — searches the Cloudflare OpenAPI specification. - `execute()` — runs JavaScript against the Cloudflare API. - The full OpenAPI specification stays outside the model context. - `$refs` are pre-resolved, allowing agents to inspect endpoint metadata directly through code. - Agents can filter endpoints by product, path, tags, or other metadata. ## Sandboxed Execution - Both tools execute code inside a Dynamic Worker isolate based on lightweight V8 sandboxes. - The environment has: - No filesystem access. - No environment variables exposed to generated code. - External fetches disabled by default. - Outbound requests can be explicitly enabled through controlled fetch handlers. ## Example: Finding DDoS Protection Endpoints - For a request to protect an origin from DDoS attacks, an agent can first consult documentation or skills. - It then uses `search()` to inspect the OpenAPI specification. - A JavaScript query can locate zone endpoints related to WAF and rulesets. - The search narrows more than 2,500 Cloudflare endpoints to relevant operations such as: - Listing and updating WAF packages and rules. - Listing and creating zone rulesets. - Reading and updating entry-point rulesets. - Creating and updating rules within a ruleset. - Once the relevant endpoints are identified, `execute()` can perform coordinated API requests in one sandboxed run. ## SDK Availability - Cloudflare is open-sourcing a Code Mode SDK as part of the Cloudflare Agents SDK. - The same pattern can be used to build more context-efficient MCP servers and AI agents. Code Mode is most useful for large, evolving APIs: expose a small, stable tool surface, let agents discover capabilities programmatically, and execute only the focused operations required for each task.

Read original(opens in new tab)
cloudflare2 min readCurated summary

Introducing Markdown for Agents

AI agents increasingly need structured, efficient access to web content, making traditional HTML a costly format for machine consumption. Cloudflare’s Markdown for Agents lets enabled websites serve HTML pages as Markdown when clients request `text/markdown`, reducing token usage and parsing overhead. The post argues that websites should treat AI agents as first-class visitors alongside humans and search engines. ## Why Markdown Matters for AI - Markdown conveys document structure with far less surrounding markup than HTML. - A Markdown heading such as `## About Us` uses roughly 3 tokens, compared with 12–15 tokens for an equivalent HTML heading. - The post’s HTML uses about 16,180 tokens, while its Markdown version uses approximately 3,150—a reduction of about 80%. - Converting HTML to Markdown inside an AI pipeline adds computation, cost, and complexity, and may not preserve the publisher’s intended structure. ## How Markdown for Agents Works - Cloudflare-enabled zones can respond to content negotiation requests containing: ```http Accept: text/markdown ``` - Cloudflare fetches the original HTML from the origin, converts it to Markdown at the network edge, and returns the converted response. - Clients can request Markdown with `curl`, while Workers-based agents can use a `fetch()` request with `Accept: "text/markdown, text/html"`. - Responses use `Content-Type: text/markdown` and include `Vary: accept`. - Existing coding agents, including Claude Code and OpenCode, already send compatible `Accept` headers. ## Token Estimates and Agent Workflows - Converted responses include an `x-markdown-tokens` header. - Agents can use this estimate to: - Determine whether content fits within a context window - Plan chunking strategies - Manage processing costs and limits ## Content Signals - Markdown responses include: ```http Content-Signal: ai-train=yes, search=yes, ai-input=yes ``` - These signals indicate that the content may be used for AI training, search results, and AI input, including agentic applications. - Cloudflare says future versions will support custom Content Signal policies. ## Availability - Cloudflare enabled Markdown for Agents on its Developer Documentation and Blog. - AI crawlers and agents can test the feature by requesting those pages with `Accept: text/markdown`. Web publishers can make their content more accessible to AI systems by supporting Markdown negotiation, while agents should request `text/markdown` whenever available to reduce tokens, parsing work, and processing cost.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Improve global upload performance with R2 Local Uploads

R2 Local Uploads improves global upload performance by first writing object data near the client, then asynchronously copying it to the bucket’s region. Objects become immediately available and remain strongly consistent during replication. Cloudflare reports up to a 75% reduction in upload request duration for cross-region uploads. ## Faster Global Uploads - Local Uploads targets `PutObject` and `UploadPart` requests made far from the bucket’s location. - Synthetic tests showed median upload TTLB dropping from about 2 seconds to 500 milliseconds. - Tests used 5 MB objects uploaded from Western North America to an Asia-Pacific bucket at roughly 20 requests per second. - The feature is available in open beta and can be enabled in the Cloudflare Dashboard or with: ```bash npx wrangler r2 bucket local-uploads enable [BUCKET] ``` ## The Cross-Region Distance Problem - R2 requests enter through a globally distributed Gateway Worker, which handles authentication and routing. - Object metadata is managed by a distributed Durable Object Metadata Service. - Encrypted object data is stored in R2’s distributed storage infrastructure. - Without Local Uploads, streamed data must travel to the bucket’s region before the upload can complete. - Long-distance transfers can increase latency and introduce upload variability or reliability issues. ## How Local Uploads Works - If the client and bucket are in the same region, R2 uses its normal storage flow. - If they are in different regions: - Data is initially written to storage near the client. - Metadata is published in the bucket’s region. - The object becomes readable as soon as the local write completes. - Background replication later copies the data to the bucket’s primary region. - There is no read-unavailability window while replication is in progress. - Local Uploads is unavailable for jurisdiction-restricted buckets, including EU and FedRAMP buckets. ## When to Use It - Applications have users or devices distributed across multiple regions. - Upload speed and reliability are important. - You want faster writes without moving the bucket’s primary location. - R2’s Metrics page can help identify regional request patterns through the “Request Distribution by Region” graph. ## Replication Architecture - R2 represents the background copy operation as a replication task. - Cloudflare Queues process these tasks asynchronously. - Queues provide: - Rate control for replication. - Automatic retries. - Dead-letter queue support for failures. - Sharding across multiple queues for each storage region. - When publishing object metadata, R2 atomically: - Stores the object metadata. - Creates a pending-replica key describing unfinished replication work. - Creates a timestamp-based replication marker that determines when the task enters a queue. - The pending-replica record includes the replication plan, source and destination locations, mode, priority, and whether the source can be deleted after successful replication. Local Uploads is a strong fit for globally distributed upload-heavy workloads. Enable it when cross-region write latency matters, while keeping in mind the restriction on jurisdiction-constrained buckets.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Building vertical microfrontends on Cloudflare’s platform

Cloudflare’s new Vertical Microfrontends (VMFE) Worker template lets independent teams map separate Workers to different URL paths on one domain. Unlike horizontal microfrontends, each team owns an entire vertical slice—including its framework, frontend, deployment pipeline, and operations. The approach enables technology flexibility and team autonomy while using view transitions and preloading to preserve a seamless user experience. ## Vertical Microfrontend Architecture - Applications are divided by URL path rather than by components on a single page: - `/` → Marketing - `/docs` → Documentation - `/blog` → Blog - `/dash` → Dashboard - Routes can be split into more granular verticals, such as: - `/dash/product-a` → Worker A - `/dash/product-b` → Worker B - Each route can be an entirely separate frontend project with its own: - Framework and libraries - Codebase - CI/CD pipeline - Owning team - This allows teams to choose technologies suited to their needs—for example, Astro for marketing and React for a dashboard. - It also reduces the risk of monolithic releases, where one team’s regression can force multiple teams to roll back. - Cloudflare applies a similar model internally, routing users from its core dashboard to separate products such as Zero Trust based on URL paths. ## Creating a Unified Experience - Independent applications must still appear cohesive to users. - Users generally accept distinct experiences between marketing, documentation, and dashboards. - However, related areas within one product—such as `/dash/product-a` and `/dash/product-b`—should not expose their separate repositories or Workers. - The goal is to hide implementation boundaries while preserving independent ownership. ## CSS View Transitions - Navigating between separately deployed Workers can otherwise produce a brief blank screen while the next document loads. - CSS View Transitions can preserve shared elements, such as navigation, during page changes. - The transition API allows teams to: - Keep DOM elements visible across navigations - Animate differences between the old and new pages - Make multi-page applications feel more like a single-page application - A small CSS rule can assign a transition name to the navigation and apply an eased animation to the page transition. ## Document Preloading - Seamless animation is not enough; navigation should also feel immediate. - The Speculation Rules API lets compatible browsers prefetch likely future document navigations. - Teams can define a `script` with `type="speculationrules"` and list URLs for related vertical slices, such as links in shared navigation. - Chrome, Edge, and Opera support the newer API, while Firefox and Safari currently do not. Cloudflare’s VMFE approach is most useful when teams need independent ownership and technology choices without sacrificing a unified product experience. Path-based Worker routing, shared visual conventions, view transitions, and selective prefetching provide the foundation for making separate applications behave like one.

Read original(opens in new tab)
cloudflare2 min readCurated summary

Introducing Moltworker: a self-hosted personal AI agent, minus the minis

Moltworker adapts the self-hosted Moltbot personal AI assistant to run on Cloudflare without requiring users to buy a dedicated Mac mini. It combines a Cloudflare Worker, Sandbox SDK, Browser Rendering, R2, AI Gateway, and Cloudflare Access to provide a globally available, secured deployment. The result is a managed infrastructure layer around Moltbot’s standard Gateway runtime while preserving its integrations and persistent state. ## Running a Personal Agent on Cloudflare - Cloudflare Workers increasingly supports Node.js APIs natively, reducing the need for compatibility hacks and making it easier to run existing JavaScript and TypeScript packages. - An internal test of the 1,000 most popular NPM packages found that only 15 relevant packages failed to run in Workers. - Although much of Moltbot runs inside a container, improved Workers compatibility is useful for building agent logic closer to users. - Cloudflare’s Developer Platform provides the main infrastructure components: - **Sandboxes** for securely running untrusted code. - **Browser Rendering** for automated headless browser interactions. - **R2** for persistent object storage. - Cloudflare’s global network for scalability and security. ## Moltworker Architecture - Moltworker consists of: - An entrypoint Worker serving as an API router and proxy. - Cloudflare Access protecting the Worker and administration interface. - A Sandbox container running Moltbot’s standard Gateway and integrations. - R2 for persistent storage. - This structure separates the public API and administrative layer from the isolated environment where the agent executes. ## AI Gateway Integration - Cloudflare AI Gateway proxies requests between Moltbot and AI providers. - It provides: - Centralized request visibility. - Cost monitoring, logs, and analytics. - Provider and model switching without changing Moltbot code. - Fallback providers or models for improved reliability. - Secrets can be managed through: - **Bring Your Own Key (BYOK)**, where provider credentials are stored centrally. - **Unified Billing**, where users purchase credits and Cloudflare handles provider billing. - Integration requires creating an AI Gateway instance, enabling a provider such as Anthropic, and setting `ANTHROPIC_BASE_URL`; Moltbot itself does not need code changes. ## Sandbox-Based Execution - The Sandbox SDK runs agent code in isolated environments built on Cloudflare Containers. - It provides simplified APIs for: - Executing commands. - Managing files and directories. - Running background processes. - Exposing services. - Executing code in contexts such as Python. - The SDK abstracts container lifecycle, networking, filesystem, and process-management concerns behind TypeScript APIs. Moltworker offers a way to run a capable personal AI agent online with managed security, storage, browser automation, and model access—without maintaining dedicated hardware.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Building a serverless, post-quantum Matrix homeserver

The post describes a proof-of-concept Matrix homeserver ported from Synapse to Cloudflare Workers. It replaces traditional VPS, PostgreSQL, Redis, and filesystem infrastructure with Workers, Durable Objects, D1, KV, and R2, reducing operational overhead and allowing costs to fall near zero when idle. The design also provides post-quantum TLS automatically while preserving Matrix’s end-to-end encryption, though the homeserver still exposes metadata. ## From Synapse to Cloudflare Workers - Traditional Synapse deployments depend on: - PostgreSQL for persistent state - Redis for caching - Filesystem storage for media - VPS infrastructure and operational maintenance - The proof of concept reimplemented core Matrix functionality in TypeScript with Hono, including: - Event authorization - Room state resolution - Cryptographic verification - Cloudflare services replace the traditional components: - Durable Objects provide strongly consistent, atomic coordination. - D1 replaces PostgreSQL. - KV replaces Redis. - R2 replaces filesystem-based media storage. ## Benefits of a Serverless Homeserver - Deployment becomes a single `wrangler deploy` command. - Cloudflare provides TLS termination, load balancing, DDoS protection, and global distribution. - Request-based pricing means the homeserver can cost almost nothing during periods of inactivity. - Workers execute close to users in more than 300 locations, reducing latency for globally distributed communities. - Built-in security features reduce the need to configure firewalls, rate limiting, WAF rules, and IP reputation systems manually. ## Post-Quantum TLS and Matrix Encryption - Cloudflare’s TLS 1.3 connections use hybrid `X25519MLKEM768`. - This combines: - X25519, a classical elliptic-curve algorithm - ML-KEM, a lattice-based post-quantum algorithm standardized by NIST - The hybrid design requires both cryptographic systems to be broken before the connection is compromised. - Traditional deployments would need to upgrade cryptographic libraries, configure cipher suites, test client compatibility, and monitor negotiation failures. - Workers provide this protection automatically through Cloudflare’s infrastructure. ## How Messages Are Protected - Matrix clients encrypt messages locally using Megolm before sending them. - The encrypted Megolm payload is then transported over TLS using post-quantum hybrid key agreement. - The Worker terminates TLS but receives only ciphertext, which it stores and routes without seeing plaintext. - Recipients download the ciphertext over another protected TLS connection and decrypt it locally. - This creates two independent encryption layers: - TLS protects data in transit. - Megolm end-to-end encryption protects message contents from the homeserver and infrastructure providers. ## Metadata and Privacy Limits - The homeserver operator can still observe metadata, including: - Room membership - Room existence - Message timing - Other routing and account information - Message contents remain inaccessible because they are encrypted before reaching the server. - Encrypted-room media is also encrypted client-side, and private keys remain on user devices. ## Storage Architecture - The design assigns each storage primitive to the consistency model it supports best. - D1 stores durable, queryable Matrix data, including users, rooms, events, and device keys across more than 25 tables. - Durable Objects handle real-time coordination and the strong consistency needed for Matrix state resolution. - KV provides cache-like storage, while R2 handles media and filesystem-style objects. The project demonstrates that a Matrix homeserver can be made substantially easier to operate with serverless infrastructure while gaining globally distributed execution and automatic post-quantum transport security. It remains a personal proof of concept, so production deployments should evaluate feature completeness, scalability, compatibility, and the privacy implications of relying on Cloudflare.

Read original(opens in new tab)
cloudflare3 min readCurated summary

Astro is joining Cloudflare

Astro Technology Company is joining Cloudflare, with the Astro team continuing to develop the framework as Cloudflare employees. Astro will remain MIT-licensed, open source, portable across platforms, and governed through a public roadmap and open contributions. The partnership aims to strengthen Astro’s role as a fast, accessible framework for content-driven websites, with Astro 6 introducing major development and runtime improvements. ## What the Cloudflare Acquisition Means - Astro remains: - Open source and MIT-licensed - Open to community contributions - Supported by a public roadmap and open governance - Deployable across any cloud or hosting platform - Astro’s full-time employees are joining Cloudflare and will continue working on the framework. - Cloudflare will support the Astro Ecosystem Fund alongside partners such as Webflow, Netlify, Wix, Sentry, and Stainless. - The project’s commitment to portability and platform independence will not change. ## Why Developers Choose Astro Astro has focused on content-driven websites rather than attempting to serve every type of application equally. - **Content-driven:** Built to showcase websites’ content. - **Server-first:** Renders HTML on the server for better performance. - **Fast by default:** Designed to make slow websites difficult to build. - **Easy to use:** Accessible without deep JavaScript tooling expertise. - **Developer-focused:** Provides tools and resources intended to support successful development. Astro’s Islands Architecture supports this approach: - Most pages are delivered as fast, static HTML. - Interactive sections can be rendered as client-side “islands.” - Developers can use multiple UI frameworks on the same page, including React, Vue, Svelte, and Solid. ## Shared Vision for Web Development Cloudflare and Astro share a goal of making the web faster and easier to build on. - Astro was created in 2021 to simplify the increasingly difficult process of building fast websites. - Its simple, structured foundation also helps coding agents and AI-assisted development produce better results. - Platforms including Webflow Cloud, Wix Vibe, and Stainless use Astro to help their customers create and publish websites. - These platforms run on or integrate with Cloudflare infrastructure while using Astro as their content and application foundation. ## Astro 6 Improvements Astro 6 is entering beta, with general availability expected soon. - A redesigned development server is built on Vite’s Environments API. - With the Cloudflare Vite plugin, local development can run in `workerd`, the Cloudflare Workers runtime. - Developers can locally use production-like APIs such as: - Durable Objects - D1 - KV - Agents - The Vite Environments API is not limited to Cloudflare; other JavaScript runtimes can provide similar integrations. - Live Content Collections are now stable, allowing content to update without rebuilding the site while retaining validation and caching. - Additional features include first-class Content Security Policy support, simpler APIs, and Zod 4 support. Cloudflare’s investment is intended to give Astro greater long-term support without changing its open, portable character. Developers can try the Astro 6 beta with `npm create astro@latest -- --ref next` or upgrade an existing project using `npx @astrojs/upgrade beta`.

Read original(opens in new tab)
cloudflare3 min readCurated summary

How Workers powers our internal maintenance scheduling pipeline

Cloudflare built an automated maintenance scheduler on Cloudflare Workers to prevent overlapping infrastructure changes from disrupting connectivity or customer-specific routing. The system evaluates the full network state, identifies conflicts across maintenance events, and alerts operators before unsafe schedules are approved. Its key design shift was from loading all operational data into one Worker to using graph-based, on-demand data retrieval that respects Workers’ memory limits. ## Why Manual Maintenance Planning Was No Longer Enough - Cloudflare operates data centers in more than 330 cities, making manual coordination increasingly unreliable. - Maintenance can create conflicts when: - Redundant edge routers in the same metro area are taken offline simultaneously. - All data centers selected by a customer’s Dedicated CDN Egress IPs (“Aegis”) pool become unavailable. - These failures could cause higher latency, connectivity loss, or 5xx errors. - The scheduler centralizes network state and warns operators when maintenance windows overlap in unsafe ways. ## Modeling Operational Safety as Constraints - Each safety rule begins with proposed maintenance items, such as routers or server groups. - The system finds calendar events whose time windows overlap with the proposed change. - It then combines those events with product data, including Aegis pools and their associated data center IDs. - For example, if an Aegis customer’s pool uses data centers 21 and 45, scheduling both for simultaneous downtime violates the constraint that at least one must remain online. - Operators receive conflict notifications and can reschedule maintenance before it affects customers. ## Reducing Data Usage on Workers - The initial design loaded server relationships, product configurations, and health metrics into a single Worker. - This quickly caused out-of-memory errors. - The scheduler instead loads only data relevant to the maintenance location and affected relationships. - A router maintenance request in Frankfurt, for example, does not need unrelated infrastructure data from Australia. ## Graph Processing with Typed Associations - Cloudflare modeled infrastructure and product relationships as a graph: - **Objects** represent entities such as routers, data centers, and Aegis pools. - **Associations** represent relationships between those entities. - Inspired by Facebook’s TAO system, the team created an interface supporting operations such as: - `object_get()` to retrieve an object. - `assoc_get()` to stream typed relationships. - `assoc_count()` to count related objects. - Constraints can retrieve only the associations they need, such as which Aegis pools include a particular data center and how many data centers each pool contains. - Parallel lookups and deduplication reduce both execution time and memory consumption. Cloudflare’s scheduler demonstrates how Workers can serve as a centralized safety layer for complex infrastructure operations. The practical recommendation is to represent operational dependencies as typed graphs and fetch relationship data incrementally, rather than loading the entire network and product state into each execution.

Read original(opens in new tab)