Skip to content
Cloudflare Docs

Changelog

New updates and improvements at Cloudflare. Subscribe to RSS

hero image

  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:

    Terminal window
    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:

    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:

    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 Guardrails in AI Gateway

    AI Gateway

    AI Gateway now includes Guardrails, to help you monitor your AI apps for harmful or inappropriate content and deploy safely.

    Within the AI Gateway settings, you can configure:

    • Guardrails: Enable or disable content moderation as needed.
    • Evaluation scope: Select whether to moderate user prompts, model responses, or both.
    • Hazard categories: Specify which categories to monitor and determine whether detected inappropriate content should be blocked or flagged.
    Guardrails in AI Gateway

    Learn more in the blog ↗ or our documentation.

  1. Workers AI now supports structured JSON outputs.

    Workers AI

    Workers AI now supports structured JSON outputs with JSON mode, which allows you to request a structured output response when interacting with AI models.

    This makes it much easier to retrieve structured data from your AI models, and avoids the (error prone!) need to parse large unstructured text responses to extract your data.

    JSON mode in Workers AI is compatible with the OpenAI SDK's structured outputs ↗ response_format API, which can be used directly in a Worker:

    import { OpenAI } from "openai";
    

    // Define your JSON schema for a calendar event
    const CalendarEventSchema = {
      type: "object",
      properties: {
        name: { type: "string" },
        date: { type: "string" },
        participants: { type: "array", items: { type: "string" } },
      },
      required: ["name", "date", "participants"],
    };
    

    export default {
      async fetch(request, env) {
        const client = new OpenAI({
          apiKey: env.OPENAI_API_KEY,
          // Optional: use AI Gateway to bring logs, evals & caching to your AI requests
          // https://developers.cloudflare.com/ai-gateway/providers/openai/
          // baseUrl: "https://gateway.ai.cloudflare.com/v1/{account_id}/{gateway_id}/openai"
        });
    

        const response = await client.chat.completions.create({
          model: "gpt-4o-2024-08-06",
          messages: [
            { role: "system", content: "Extract the event information." },
            {
              role: "user",
              content: "Alice and Bob are going to a science fair on Friday.",
            },
          ],
          // Use the `response_format` option to request a structured JSON output
          response_format: {
            // Set json_schema and provide ra schema, or json_object and parse it yourself
            type: "json_schema",
            schema: CalendarEventSchema, // provide a schema
          },
        });
    

        // This will be of type CalendarEventSchema
        const event = response.choices[0].message.parsed;
    

        return Response.json({
          calendar_event: event,
        });
      },
    };

    To learn more about JSON mode and structured outputs, visit the Workers AI documentation.

  1. Concurrent Workflow instances limits increased.

    Workflows

    Workflows now supports up to 4,500 concurrent (running) instances, up from the previous limit of 100. This limit will continue to increase during the Workflows open beta. This increase applies to all users on the Workers Paid plan, and takes effect immediately.

    Review the Workflows limits documentation and/or dive into the get started guide to start building on Workflows.

  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-sdk package directly

    Terminal window
    npm i agents-sdk

    ... and then define your first Agent:

    import { Agent } from 'agents-sdk';
    

    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. Super Slurper now supports migrations from all S3-compatible storage providers

    R2

    Super Slurper can now migrate data from any S3-compatible object storage provider to Cloudflare R2. This includes transfers from services like MinIO, Wasabi, Backblaze B2, and DigitalOcean Spaces.

    Super Slurper S3-Compatible Source

    For more information on Super Slurper and how to migrate data from your existing S3-compatible storage buckets to R2, refer to our documentation.

  1. Bind the Images API to your Worker

    Cloudflare Images

    You can now interact with the Images API directly in your Worker.

    This allows more fine-grained control over transformation request flows and cache behavior. For example, you can resize, manipulate, and overlay images without requiring them to be accessible through a URL.

    The Images binding can be configured in the Cloudflare dashboard for your Worker or in the wrangler.toml file in your project's directory:

    [images]
    binding = "IMAGES" # i.e. available in your Worker on env.IMAGES

    Within your Worker code, you can interact with this binding by using env.IMAGES.

    Here's how you can rotate, resize, and blur an image, then output the image as AVIF:

    ​​const info = await env.IMAGES.info(stream);
    // stream contains a valid image, and width/height is available on the info object
    

    const response = (
    await env.IMAGES.input(stream)
            .transform({ rotate: 90 })
            .transform({ width: 128 })
            .output({ format: "image/avif" })
          ).response();
    

    return response;

    For more information, refer to Images Bindings.

  1. Workers AI larger context windows

    Workers AI

    We've updated the Workers AI text generation models to include context windows and limits definitions and changed our APIs to estimate and validate the number of tokens in the input prompt, not the number of characters.

    This update allows developers to use larger context windows when interacting with Workers AI models, which can lead to better and more accurate results.

    Our catalog page provides more information about each model's supported context window.

  1. Zaraz moves to the “Tag Management” category in the Cloudflare dashboard

    Zaraz

    Zaraz at zone level to Tag management at account level

    Previously, you could only configure Zaraz by going to each individual zone under your Cloudflare account. Now, if you’d like to get started with Zaraz or manage your existing configuration, you can navigate to the Tag Management ↗ section on the Cloudflare dashboard – this will make it easier to compare and configure the same settings across multiple zones.

    These changes will not alter any existing configuration or entitlements for zones you already have Zaraz enabled on. If you’d like to edit existing configurations, you can go to the Tag Setup ↗ section of the dashboard, and select the zone you'd like to edit.

  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 ↗.