Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Workers
hero image

  1. Set breakpoints and debug your Workers tests with @cloudflare/vitest-pool-workers

    Workers

    You can now debug your Workers tests with our Vitest integration by running the following command:

    Terminal window
    vitest --inspect --no-file-parallelism

    Attach a debugger to the port 9229 and you can start stepping through your Workers tests. This is available with @cloudflare/vitest-pool-workers v0.7.5 or later.

    Learn more in our documentation.

  1. Access your Worker's environment variables from process.env

    Workers

    You can now access environment variables and secrets on process.env when using the nodejs_compat compatibility flag.

    JavaScript
    const apiClient = ApiClient.new({ apiKey: process.env.API_KEY });
    const LOG_LEVEL = process.env.LOG_LEVEL || "info";

    In Node.js, environment variables are exposed via the global process.env object. Some libraries assume that this object will be populated, and many developers may be used to accessing variables in this way.

    Previously, the process.env object was always empty unless written to in Worker code. This could cause unexpected errors or friction when developing Workers using code previously written for Node.js.

    Now, environment variables, secrets, and version metadata can all be accessed on process.env.

    To opt-in to the new process.env behaviour now, add the nodejs_compat_populate_process_env compatibility flag to your wrangler.json configuration:

    JSONC
    {
      // Rest of your configuration
      // Add "nodejs_compat_populate_process_env" to your compatibility_flags array
      "compatibility_flags": ["nodejs_compat", "nodejs_compat_populate_process_env"],
      // Rest of your configuration

    After April 1, 2025, populating process.env will become the default behavior when both nodejs_compat is enabled and your Worker's compatibility_date is after "2025-04-01".

  1. Use the latest JavaScript features with Wrangler CLI v4.0.0-rc.0

    Workers

    We've released a release candidate of the next major version of Wrangler, the CLI for Cloudflare Workers — wrangler@4.0.0-rc.0.

    You can run the following command to install it and be one of the first to try it out:

    npm i wrangler@v4-rc

    Unlike previous major versions of Wrangler, which were foundational rewrites ↗ and rearchitectures ↗ — Version 4 of Wrangler includes a much smaller set of changes. If you use Wrangler today, your workflow is very unlikely to change. Before we release Wrangler v4 and advance past the release candidate stage, we'll share a detailed migration guide in the Workers developer docs. But for the vast majority of cases, you won't need to do anything to migrate — things will just work as they do today. We are sharing this release candidate in advance of the official release of v4, so that you can try it out early and share feedback.

    New JavaScript language features that you can now use with Wrangler v4

    Version 4 of Wrangler updates the version of esbuild ↗ that Wrangler uses internally, allowing you to use modern JavaScript language features, including:

    The using keyword from Explicit Resource Management

    The using keyword from the Explicit Resource Management standard makes it easier to work with the JavaScript-native RPC system built into Workers. This means that when you obtain a stub, you can ensure that it is automatically disposed when you exit scope it was created in:

    JavaScript
    function sendEmail(id, message) {
      using user = await env.USER_SERVICE.findUser(id);
      await user.sendEmail(message);
    

      // user[Symbol.dispose]() is implicitly called at the end of the scope.
    }
    Import attributes

    Import attributes ↗ allow you to denote the type or other attributes of the module that your code imports. For example, you can import a JSON module, using the following syntax:

    JavaScript
    import data from "./data.json" with { type: "json" };

    Other changes

    --local is now the default for all CLI commands

    All commands that access resources (for example, wrangler kv, wrangler r2, wrangler d1) now access local datastores by default, ensuring consistent behavior.

    Clearer policy for the minimum required version of Node.js required to run Wrangler

    Moving forward, the active, maintenance, and current versions of Node.js ↗ will be officially supported by Wrangler. This means the minimum officially supported version of Node.js you must have installed for Wrangler v4 will be Node.js v18 or later. This policy mirrors how many other packages and CLIs support older versions of Node.js, and ensures that as long as you are using a version of Node.js that the Node.js project itself supports, this will be supported by Wrangler as well.

    Features previously deprecated in Wrangler v3 are now removed in Wrangler v4

    All previously deprecated features in Wrangler v2 ↗ and in Wrangler v3 ↗ have now been removed. Additionally, the following features that were deprecated during the Wrangler v3 release have been removed:

    • Legacy Assets (using wrangler dev/deploy --legacy-assets or the legacy_assets config file property). Instead, we recommend you migrate to Workers assets ↗.
    • Legacy Node.js compatibility (using wrangler dev/deploy --node-compat or the node_compat config file property). Instead, use the nodejs_compat compatibility flag ↗. This includes the functionality from legacy node_compat polyfills and natively implemented Node.js APIs.
    • wrangler version. Instead, use wrangler --version to check the current version of Wrangler.
    • getBindingsProxy() (via import { getBindingsProxy } from "wrangler"). Instead, use the getPlatformProxy() API ↗, which takes exactly the same arguments.
    • usage_model. This no longer has any effect, after the rollout of Workers Standard Pricing ↗.

    We'd love your feedback! If you find a bug or hit a roadblock when upgrading to Wrangler v4, open an issue on the cloudflare/workers-sdk repository on GitHub ↗.

  1. Introducing the Agents SDK

    Agents Workers

    We've released the Agents SDK ↗, a package and set of tools that help you build and ship AI Agents.

    You can get up and running with a chat-based AI Agent ↗ (and deploy it to Workers) that uses the Agents SDK, tool calling, and state syncing with a React-based front-end by running the following command:

    Terminal window
    npm create cloudflare@latest agents-starter -- --template="cloudflare/agents-starter"
    # open up README.md and follow the instructions

    You can also add an Agent to any existing Workers application by installing the agents package directly

    Terminal window
    npm i agents

    ... and then define your first Agent:

    TypeScript
    import { Agent } from "agents";
    

    export class YourAgent extends Agent<Env> {
      // Build it out
      // Access state on this.state or query the Agent's database via this.sql
      // Handle WebSocket events with onConnect and onMessage
      // Run tasks on a schedule with this.schedule
      // Call AI models
      // ... and/or call other Agents.
    }

    Head over to the Agents documentation to learn more about the Agents SDK, the SDK APIs, as well as how to test and deploying agents to production.

  1. Autofix Worker name configuration errors at build time

    Workers
    Auto-fixing Workers Name in Git Repo

    Small misconfigurations shouldn’t break your deployments. Cloudflare is introducing automatic error detection and fixes in Workers Builds, identifying common issues in your wrangler.toml or wrangler.jsonc and proactively offering fixes, so you spend less time debugging and more time shipping.

    Here's how it works:

    1. Before running your build, Cloudflare checks your Worker's Wrangler configuration file (wrangler.toml or wrangler.jsonc) for common errors.
    2. Once you submit a build, if Cloudflare finds an error it can fix, it will submit a pull request to your repository that fixes it.
    3. Once you merge this pull request, Cloudflare will run another build.

    We're starting with fixing name mismatches between your Wrangler file and the Cloudflare dashboard, a top cause of build failures.

    This is just the beginning, we want your feedback on what other errors we should catch and fix next. Let us know in the Cloudflare Developers Discord, #workers-and-pages-feature-suggestions ↗.

  1. Build AI Agents with Example Prompts

    Agents Workers Workflows

    We've added an example prompt to help you get started with building AI agents and applications on Cloudflare Workers, including Workflows, Durable Objects, and Workers KV.

    You can use this prompt with your favorite AI model, including Claude 3.5 Sonnet, OpenAI's o3-mini, Gemini 2.0 Flash, or Llama 3.3 on Workers AI. Models with large context windows will allow you to paste the prompt directly: provide your own prompt within the <user_prompt></user_prompt> tags.

    Terminal window
    {paste_prompt_here}
    <user_prompt>
    user: Build an AI agent using Cloudflare Workflows. The Workflow should run when a new GitHub issue is opened on a specific project with the label 'help' or 'bug', and attempt to help the user troubleshoot the issue by calling the OpenAI API with the issue title and description, and a clear, structured prompt that asks the model to suggest 1-3 possible solutions to the issue. Any code snippets should be formatted in Markdown code blocks. Documentation and sources should be referenced at the bottom of the response. The agent should then post the response to the GitHub issue. The agent should run as the provided GitHub bot account.
    </user_prompt>

    This prompt is still experimental, but we encourage you to try it out and provide feedback ↗.

  1. Create and deploy Workers from Git repositories

    Workers
    Import repo or choose template

    You can now create a Worker by:

    • Importing a Git repository: Choose an existing Git repo on your GitHub/GitLab account and set up Workers Builds to deploy your Worker.
    • Deploying a template with Git: Choose from a brand new selection of production ready examples ↗ to help you get started with popular frameworks like Astro ↗, Remix ↗ and Next ↗ or build stateful applications with Cloudflare resources like D1 databases, Workers AI or Durable Objects! When you're ready to deploy, Cloudflare will set up your project by cloning the template to your GitHub/GitLab account, provisioning any required resources and deploying your Worker.

    With every push to your chosen branch, Cloudflare will automatically build and deploy your Worker.

    To get started, go to the Workers dashboard ↗.

    These new features are available today in the Cloudflare dashboard to a subset of Cloudflare customers, and will be coming to all customers in the next few weeks. Don't see it in your dashboard, but want early access? Add your Cloudflare Account ID to this form ↗.

  1. Revamped Workers Metrics

    Workers

    We've revamped the Workers Metrics dashboard ↗.

    Workers Metrics dashboard

    Now you can easily compare metrics across Worker versions, understand the current state of a gradual deployment, and review key Workers metrics in a single view. This new interface enables you to:

    • Drag-and-select using a graphical timepicker for precise metric selection.
    Workers Metrics graphical timepicker
    • Use histograms to visualize cumulative metrics, allowing you to bucket and compare rates over time.
    • Focus on Worker versions by directly interacting with the version numbers in the legend.
    Workers Metrics legend selector
    • Monitor and compare active gradual deployments.
    • Track error rates across versions with grouping both by version and by invocation status.
    • Measure how Smart Placement improves request duration.

    Learn more about metrics.

  1. Transform HTML quickly with streaming content

    Workers

    You can now transform HTML elements with streamed content using HTMLRewriter.

    Methods like replace, append, and prepend now accept Response and ReadableStream values as Content.

    This can be helpful in a variety of situations. For instance, you may have a Worker in front of an origin, and want to replace an element with content from a different source. Prior to this change, you would have to load all of the content from the upstream URL and convert it into a string before replacing the element. This slowed down overall response times.

    Now, you can pass the Response object directly into the replace method, and HTMLRewriter will immediately start replacing the content as it is streamed in. This makes responses faster.

    index.js
    class ElementRewriter {
      async element(element) {
        // able to replace elements while streaming content
        // the fetched body is not buffered into memory as part
        // of the replace
        let res = await fetch("https://upstream-content-provider.example");
        element.replace(res);
      }
    }
    

    export default {
      async fetch(request, env, ctx) {
        let response = await fetch("https://site-to-replace.com");
        return new HTMLRewriter()
          .on("[data-to-replace]", new ElementRewriter())
          .transform(response);
      },
    };

    For more information, see the HTMLRewriter documentation.

  1. Increased Browser Rendering limits!

    Workers Browser Rendering

    Browser Rendering now supports 10 concurrent browser instances per account and 10 new instances per minute, up from the previous limits of 2.

    This allows you to launch more browser tasks from Cloudflare Workers.

    To manage concurrent browser sessions, you can use Queues or Workflows:

    index.js
    export default {
      async queue(batch, env) {
        for (const message of batch.messages) {
          const browser = await puppeteer.launch(env.BROWSER);
          const page = await browser.newPage();
    

          try {
            await page.goto(message.url, {
              waitUntil: message.waitUntil,
            });
            // Process page...
          } finally {
            await browser.close();
          }
        }
      },
    };

  1. Support for Node.js DNS, Net, and Timer APIs in Workers

    Workers

    When using a Worker with the nodejs_compat compatibility flag enabled, you can now use the following Node.js APIs:

    node:net

    You can use node:net ↗ to create a direct connection to servers via a TCP sockets with net.Socket ↗.

    index.js
    import net from "node:net";
    

    const exampleIP = "127.0.0.1";
    

    export default {
      async fetch(req) {
        const socket = new net.Socket();
        socket.connect(4000, exampleIP, function () {
          console.log("Connected");
        });
    

        socket.write("Hello, Server!");
        socket.end();
    

        return new Response("Wrote to server", { status: 200 });
      },
    };

    Additionally, you can now use other APIs including net.BlockList ↗ and net.SocketAddress ↗.

    Note that net.Server ↗ is not supported.

    node:dns

    You can use node:dns ↗ for name resolution via DNS over HTTPS using Cloudflare DNS ↗ at 1.1.1.1.

    index.js
    import dns from "node:dns";
    

    let response = await dns.promises.resolve4("cloudflare.com", "NS");

    All node:dns functions are available, except lookup, lookupService, and resolve which throw "Not implemented" errors when called.

    node:timers

    You can use node:timers ↗ to schedule functions to be called at some future period of time.

    This includes setTimeout ↗ for calling a function after a delay, setInterval ↗ for calling a function repeatedly, and setImmediate ↗ for calling a function in the next iteration of the event loop.

    index.js
    import timers from "node:timers";
    

    console.log("first");
    timers.setTimeout(() => {
      console.log("last");
    }, 10);
    

    timers.setTimeout(() => {
      console.log("next");
    });

  1. Faster Workers Builds with Build Caching and Watch Paths

    Workers
    Build caching settingsBuild watch path settings

    Workers Builds, the integrated CI/CD system for Workers (currently in beta), now lets you cache artifacts across builds, speeding up build jobs by eliminating repeated work, such as downloading dependencies at the start of each build.

    • Build Caching: Cache dependencies and build outputs between builds with a shared project-wide cache, ensuring faster builds for the entire team.

    • Build Watch Paths: Define paths to include or exclude from the build process, ideal for monorepos to target only the files that need to be rebuilt per Workers project.

    To get started, select your Worker on the Cloudflare dashboard ↗ then go to Settings > Builds, and connect a GitHub or GitLab repository. Once connected, you'll see options to configure Build Caching and Build Watch Paths.

  1. Bypass caching for subrequests made from Cloudflare Workers, with Request.cache

    Workers

    You can now use the cache property of the Request interface to bypass Cloudflare's cache when making subrequests from Cloudflare Workers, by setting its value to no-store.

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

    When you set the value to no-store on a subrequest made from a Worker, the Cloudflare Workers runtime will not check whether a match exists in the cache, and not add the response to the cache, even if the response includes directives in the Cache-Control HTTP header that otherwise indicate that the response is cacheable.

    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, the Workers runtime threw an exception.

    If you've tried to use @planetscale/database, redis-js, stytch-node, supabase, axiom-js or have seen the error message The cache field on RequestInitializerDict is not implemented in fetch — you should try again, making sure that the Compatibility Date of your Worker is set to on or after 2024-11-11, or the cache_option_enabled compatibility flag is enabled for your Worker.

  1. Workflows is now in open beta

    Workers Workflows

    Workflows is now in open beta, and available to any developer a free or paid Workers plan.

    Workflows allow you to build multi-step applications that can automatically retry, persist state and run for minutes, hours, days, or weeks. Workflows introduces a programming model that makes it easier to build reliable, long-running tasks, observe as they progress, and programmatically trigger instances based on events across your services.

    Get started

    You can get started with Workflows by following our get started guide and/or using npm create cloudflare to pull down the starter project:

    Terminal window
    npm create cloudflare@latest workflows-starter -- --template "cloudflare/workflows-starter"

    You can open the src/index.ts file, extend it, and use wrangler deploy to deploy your first Workflow. From there, you can:

Search all changelog entries