Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Workers
hero image

  1. Build durable multi-step applications in Python with Workflows (now in beta)

    Workflows Workers

    You can now build Workflows using Python. With Python Workflows, you get automatic retries, state persistence, and the ability to run multi-step operations that can span minutes, hours, or weeks using Python’s familiar syntax and the Python Workers runtime.

    Python Workflows use the same step-based execution model as JavaScript Workflows, but with Python syntax and access to Python’s ecosystem. Python Workflows also enable DAG (Directed Acyclic Graph) workflows, where you can define complex dependencies between steps using the depends parameter.

    Here’s a simple example:

    Python
    from workers import Response, WorkflowEntrypoint
    

    class PythonWorkflowStarter(WorkflowEntrypoint):
        async def run(self, event, step):
            @step.do("my first step")
            async def my_first_step():
                # do some work
                return "Hello Python!"
    

            await my_first_step()
    

            await step.sleep("my-sleep-step", "10 seconds")
    

            @step.do("my second step")
            async def my_second_step():
                # do some more work
                return "Hello again!"
    

            await my_second_step()
    

    class Default(WorkerEntrypoint):
        async def fetch(self, request):
            await self.env.MY_WORKFLOW.create()
            return Response("Hello Workflow creation!")

    Python Workflows support the same core capabilities as JavaScript Workflows, including sleep scheduling, event-driven workflows, and built-in error handling with configurable retry policies.

    To learn more and get started, refer to Python Workflows documentation.

  1. New getByName() API to access Durable Objects

    Durable Objects Workers

    You can now create a client (a Durable Object stub) to a Durable Object with the new getByName method, removing the need to convert Durable Object names to IDs and then create a stub.

    JavaScript
    // Before: (1) translate name to ID then (2) get a client
    const objectId = env.MY_DURABLE_OBJECT.idFromName("foo"); // or .newUniqueId()
    const stub = env.MY_DURABLE_OBJECT.get(objectId);
    

    // Now: retrieve client to Durable Object directly via its name
    const stub = env.MY_DURABLE_OBJECT.getByName("foo");
    

    // Use client to send request to the remote Durable Object
    const rpcResponse = await stub.sayHello();

    Each Durable Object has a globally-unique name, which allows you to send requests to a specific object from anywhere in the world. Thus, a Durable Object can be used to coordinate between multiple clients who need to work together. You can have billions of Durable Objects, providing isolation between application tenants.

    To learn more, visit the Durable Objects API Documentation or the getting started guide.

  1. Easier debugging in Workers with improved Wrangler error screen

    Workers

    Wrangler's error screen has received several improvements to enhance your debugging experience!

    The error screen now features a refreshed design thanks to youch ↗, with support for both light and dark themes, improved source map resolution logic that handles missing source files more reliably, and better error cause display.

    BeforeAfter (Light)After (Dark)
    Old error screenNew light theme error screenNew dark theme error screen

    Try it out now with npx wrangler@latest dev in your Workers project.

  1. The Node.js and Web File System APIs in Workers

    Workers

    Implementations of the node:fs module ↗ and the Web File System API ↗ are now available in Workers.

    Using the node:fs module

    The node:fs module provides access to a virtual file system in Workers. You can use it to read and write files, create directories, and perform other file system operations.

    The virtual file system is ephemeral with each individual request havig its own isolated temporary file space. Files written to the file system will not persist across requests and will not be shared across requests or across different Workers.

    Workers running with the nodejs_compat compatibility flag will have access to the node:fs module by default when the compatibility date is set to 2025-09-01 or later. Support for the API can also be enabled using the enable_nodejs_fs_module compatibility flag together with the nodejs_compat flag. The node:fs module can be disabled using the disable_nodejs_fs_module compatibility flag.

    JavaScript
    import fs from "node:fs";
    

    const config = JSON.parse(fs.readFileSync("/bundle/config.json", "utf-8"));
    

    export default {
      async fetch(request) {
        return new Response(`Config value: ${config.value}`);
      },
    };

    There are a number of initial limitations to the node:fs implementation:

    • The glob APIs (e.g. fs.globSync(...)) are not implemented.
    • The file watching APIs (e.g. fs.watch(...)) are not implemented.
    • The file timestamps (modified time, access time, etc) are only partially supported. For now, these will always return the Unix epoch.

    Refer to the Node.js documentation ↗ for more information on the node:fs module and its APIs.

    The Web File System API

    The Web File System API provides access to the same virtual file system as the node:fs module, but with a different API surface. The Web File System API is only available in Workers running with the enable_web_file_system compatibility flag. The nodejs_compat compatibility flag is not required to use the Web File System API.

    JavaScript
    const root = navigator.storage.getDirectory();
    

    export default {
      async fetch(request) {
        const tmp = await root.getDirectoryHandle("/tmp");
        const file = await tmp.getFileHandle("data.txt", { create: true });
        const writable = await file.createWritable();
        const writer = writable.getWriter();
        await writer.write("Hello, World!");
        await writer.close();
    

        return new Response("File written successfully!");
      },
    };

    As there are still some parts of the Web File System API that are not fully standardized, there may be some differences between the Workers implementation and the implementations in browsers.

  1. Workers Static Assets: Corrected handling of double slashes in redirect rule paths

    Workers

    Static Assets: Fixed a bug in how redirect rules ↗ defined in your Worker's _redirects file are processed.

    If you're serving Static Assets with a _redirects file containing a rule like /ja/* /:splat, paths with double slashes were previously misinterpreted as external URLs. For example, visiting /ja//example.com would incorrectly redirect to https://example.com instead of /example.com on your domain. This has been fixed and double slashes now correctly resolve as local paths. Note: Cloudflare Pages was not affected by this issue.

  1. Workers per-branch preview URLs now support long branch names

    Workers

    We've updated preview URLs for Cloudflare Workers to support long branch names.

    Previously, branch and Worker names exceeding the 63-character DNS limit would cause alias generation to fail, leaving pull requests without aliased preview URLs. This particularly impacted teams relying on descriptive branch naming.

    Now, Cloudflare automatically truncates long branch names and appends a unique hash, ensuring every pull request gets a working preview link.

    How it works

    • 63 characters or less: <branch-name>-<worker-name> → Uses actual branch name as is
    • 64 characters or more: <truncated-branch-name>--<hash>-<worker-name> → Uses truncated name with 4-character hash
    • Hash generation: The hash is derived from the full branch name to ensure uniqueness
    • Stable URLs: The same branch always generates the same hash across all commits

    Requirements and compatibility

    • Wrangler 4.30.0 or later: This feature requires updating to wrangler@4.30.0+
    • No configuration needed: Works automatically with existing preview URL setups

  1. Python Workers handlers now live in an entrypoint class

    Workers

    We are changing how Python Workers are structured by default. Previously, handlers were defined at the top-level of a module as on_fetch, on_scheduled, etc. methods, but now they live in an entrypoint class.

    Here's an example of how to now define a Worker with a fetch handler:

    Python
    from workers import Response, WorkerEntrypoint
    

    class Default(WorkerEntrypoint):
        async def fetch(self, request):
            return Response("Hello World!")

    To keep using the old-style handlers, you can specify the disable_python_no_global_handlers compatibility flag in your wrangler file:

    JSONC
    {
      "compatibility_flags": [
        "disable_python_no_global_handlers"
      ]
    }

    Consult the Python Workers documentation for more details.

  1. Terraform provider improvements — Python Workers support, smaller plan diffs, and API SDK fixes

    Workers

    The recent Cloudflare Terraform Provider ↗ and SDK releases (such as cloudflare-typescript ↗) bring significant improvements to the Workers developer experience. These updates focus on reliability, performance, and adding Python Workers support.

    Terraform Improvements

    Fixed Unwarranted Plan Diffs

    Resolved several issues with the cloudflare_workers_script resource that resulted in unwarranted plan diffs, including:

    • Using Durable Objects migrations
    • Using some bindings such as secret_text
    • Using smart placement

    A resource should never show a plan diff if there isn't an actual change. This fix reduces unnecessary noise in your Terraform plan and is available in Cloudflare Terraform Provider 5.8.0.

    Improved File Management

    You can now specify content_file and content_sha256 instead of content. This prevents the Workers script content from being stored in the state file which greatly reduces plan diff size and noise. If your workflow synced plans remotely, this should now happen much faster since there is less data to sync. This is available in Cloudflare Terraform Provider 5.7.0.

    resource "cloudflare_workers_script" "my_worker" {
      account_id      = "123456789"
      script_name     = "my_worker"
      main_module     = "worker.mjs"
      content_file    = "worker.mjs"
      content_sha256  = filesha256("worker.mjs")
    }

    Assets Headers and Redirects Support

    Fixed the cloudflare_workers_script resource to properly support headers and redirects for Assets:

    resource "cloudflare_workers_script" "my_worker" {
      account_id      = "123456789"
      script_name     = "my_worker"
      main_module     = "worker.mjs"
      content_file    = "worker.mjs"
      content_sha256  = filesha256("worker.mjs")
      assets = {
        config = {
          headers = file("_headers")
          redirects = file("_redirects")
        }
        # Completion jwt from:
        # https://developers.cloudflare.com/api/resources/workers/subresources/assets/subresources/upload/
        jwt = "jwt"
      }
    }

    Available in Cloudflare Terraform Provider 5.8.0.

    Python Workers Support

    Added support for uploading Python Workers (beta) in Terraform. You can now deploy Python Workers with:

    resource "cloudflare_workers_script" "my_worker" {
      account_id       = "123456789"
      script_name      = "my_worker"
      content_file     = "worker.py"
      content_sha256   = filesha256("worker.py")
      content_type     = "text/x-python"
    }

    Available in Cloudflare Terraform Provider 5.8.0.

    SDK Enhancements

    Improved File Upload API

    Fixed an issue where Workers script versions in the SDK did not allow uploading files. This now works, and also has an improved files upload interface:

    JavaScript
    const scriptContent = `
      export default {
        async fetch(request, env, ctx) {
          return new Response('Hello World!', { status: 200 });
        }
      };
    `;
    

    client.workers.scripts.versions.create('my-worker', {
      account_id: '123456789',
      metadata: {
        main_module: 'my-worker.mjs',
      },
      files: [
        await toFile(
          Buffer.from(scriptContent),
          'my-worker.mjs',
          {
            type: "application/javascript+module",
          }
        )
      ]
    });

    Will be available in cloudflare-typescript 4.6.0. A similar change will be available in cloudflare-python 4.4.0.

    Fixed updating KV values

    Previously when creating a KV value like this:

    JavaScript
    await cf.kv.namespaces.values.update("my-kv-namespace", "key1", {
      account_id: "123456789",
      metadata: "my metadata",
      value: JSON.stringify({
        hello: "world"
      })
    });

    ...and recalling it in your Worker like this:

    TypeScript
    const value = await c.env.KV.get<{hello: string}>("key1", "json");

    You'd get back this: {metadata:'my metadata', value:"{'hello':'world'}"} instead of the correct value of {hello: 'world'}

    This is fixed in cloudflare-typescript 4.5.0 and will be fixed in cloudflare-python 4.4.0.

  1. MessageChannel and MessagePort

    Workers

    A minimal implementation of the MessageChannel API ↗ is now available in Workers. This means that you can use MessageChannel to send messages between different parts of your Worker, but not across different Workers.

    The MessageChannel and MessagePort APIs will be available by default at the global scope with any worker using a compatibility date of 2025-08-15 or later. It is also available using the expose_global_message_channel compatibility flag, or can be explicitly disabled using the no_expose_global_message_channel compatibility flag.

    JavaScript
    const { port1, port2 } = new MessageChannel();
    

    port2.onmessage = (event) => {
      console.log('Received message:', event.data);
    };
    

    port2.postMessage('Hello from port2!');

    Any value that can be used with the structuredClone(...) API can be sent over the port.

    Differences

    There are a number of key limitations to the MessageChannel API in Workers:

    • Transfer lists are currently not supported. This means that you will not be able to transfer ownership of objects like ArrayBuffer or MessagePort between ports.
    • The MessagePort is not yet serializable. This means that you cannot send a MessagePort object through the postMessage method or via JSRPC calls.
    • The 'messageerror' event is only partially supported. If the 'onmessage' handler throws an error, the 'messageerror' event will be triggered, however, it will not be triggered when there are errors serializing or deserializing the message data. Instead, the error will be thrown when the postMessage method is called on the sending port.
    • The 'close' event will be emitted on both ports when one of the ports is closed, however it will not be emitted when the Worker is terminated or when one of the ports is garbage collected.

  1. Wrangler and the Cloudflare Vite plugin support `.env` files in local development

    Workers

    Now, you can use .env files to provide secrets and override environment variables on the env object during local development with Wrangler and the Cloudflare Vite plugin.

    Previously in local development, if you wanted to provide secrets or environment variables during local development, you had to use .dev.vars files. This is still supported, but you can now also use .env files, which are more familiar to many developers.

    Using .env files in local development

    You can create a .env file in your project root to define environment variables that will be used when running wrangler dev or vite dev. The .env file should be formatted like a dotenv file, such as KEY="VALUE":

    .env
    TITLE="My Worker"
    API_TOKEN="dev-token"

    When you run wrangler dev or vite dev, the environment variables defined in the .env file will be available in your Worker code via the env object:

    JavaScript
    export default {
      async fetch(request, env) {
        const title = env.TITLE; // "My Worker"
        const apiToken = env.API_TOKEN; // "dev-token"
        const response = await fetch(
          `https://api.example.com/data?token=${apiToken}`,
        );
        return new Response(`Title: ${title} - ` + (await response.text()));
      },
    };

    Multiple environments with .env files

    If your Worker defines multiple environments, you can set different variables for each environment (ex: production or staging) by creating files named .env.<environment-name>.

    When you use wrangler <command> --env <environment-name> or CLOUDFLARE_ENV=<environment-name> vite dev, the corresponding environment-specific file will also be loaded and merged with the .env file.

    For example, if you want to set different environment variables for the staging environment, you can create a file named .env.staging:

    .env.staging
    API_TOKEN="staging-token"

    When you run wrangler dev --env staging or CLOUDFLARE_ENV=staging vite dev, the environment variables from .env.staging will be merged onto those from .env.

    JavaScript
    export default {
      async fetch(request, env) {
        const title = env.TITLE; // "My Worker" (from `.env`)
        const apiToken = env.API_TOKEN; // "staging-token" (from `.env.staging`, overriding the value from `.env`)
        const response = await fetch(
          `https://api.example.com/data?token=${apiToken}`,
        );
        return new Response(`Title: ${title} - ` + (await response.text()));
      },
    };

    Find out more

    For more information on how to use .env files with Wrangler and the Cloudflare Vite plugin, see the following documentation:

  1. Directly import `waitUntil` in Workers for easily spawning background tasks

    Workers

    You can now import waitUntil from cloudflare:workers to extend your Worker's execution beyond the request lifecycle from anywhere in your code.

    Previously, waitUntil could only be accessed through the execution context (ctx) parameter passed to your Worker's handler functions. This meant that if you needed to schedule background tasks from deeply nested functions or utility modules, you had to pass the ctx object through multiple function calls to access waitUntil.

    Now, you can import waitUntil directly and use it anywhere in your Worker without needing to pass ctx as a parameter:

    JavaScript
    import { waitUntil } from "cloudflare:workers";
    

    export function trackAnalytics(eventData) {
      const analyticsPromise = fetch("https://analytics.example.com/track", {
        method: "POST",
        body: JSON.stringify(eventData),
      });
    

      // Extend execution to ensure analytics tracking completes
      waitUntil(analyticsPromise);
    }

    This is particularly useful when you want to:

    • Schedule background tasks from utility functions or modules
    • Extend execution for analytics, logging, or cleanup operations
    • Avoid passing the execution context through multiple layers of function calls
    JavaScript
    import { waitUntil } from "cloudflare:workers";
    

    export default {
      async fetch(request, env, ctx) {
        // Background task that should complete even after response is sent
        cleanupTempData(env.KV_NAMESPACE);
        return new Response("Hello, World!");
      }
    };
    

    function cleanupTempData(kvNamespace) {
      // This function can now use waitUntil without needing ctx
      const deletePromise = kvNamespace.delete("temp-key");
      waitUntil(deletePromise);
    }

    For more information, see the waitUntil documentation.

  1. Requests made from Cloudflare Workers can now force a revalidation of their cache with the origin

    Workers

    By setting the value of the cache property to no-cache, you can force Cloudflare's cache to revalidate its contents with the origin when making subrequests from Cloudflare Workers.

    index.js
    export default {
      async fetch(req, env, ctx) {
        const request = new Request("https://cloudflare.com", {
          cache: "no-cache",
        });
        const response = await fetch(request);
        return response;
      },
    };

    When no-cache is set, the Worker request will first look for a match in Cloudflare's cache, then:

    • If there is a match, a conditional request is sent to the origin, regardless of whether or not the match is fresh or stale. If the resource has not changed, the cached version is returned. If the resource has changed, it will be downloaded from the origin, updated in the cache, and returned.
    • If there is no match, Workers will make a standard request to the origin and cache the response.

    This increases compatibility with NPM packages and JavaScript frameworks that rely on setting the cache property, which is a cross-platform standard part of the Request interface. Previously, if you set the cache property on Request to 'no-cache', the Workers runtime threw an exception.

  1. Agents SDK adds MCP Elicitation support, http-streamable support, task queues, email integration and more

    Agents Workers

    The latest releases of @cloudflare/agents ↗ brings major improvements to MCP transport protocols support and agents connectivity. Key updates include:

    MCP elicitation support

    MCP servers can now request user input during tool execution, enabling interactive workflows like confirmations, forms, and multi-step processes. This feature uses durable storage to preserve elicitation state even during agent hibernation, ensuring seamless user interactions across agent lifecycle events.

    TypeScript
    // Request user confirmation via elicitation
    const confirmation = await this.elicitInput({
      message: `Are you sure you want to increment the counter by ${amount}?`,
      requestedSchema: {
        type: "object",
        properties: {
          confirmed: {
            type: "boolean",
            title: "Confirm increment",
            description: "Check to confirm the increment",
          },
        },
        required: ["confirmed"],
      },
    });

    Check out our demo ↗ to see elicitation in action.

    HTTP streamable transport for MCP

    MCP now supports HTTP streamable transport which is recommended over SSE. This transport type offers:

    • Better performance: More efficient data streaming and reduced overhead
    • Improved reliability: Enhanced connection stability and error recover- Automatic fallback: If streamable transport is not available, it gracefully falls back to SSE
    TypeScript
    export default MyMCP.serve("/mcp", {
      binding: "MyMCP",
    });

    The SDK automatically selects the best available transport method, gracefully falling back from streamable-http to SSE when needed.

    Enhanced MCP connectivity

    Significant improvements to MCP server connections and transport reliability:

    • Auto transport selection: Automatically determines the best transport method, falling back from streamable-http to SSE as needed
    • Improved error handling: Better connection state management and error reporting for MCP servers
    • Reliable prop updates: Centralized agent property updates ensure consistency across different contexts

    Lightweight .queue for fast task deferral

    You can use .queue() to enqueue background work — ideal for tasks like processing user messages, sending notifications etc.

    TypeScript
    class MyAgent extends Agent {
      doSomethingExpensive(payload) {
        // a long running process that you want to run in the background
      }
    

      queueSomething() {
        await this.queue("doSomethingExpensive", somePayload); // this will NOT block further execution, and runs in the background
        await this.queue("doSomethingExpensive", someOtherPayload); // the callback will NOT run until the previous callback is complete
        // ... call as many times as you want
      }
    }

    Want to try it yourself? Just define a method like processMessage in your agent, and you’re ready to scale.

    New email adapter

    Want to build an AI agent that can receive and respond to emails automatically? With the new email adapter and onEmail lifecycle method, now you can.

    TypeScript
    export class EmailAgent extends Agent {
      async onEmail(email: AgentEmail) {
        const raw = await email.getRaw();
        const parsed = await PostalMime.parse(raw);
    

        // create a response based on the email contents
        // and then send a reply
    

        await this.replyToEmail(email, {
          fromName: "Email Agent",
          body: `Thanks for your email! You've sent us "${parsed.subject}". We'll process it shortly.`,
        });
      }
    }

    You route incoming mail like this:

    TypeScript
    export default {
      async email(email, env) {
        await routeAgentEmail(email, env, {
          resolver: createAddressBasedEmailResolver("EmailAgent"),
        });
      },
    };

    You can find a full example here ↗.

    Automatic context wrapping for custom methods

    Custom methods are now automatically wrapped with the agent's context, so calling getCurrentAgent() should work regardless of where in an agent's lifecycle it's called. Previously this would not work on RPC calls, but now just works out of the box.

    TypeScript
    export class MyAgent extends Agent {
      async suggestReply(message) {
        // getCurrentAgent() now correctly works, even when called inside an RPC method
        const { agent } = getCurrentAgent()!;
        return generateText({
          prompt: `Suggest a reply to: "${message}" from "${agent.name}"`,
          tools: [replyWithEmoji],
        });
      }
    }

    Try it out and tell us what you build!

  1. Cloudflare Sandbox SDK adds streaming, code interpreter, Git support, process control and more

    Agents Workers

    We’ve shipped a major release for the @cloudflare/sandbox ↗ SDK, turning it into a full-featured, container-based execution platform that runs securely on Cloudflare Workers.

    This update adds live streaming of output, persistent Python and JavaScript code interpreters with rich output support (charts, tables, HTML, JSON), file system access, Git operations, full background process control, and the ability to expose running services via public URLs.

    This makes it ideal for building AI agents, CI runners, cloud REPLs, data analysis pipelines, or full developer tools — all without managing infrastructure.

    Code interpreter (Python, JS, TS)

    Create persistent code contexts with support for rich visual + structured outputs.

    createCodeContext(options)

    Creates a new code execution context with persistent state.

    TypeScript
    // Create a Python context
    const pythonCtx = await sandbox.createCodeContext({ language: "python" });
    

    // Create a JavaScript context
    const jsCtx = await sandbox.createCodeContext({ language: "javascript" });

    Options:

    • language: Programming language ('python' | 'javascript' | 'typescript')
    • cwd: Working directory (default: /workspace)
    • envVars: Environment variables for the context

    runCode(code, options)

    Executes code with optional streaming callbacks.

    TypeScript
    // Simple execution
    const execution = await sandbox.runCode('print("Hello World")', {
      context: pythonCtx,
    });
    

    // With streaming callbacks
    await sandbox.runCode(
      `
    for i in range(5):
        print(f"Step {i}")
        time.sleep(1)
    `,
      {
        context: pythonCtx,
        onStdout: (output) => console.log("Real-time:", output.text),
        onResult: (result) => console.log("Result:", result),
      },
    );

    Options:

    • language: Programming language ('python' | 'javascript' | 'typescript')
    • cwd: Working directory (default: /workspace)
    • envVars: Environment variables for the context

    Real-time streaming output

    Returns a streaming response for real-time processing.

    TypeScript
    const stream = await sandbox.runCodeStream(
      "import time; [print(i) for i in range(10)]",
    );
    // Process the stream as needed

    Rich output handling

    Interpreter outputs are auto-formatted and returned in multiple formats:

    • text
    • html (e.g., Pandas tables)
    • png, svg (e.g., Matplotlib charts)
    • json (structured data)
    • chart (parsed visualizations)
    TypeScript
    const result = await sandbox.runCode(
      `
    import seaborn as sns
    import matplotlib.pyplot as plt
    

    data = sns.load_dataset("flights")
    pivot = data.pivot("month", "year", "passengers")
    sns.heatmap(pivot, annot=True, fmt="d")
    plt.title("Flight Passengers")
    plt.show()
    

    pivot.to_dict()
    `,
      { context: pythonCtx },
    );
    

    if (result.png) {
      console.log("Chart output:", result.png);
    }

    Preview URLs from Exposed Ports

    Start background processes and expose them with live URLs.

    TypeScript
    await sandbox.startProcess("python -m http.server 8000");
    const preview = await sandbox.exposePort(8000);
    

    console.log("Live preview at:", preview.url);

    Full process lifecycle control

    Start, inspect, and terminate long-running background processes.

    TypeScript
    const process = await sandbox.startProcess("node server.js");
    console.log(`Started process ${process.id} with PID ${process.pid}`);
    

    // Monitor the process
    const logStream = await sandbox.streamProcessLogs(process.id);
    for await (const log of parseSSEStream<LogEvent>(logStream)) {
      console.log(`Server: ${log.data}`);
    }
    • listProcesses() - List all running processes
    • getProcess(id) - Get detailed process status
    • killProcess(id, signal) - Terminate specific processes
    • killAllProcesses() - Kill all processes
    • streamProcessLogs(id, options) - Stream logs from running processes
    • getProcessLogs(id) - Get accumulated process output

    Git integration

    Clone Git repositories directly into the sandbox.

    TypeScript
    await sandbox.gitCheckout("https://github.com/user/repo", {
      branch: "main",
      targetDir: "my-project",
    });

    Sandboxes are still experimental. We're using them to explore how isolated, container-like workloads might scale on Cloudflare — and to help define the developer experience around them.

  1. Increased disk space for Workers Builds

    Workers

    As part of the ongoing open beta for Workers Builds, we’ve increased the available disk space for builds from 8 GB to 20 GB for both Free and Paid plans.

    This provides more space for larger projects, dependencies, and build artifacts while improving overall build reliability.

    MetricFree PlanPaid Plans
    Disk Space20 GB20 GB

    All other build limits — including CPU, memory, build minutes, and timeout remain unchanged.

  1. Develop locally with Containers and the Cloudflare Vite plugin

    Workers

    You can now configure and run Containers alongside your Worker during local development when using the Cloudflare Vite plugin. Previously, you could only develop locally when using Wrangler as your local development server.

    Configuration

    You can simply configure your Worker and your Container(s) in your Wrangler configuration file:

    JSONC
    {
      "name": "container-starter",
      "main": "src/index.js",
      "containers": [
        {
          "class_name": "MyContainer",
          "image": "./Dockerfile",
          "instances": 5
        }
      ],
      "durable_objects": {
        "bindings": [
          {
            "class_name": "MyContainer",
            "name": "MY_CONTAINER"
          }
        ]
      },
      "migrations": [
        {
          "new_sqlite_classes": [
            "MyContainer"
          ],
          "tag": "v1"
        }
      ],
    }

    Worker Code

    Once your Worker and Containers are configured, you can access the Container instances from your Worker code:

    TypeScript
    import { Container, getContainer } from "@cloudflare/containers";
    

    export class MyContainer extends Container {
      defaultPort = 4000; // Port the container is listening on
      sleepAfter = "10m"; // Stop the instance if requests not sent for 10 minutes
    }
    

    async fetch(request, env) {
      const { "session-id": sessionId } = await request.json();
      // Get the container instance for the given session ID
      const containerInstance = getContainer(env.MY_CONTAINER, sessionId)
      // Pass the request to the container instance on its default port
      return containerInstance.fetch(request);
    }

    Local development

    To develop your Worker locally, start a local dev server by running

    Terminal window
    vite dev

    in your terminal.

    Resources

    Learn more about Cloudflare Containers ↗ or the Cloudflare Vite plugin ↗ in our developer docs.

  1. Deploy to Cloudflare buttons now support Worker environment variables, secrets, and Secrets Store secrets

    Workers Secrets Store

    Any template which uses Worker environment variables, secrets, or Secrets Store secrets can now be deployed using a Deploy to Cloudflare button.

    Define environment variables and secrets store bindings in your Wrangler configuration file as normal:

    JSONC
    {
      "name": "my-worker",
      "main": "./src/index.ts",
      // Set this to today's date
      "compatibility_date": "2026-05-21",
      "vars": {
        "API_HOST": "https://example.com",
      },
      "secrets_store_secrets": [
        {
          "binding": "API_KEY",
          "store_id": "demo",
          "secret_name": "api-key"
        }
      ]
    }

    Add secrets to a .dev.vars.example or .env.example file:

    .dev.vars.example
    COOKIE_SIGNING_KEY=my-secret # comment

    And optionally, you can add a description for these bindings in your template's package.json to help users understand how to configure each value:

    package.json
    {
      "name": "my-worker",
      "private": true,
      "cloudflare": {
        "bindings": {
          "API_KEY": {
            "description": "Select your company's API key for connecting to the example service."
          },
          "COOKIE_SIGNING_KEY": {
            "description": "Generate a random string using `openssl rand -hex 32`."
          }
        }
      }
    }

    These secrets and environment variables will be presented to users in the dashboard as they deploy this template, allowing them to configure each value. Additional information about creating templates and Deploy to Cloudflare buttons can be found in our documentation.

  1. Test out code changes before shipping with per-branch preview deployments for Cloudflare Workers

    Workers

    Now, when you connect your Cloudflare Worker to a git repository on GitHub or GitLab, each branch of your repository has its own stable preview URL, that you can use to preview code changes before merging the pull request and deploying to production.

    This works the same way that Cloudflare Pages does — every time you create a pull request, you'll automatically get a shareable preview link where you can see your changes running, without affecting production. The link stays the same, even as you add commits to the same branch. These preview URLs are named after your branch and are posted as a comment to each pull request. The URL stays the same with every commit and always points to the latest version of that branch.

    PR comment preview

    Preview URL types

    Each comment includes two preview URLs as shown above:

    • Commit Preview URL: Unique to the specific version/commit (e.g., <version-prefix>-<worker-name>.<subdomain>.workers.dev)
    • Branch Preview URL: A stable alias based on the branch name (e.g., <branch-name>-<worker-name>.<subdomain>.workers.dev)

    How it works

    When you create a pull request:

    • A preview alias is automatically created based on the Git branch name (e.g., <branch-name> becomes <branch-name>-<worker-name>.<subdomain>.workers.dev)
    • No configuration is needed, the alias is generated for you
    • The link stays the same even as you add commits to the same branch
    • Preview URLs are posted directly to your pull request as comments (just like they are in Cloudflare Pages)

    Custom alias name

    You can also assign a custom preview alias using the Wrangler CLI, by passing the --preview-alias flag when uploading a version of your Worker:

    Terminal window
    wrangler versions upload --preview-alias staging

    Limitations while in beta

    • Only available on the workers.dev subdomain (custom domains not yet supported)
    • Requires Wrangler v4.21.0+
    • Preview URLs are not generated for Workers that use Durable Objects
    • Not yet supported for Workers for Platforms

  1. The Cloudflare Vite plugin now supports Vite 7

    Workers

    Vite 7 ↗ is now supported in the Cloudflare Vite plugin. See the Vite changelog ↗ for a list of changes.

    Note that the minimum Node.js versions supported by Vite 7 are 20.19 and 22.12. We continue to support Vite 6 so you do not need to immediately upgrade.

  1. Workers now supports JavaScript debug terminals in VSCode, Cursor and Windsurf IDEs

    Workers

    Workers now support breakpoint debugging using VSCode's built-in JavaScript Debug Terminals ↗. All you have to do is open a JS debug terminal (Cmd + Shift + P and then type javascript debug) and run wrangler dev (or vite dev) from within the debug terminal. VSCode will automatically connect to your running Worker (even if you're running multiple Workers at once!) and start a debugging session.

    In 2023 we announced breakpoint debugging support ↗ for Workers, which meant that you could easily debug your Worker code in Wrangler's built-in devtools (accessible via the [d] hotkey) as well as multiple other devtools clients, including VSCode ↗. For most developers, breakpoint debugging via VSCode is the most natural flow, but until now it's required manually configuring a launch.json file ↗, running wrangler dev, and connecting via VSCode's built-in debugger. Now it's much more seamless!

  1. Enhanced support for static assets with the Cloudflare Vite plugin

    Workers

    You can now use any of Vite's static asset handling ↗ features in your Worker as well as in your frontend. These include importing assets as URLs, importing as strings and importing from the public directory as well as inlining assets.

    Additionally, assets imported as URLs in your Worker are now automatically moved to the client build output.

    Here is an example that fetches an imported asset using the assets binding and modifies the response.

    TypeScript
    // Import the asset URL
    // This returns the resolved path in development and production
    import myImage from "./my-image.png";
    

    export default {
      async fetch(request, env) {
        // Fetch the asset using the binding
        const response = await env.ASSETS.fetch(new URL(myImage, request.url));
        // Create a new `Response` object that can be modified
        const modifiedResponse = new Response(response.body, response);
        // Add an additional header
        modifiedResponse.headers.append("my-header", "imported-asset");
    

        // Return the modified response
        return modifiedResponse;
      },
    };

    Refer to Static Assets in the Cloudflare Vite plugin docs for more info.

  1. Remote bindings (beta) now works with Next.js — connect to remote resources (D1, KV, R2, etc.) during local development

    Workers

    We recently announced ↗ our public beta for remote bindings, which allow you to connect to deployed resources running on your Cloudflare account (like R2 buckets or D1 databases) while running a local development session.

    Now, you can use remote bindings with your Next.js applications through the @opennextjs/cloudflare adaptor ↗ by enabling the experimental feature in your next.config.ts:

    initOpenNextCloudflareForDev();
    initOpenNextCloudflareForDev({
     experimental: { remoteBindings: true }
    });

    Then, all you have to do is specify which bindings you want connected to the deployed resource on your Cloudflare account via the experimental_remote flag in your binding definition:

    JSONC
    {
      "r2_buckets": [
        {
          "bucket_name": "testing-bucket",
          "binding": "MY_BUCKET",
          "experimental_remote": true,
        },
      ],
    }

    You can then run next dev to start a local development session (or start a preview with opennextjs-cloudflare preview), and all requests to env.MY_BUCKET will be proxied to the remote testing-bucket — rather than the default local binding simulations.

    Remote bindings & ISR

    Remote bindings are also used during the build process, which comes with significant benefits for pages using Incremental Static Regeneration (ISR) ↗. During the build step for an ISR page, your server executes the page's code just as it would for normal user requests. If a page needs data to display (like fetching user info from KV), those requests are actually made. The server then uses this fetched data to render the final HTML.

    Data fetching is a critical part of this process, as the finished HTML is only as good as the data it was built with. If the build process can't fetch real data, you end up with a pre-rendered page that's empty or incomplete.

    With remote bindings support in OpenNext, your pre-rendered pages are built with real data from the start. The build process uses any configured remote bindings, and any data fetching occurs against the deployed resources on your Cloudflare account.

    Want to learn more? Get started with remote bindings and OpenNext ↗.

    Have feedback? Join the discussion in our beta announcement ↗ to share feedback or report any issues.

  1. Run and connect Workers in separate dev commands with the Cloudflare Vite plugin

    Workers

    Workers can now talk to each other across separate dev commands using service bindings and tail consumers, whether started with vite dev or wrangler dev.

    Simply start each Worker in its own terminal:

    Terminal window
    # Terminal 1
    vite dev
    

    # Terminal 2
    wrangler dev

    This is useful when different teams maintain different Workers, or when each Worker has its own build setup or tooling.

    Check out the Developing with multiple Workers guide to learn more about the different approaches and when to use each one.

  1. Run AI-generated code on-demand with Code Sandboxes (new)

    Agents Workers Workflows

    AI is supercharging app development for everyone, but we need a safe way to run untrusted, LLM-written code. We’re introducing Sandboxes ↗, which let your Worker run actual processes in a secure, container-based environment.

    TypeScript
    import { getSandbox } from "@cloudflare/sandbox";
    export { Sandbox } from "@cloudflare/sandbox";
    

    export default {
      async fetch(request: Request, env: Env) {
        const sandbox = getSandbox(env.Sandbox, "my-sandbox");
        return sandbox.exec("ls", ["-la"]);
      },
    };

    Methods

    • exec(command: string, args: string[], options?: { stream?: boolean }):Execute a command in the sandbox.
    • gitCheckout(repoUrl: string, options: { branch?: string; targetDir?: string; stream?: boolean }): Checkout a git repository in the sandbox.
    • mkdir(path: string, options: { recursive?: boolean; stream?: boolean }): Create a directory in the sandbox.
    • writeFile(path: string, content: string, options: { encoding?: string; stream?: boolean }): Write content to a file in the sandbox.
    • readFile(path: string, options: { encoding?: string; stream?: boolean }): Read content from a file in the sandbox.
    • deleteFile(path: string, options?: { stream?: boolean }): Delete a file from the sandbox.
    • renameFile(oldPath: string, newPath: string, options?: { stream?: boolean }): Rename a file in the sandbox.
    • moveFile(sourcePath: string, destinationPath: string, options?: { stream?: boolean }): Move a file from one location to another in the sandbox.
    • ping(): Ping the sandbox.

    Sandboxes are still experimental. We're using them to explore how isolated, container-like workloads might scale on Cloudflare — and to help define the developer experience around them.

    You can try it today from your Worker, with just a few lines of code. Let us know what you build.

  1. @cloudflare/actors library - SDK for Durable Objects in beta

    Durable Objects Workers

    The new @cloudflare/actors ↗ library is now in beta!

    The @cloudflare/actors library is a new SDK for Durable Objects and provides a powerful set of abstractions for building real-time, interactive, and multiplayer applications on top of Durable Objects. With beta usage and feedback, @cloudflare/actors will become the recommended way to build on Durable Objects and draws upon Cloudflare's experience building products/features on Durable Objects.

    The name "actors" originates from the actor programming model, which closely ties to how Durable Objects are modelled.

    The @cloudflare/actors library includes:

    • Storage helpers for querying embeddeded, per-object SQLite storage
    • Storage helpers for managing SQL schema migrations
    • Alarm helpers for scheduling multiple alarms provided a date, delay in seconds, or cron expression
    • Actor class for using Durable Objects with a defined pattern
    • Durable Objects Workers API ↗ is always available for your application as needed

    Storage and alarm helper methods can be combined with any Javascript class ↗ that defines your Durable Object, i.e, ones that extend DurableObject including the Actor class.

    JavaScript
    import { Storage } from "@cloudflare/actors/storage";
    

    export class ChatRoom extends DurableObject<Env> {
        storage: Storage;
    

        constructor(ctx: DurableObjectState, env: Env) {
            super(ctx, env)
            this.storage = new Storage(ctx.storage);
            this.storage.migrations = [{
                idMonotonicInc: 1,
                description: "Create users table",
                sql: "CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY)"
            }]
        }
        async fetch(request: Request): Promise<Response> {
            // Run migrations before executing SQL query
            await this.storage.runMigrations();
    

            // Query with SQL template
            let userId = new URL(request.url).searchParams.get("userId");
            const query = this.storage.sql`SELECT * FROM users WHERE id = ${userId};`
            return new Response(`${JSON.stringify(query)}`);
        }
    }

    @cloudflare/actors library introduces the Actor class pattern. Actor lets you access Durable Objects without writing the Worker that communicates with your Durable Object (the Worker is created for you). By default, requests are routed to a Durable Object named "default".

    JavaScript
    export class MyActor extends Actor<Env> {
        async fetch(request: Request): Promise<Response> {
            return new Response('Hello, World!')
        }
    }
    

    export default handler(MyActor);

    You can route to different Durable Objects by name within your Actor class using nameFromRequest ↗.

    JavaScript
    export class MyActor extends Actor<Env> {
        static nameFromRequest(request: Request): string {
            let url = new URL(request.url);
            return url.searchParams.get("userId") ?? "foo";
        }
    

        async fetch(request: Request): Promise<Response> {
            return new Response(`Actor identifier (Durable Object name): ${this.identifier}`);
        }
    }
    

    export default handler(MyActor);

    For more examples, check out the library README ↗. @cloudflare/actors library is a place for more helpers and built-in patterns, like retry handling and Websocket-based applications, to reduce development overhead for common Durable Objects functionality. Please share feedback and what more you would like to see on our Discord channel ↗.