Author: guillaume

  • Queues – Cloudflare Queues now available on Workers Free plan

    Cloudflare Queues is now part of the Workers free plan, offering guaranteed message delivery across up to 10,000 queues to either Cloudflare Workers or HTTP pull consumers. Every Cloudflare account now includes 10,000 operations per day across reads, writes, and deletes. For more details on how each operation is defined, refer to Queues pricing.

    All features of the existing Queues functionality are available on the free plan, including unlimited event subscriptions. Note that the maximum retention period on the free tier, however, is 24 hours rather than 14 days.

    If you are new to Cloudflare Queues, follow this guide or try one of our tutorials to get started.

  • Workflows, Workers – Visualize your Workflows in the Cloudflare dashboard

    Cloudflare Workflows now automatically generates visual diagrams from your code

    Your Workflow is parsed to provide a visual map of the Workflow structure, allowing you to:

    • Understand how steps connect and execute
    • Visualize loops and nested logic
    • Follow branching paths for conditional logic

    Example diagram

    You can collapse loops and nested logic to see the high-level flow, or expand them to see every step.

    Workflow diagrams are available in beta for all JavaScript and TypeScript Workflows. Find your Workflows in the Cloudflare dashboard to see their diagrams.

  • R2 – Improve Global Upload Performance with R2 Local Uploads – Now in Open Beta

    Local Uploads is now available in open beta. Enable it on your R2 bucket to improve upload performance when clients upload data from a different region than your bucket. With Local Uploads enabled, object data is written to storage infrastructure near the client, then asynchronously replicated to your bucket. The object is immediately accessible and remains strongly consistent throughout. Refer to How R2 works for details on how data is written to your bucket.

    In our tests, we observed up to 75% reduction in Time to Last Byte (TTLB) for upload requests when Local Uploads is enabled.

    Local Uploads latency comparison showing p50 TTLB dropping from around 2 seconds to 500ms after enabling Local Uploads

    This feature is ideal when:

    • Your users are globally distributed
    • Upload performance and reliability is critical to your application
    • You want to optimize write performance without changing your bucket’s primary location

    To enable Local Uploads on your bucket, find Local Uploads in your bucket settings in the Cloudflare Dashboard, or run:

    npx wrangler r2 bucket local-uploads enable <BUCKET_NAME>

    Enabling Local Uploads on a bucket is seamless: existing uploads will complete as expected and there’s no interruption to traffic. There is no additional cost to enable Local Uploads. Upload requests incur the standard Class A operation costs same as upload requests made without Local Uploads.

    For more information, refer to Local Uploads.

  • R2 – Improve Global Upload Performance with R2 Local Uploads – Now in Open Beta

    Local Uploads is now available in open beta. Enable it on your R2 bucket to improve upload performance when clients upload data from a different region than your bucket. With Local Uploads enabled, object data is written to storage infrastructure near the client, then asynchronously replicated to your bucket. The object is immediately accessible and remains strongly consistent throughout. Refer to How R2 works for details on how data is written to your bucket.

    In our tests, we observed up to 75% reduction in Time to Last Byte (TTLB) for upload requests when Local Uploads is enabled.

    Local Uploads latency comparison showing p50 TTLB dropping from around 2 seconds to 500ms after enabling Local Uploads

    This feature is ideal when:

    • Your users are globally distributed
    • Upload performance and reliability is critical to your application
    • You want to optimize write performance without changing your bucket’s primary location

    To enable Local Uploads on your bucket, find Local Uploads in your bucket settings in the Cloudflare Dashboard, or run:

    npx wrangler r2 bucket local-uploads enable <BUCKET_NAME>

    Enabling Local Uploads on a bucket is seamless: existing uploads will complete as expected and there’s no interruption to traffic. There is no additional cost to enable Local Uploads. Upload requests incur the standard Class A operation costs same as upload requests made without Local Uploads.

    For more information, refer to Local Uploads.

  • Agents, Workflows – Agents SDK v0.3.7: Workflows integration, synchronous state, and scheduleEvery()

    The latest release of the Agents SDK brings first-class support for Cloudflare Workflows, synchronous state management, and new scheduling capabilities.

    Cloudflare Workflows integration

    Agents excel at real-time communication and state management. Workflows excel at durable execution. Together, they enable powerful patterns where Agents handle WebSocket connections while Workflows handle long-running tasks, retries, and human-in-the-loop flows.

    Use the new AgentWorkflow class to define workflows with typed access to your Agent:

    • JavaScript

      import { AgentWorkflow } from "agents/workflows";
      export class ProcessingWorkflow extends AgentWorkflow {
      async run(event, step) {
      // Call Agent methods via RPC
      await this.agent.updateStatus(event.payload.taskId, "processing");
      // Non-durable: progress reporting to clients
      await this.reportProgress({ step: "process", percent: 0.5 });
      this.broadcastToClients({ type: "update", taskId: event.payload.taskId });
      // Durable via step: idempotent, won't repeat on retry
      await step.mergeAgentState({ taskProgress: 0.5 });
      const result = await step.do("process", async () => {
      return processData(event.payload.data);
      });
      await step.reportComplete(result);
      return result;
      }
      }
    • TypeScript

      import { AgentWorkflow } from "agents/workflows";
      import type { AgentWorkflowEvent, AgentWorkflowStep } from "agents/workflows";
      export class ProcessingWorkflow extends AgentWorkflow<MyAgent, TaskParams> {
      async run(event: AgentWorkflowEvent<TaskParams>, step: AgentWorkflowStep) {
      // Call Agent methods via RPC
      await this.agent.updateStatus(event.payload.taskId, "processing");
      // Non-durable: progress reporting to clients
      await this.reportProgress({ step: "process", percent: 0.5 });
      this.broadcastToClients({ type: "update", taskId: event.payload.taskId });
      // Durable via step: idempotent, won't repeat on retry
      await step.mergeAgentState({ taskProgress: 0.5 });
      const result = await step.do("process", async () => {
      return processData(event.payload.data);
      });
      await step.reportComplete(result);
      return result;
      }
      }

    Start workflows from your Agent with runWorkflow() and handle lifecycle events:

    • JavaScript

      export class MyAgent extends Agent {
      async startTask(taskId, data) {
      const instanceId = await this.runWorkflow("PROCESSING_WORKFLOW", {
      taskId,
      data,
      });
      return { instanceId };
      }
      async onWorkflowProgress(workflowName, instanceId, progress) {
      this.broadcast(JSON.stringify({ type: "progress", progress }));
      }
      async onWorkflowComplete(workflowName, instanceId, result) {
      console.log(`Workflow ${instanceId} completed`);
      }
      async onWorkflowError(workflowName, instanceId, error) {
      console.error(`Workflow ${instanceId} failed:`, error);
      }
      }
    • TypeScript

      export class MyAgent extends Agent {
      async startTask(taskId: string, data: string) {
      const instanceId = await this.runWorkflow("PROCESSING_WORKFLOW", {
      taskId,
      data,
      });
      return { instanceId };
      }
      async onWorkflowProgress(
      workflowName: string,
      instanceId: string,
      progress: unknown,
      ) {
      this.broadcast(JSON.stringify({ type: "progress", progress }));
      }
      async onWorkflowComplete(
      workflowName: string,
      instanceId: string,
      result?: unknown,
      ) {
      console.log(`Workflow ${instanceId} completed`);
      }
      async onWorkflowError(
      workflowName: string,
      instanceId: string,
      error: unknown,
      ) {
      console.error(`Workflow ${instanceId} failed:`, error);
      }
      }

    Key workflow methods on your Agent:

    • runWorkflow(workflowName, params, options?) — Start a workflow with optional metadata
    • getWorkflow(workflowId) / getWorkflows(criteria?) — Query workflows with cursor-based pagination
    • approveWorkflow(workflowId) / rejectWorkflow(workflowId) — Human-in-the-loop approval flows
    • pauseWorkflow(), resumeWorkflow(), terminateWorkflow() — Workflow control

    Synchronous setState()

    State updates are now synchronous with a new validateStateChange() validation hook:

    • JavaScript

      export class MyAgent extends Agent {
      validateStateChange(oldState, newState) {
      // Return false to reject the change
      if (newState.count < 0) return false;
      // Return modified state to transform
      return { ...newState, lastUpdated: Date.now() };
      }
      }
    • TypeScript

      export class MyAgent extends Agent<Env, State> {
      validateStateChange(oldState: State, newState: State): State | false {
      // Return false to reject the change
      if (newState.count < 0) return false;
      // Return modified state to transform
      return { ...newState, lastUpdated: Date.now() };
      }
      }

    scheduleEvery() for recurring tasks

    The new scheduleEvery() method enables fixed-interval recurring tasks with built-in overlap prevention:

    • JavaScript

      // Run every 5 minutes
      await this.scheduleEvery("syncData", 5 * 60 * 1000, { source: "api" });
    • TypeScript

      // Run every 5 minutes
      await this.scheduleEvery("syncData", 5 * 60 * 1000, { source: "api" });

    Callable system improvements

    • Client-side RPC timeout — Set timeouts on callable method invocations
    • StreamingResponse.error(message) — Graceful stream error signaling
    • getCallableMethods() — Introspection API for discovering callable methods
    • Connection close handling — Pending calls are automatically rejected on disconnect
    • JavaScript

      await agent.call("method", [args], {
      timeout: 5000,
      stream: { onChunk, onDone, onError },
      });
    • TypeScript

      await agent.call("method", [args], {
      timeout: 5000,
      stream: { onChunk, onDone, onError },
      });

    Email and routing enhancements

    Secure email reply routing — Email replies are now secured with HMAC-SHA256 signed headers, preventing unauthorized routing of emails to agent instances.

    Routing improvements:

    • basePath option to bypass default URL construction for custom routing
    • Server-sent identity — Agents send name and agent type on connect
    • New onIdentity and onIdentityChange callbacks on the client
    • JavaScript

      const agent = useAgent({
      basePath: "user",
      onIdentity: (name, agentType) => console.log(`Connected to ${name}`),
      });
    • TypeScript

      const agent = useAgent({
      basePath: "user",
      onIdentity: (name, agentType) => console.log(`Connected to ${name}`),
      });

    Upgrade

    To update to the latest version:

    npm i agents@latest

    For the complete Workflows API reference and patterns, see Run Workflows.

  • KV – Reduced minimum cache TTL for Workers KV to 30 seconds

    The minimum cacheTtl parameter for Workers KV has been reduced from 60 seconds to 30 seconds. This change applies to both get() and getWithMetadata() methods.

    This reduction allows you to maintain more up-to-date cached data and have finer-grained control over cache behavior. Applications requiring faster data refresh rates can now configure cache durations as low as 30 seconds instead of the previous 60-second minimum.

    The cacheTtl parameter defines how long a KV result is cached at the global network location it is accessed from:

    // Read with custom cache TTL
    const value = await env.NAMESPACE.get("my-key", {
    cacheTtl: 30, // Cache for minimum 30 seconds (previously 60)
    });
    // getWithMetadata also supports the reduced cache TTL
    const valueWithMetadata = await env.NAMESPACE.getWithMetadata("my-key", {
    cacheTtl: 30, // Cache for minimum 30 seconds
    });

    The default cache TTL remains unchanged at 60 seconds. Upgrade to the latest version of Wrangler to be able to use 30 seconds cacheTtl.

    This change affects all KV read operations using the binding API. For more information, consult the Workers KV cache TTL documentation.

  • Magic WAN, Magic Transit, Cloudflare One – BGP over GRE and IPsec tunnels

    Magic WAN and Magic Transit customers can use the Cloudflare dashboard to configure and manage BGP peering between their networks and their Magic routing table when using IPsec and GRE tunnel on-ramps (beta).

    Using BGP peering allows customers to:

    • Automate the process of adding or removing networks and subnets.
    • Take advantage of failure detection and session recovery features.

    With this functionality, customers can:

    • Establish an eBGP session between their devices and the Magic WAN / Magic Transit service when connected via IPsec and GRE tunnel on-ramps.
    • Secure the session by MD5 authentication to prevent misconfigurations.
    • Exchange routes dynamically between their devices and their Magic routing table.

    For configuration details, refer to:

  • Workers AI – Launching FLUX.2 [klein] 9B on Workers AI

    We have partnered with Black Forest Labs (BFL) again to bring their optimized FLUX.2 [klein] 9B model to Workers AI. This distilled model offers enhanced quality compared to the 4B variant, while maintaining cost-effective pricing. With a fixed 4-step inference process, Klein 9B is ideal for rapid prototyping and real-time applications where both speed and quality matter.

    Read the BFL blog to learn more about the model itself, or try it out yourself on our multi modal playground.

    Pricing documentation is available on the model page or pricing page.

    Workers AI platform specifics

    The model hosted on Workers AI is optimized for speed with a fixed 4-step inference process and supports up to 4 image inputs. Since this is a distilled model, the steps parameter is fixed at 4 and cannot be adjusted. Like FLUX.2 [dev] and FLUX.2 [klein] 4B, this image model uses multipart form data inputs, even if you just have a prompt.

    With the REST API, the multipart form data input looks like this:

    curl --request POST
    --url 'https://api.cloudflare.com/client/v4/accounts/{ACCOUNT}/ai/run/@cf/black-forest-labs/flux-2-klein-9b'
    --header 'Authorization: Bearer {TOKEN}'
    --header 'Content-Type: multipart/form-data'
    --form 'prompt=a sunset at the alps'
    --form width=1024
    --form height=1024

    With the Workers AI binding, you can use it as such:

    const form = new FormData();
    form.append("prompt", "a sunset with a dog");
    form.append("width", "1024");
    form.append("height", "1024");
    const resp = await env.AI.run("@cf/black-forest-labs/flux-2-klein-9b", {
    multipart: {
    body: form,
    contentType: "multipart/form-data",
    },
    });

    The parameters you can send to the model are detailed here:

    JSON Schema for Model

    Required Parameters

    • prompt (string) – Text description of the image to generate

    Optional Parameters

    • input_image_0 (string) – Binary image
    • input_image_1 (string) – Binary image
    • input_image_2 (string) – Binary image
    • input_image_3 (string) – Binary image
    • guidance (float) – Guidance scale for generation. Higher values follow the prompt more closely
    • width (integer) – Width of the image, default 1024 Range: 256-1920
    • height (integer) – Height of the image, default 768 Range: 256-1920
    • seed (integer) – Seed for reproducibility

    Note: Since this is a distilled model, the steps parameter is fixed at 4 and cannot be adjusted.

    Multi-reference images

    The FLUX.2 klein-9b model supports generating images based on reference images, just like FLUX.2 [dev] and FLUX.2 [klein] 4B. You can use this feature to apply the style of one image to another, add a new character to an image, or iterate on past generated images. You would use it with the same multipart form data structure, with the input images in binary. The model supports up to 4 input images.

    For the prompt, you can reference the images based on the index, like take the subject of image 1 and style it like image 0 or even use natural language like place the dog beside the woman.

    You must name the input parameter as input_image_0, input_image_1, input_image_2, input_image_3 for it to work correctly. All input images must be smaller than 512×512.

    curl --request POST
    --url 'https://api.cloudflare.com/client/v4/accounts/{ACCOUNT}/ai/run/@cf/black-forest-labs/flux-2-klein-9b'
    --header 'Authorization: Bearer {TOKEN}'
    --header 'Content-Type: multipart/form-data'
    --form 'prompt=take the subject of image 1 and style it like image 0'
    --form input_image_0=@/Users/johndoe/Desktop/icedoutkeanu.png
    --form input_image_1=@/Users/johndoe/Desktop/me.png
    --form width=1024
    --form height=1024

    Through Workers AI Binding:

    //helper function to convert ReadableStream to Blob
    async function streamToBlob(stream: ReadableStream, contentType: string): Promise<Blob> {
    const reader = stream.getReader();
    const chunks = [];
    while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    chunks.push(value);
    }
    return new Blob(chunks, { type: contentType });
    }
    const image0 = await fetch("http://image-url");
    const image1 = await fetch("http://image-url");
    const form = new FormData();
    const image_blob0 = await streamToBlob(image0.body, "image/png");
    const image_blob1 = await streamToBlob(image1.body, "image/png");
    form.append('input_image_0', image_blob0)
    form.append('input_image_1', image_blob1)
    form.append('prompt', 'take the subject of image 1 and style it like image 0')
    const resp = await env.AI.run("@cf/black-forest-labs/flux-2-klein-9b", {
    multipart: {
    body: form,
    contentType: "multipart/form-data"
    }
    })
  • Zero Trust WARP Client – WARP client for Windows (version 2026.1.89.1)

    A new Beta release for the Windows WARP client is now available on the beta releases downloads page.

    This release contains minor fixes, improvements, and new features.

    Changes and improvements

    • Improvements to multi-user mode. Fixed an issue where when switching from a pre-login registration to a user registration, Mobile Device Management (MDM) configuration association could be lost.
    • Added a new feature to manage NetBIOS over TCP/IP functionality on the Windows client. NetBIOS over TCP/IP on the Windows client is now disabled by default and can be enabled in device profile settings.
    • Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
    • Improvement for the Windows client certificate posture check to ensure logged results are from checks that run once users log in.
    • Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.

    Known issues

    • For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 KB5062553 or higher for resolution.

    • Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.

    • DNS resolution may be broken when the following conditions are all true:

      • WARP is in Secure Web Gateway without DNS filtering (tunnel-only) mode.
      • A custom DNS server address is configured on the primary network adapter.
      • The custom DNS server address on the primary network adapter is changed while WARP is connected.

      To work around this issue, reconnect the WARP client by toggling off and back on.

  • Zero Trust WARP Client – WARP client for macOS (version 2026.1.89.1)

    A new Beta release for the macOS WARP client is now available on the beta releases downloads page.

    This release contains minor fixes and improvements.

    Changes and improvements

    • Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
    • Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.