Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Developer platform
hero image

  1. Pipelines now supports SQL transformations and Apache Iceberg

    Pipelines

    Today, we're launching the new Cloudflare Pipelines: a streaming data platform that ingests events, transforms them with SQL, and writes to R2 as Apache Iceberg ↗ tables or Parquet files.

    Pipelines can receive events via HTTP endpoints or Worker bindings, transform them with SQL, and deliver to R2 with exactly-once guarantees. This makes it easy to build analytics-ready warehouses for server logs, mobile application events, IoT telemetry, or clickstream data without managing streaming infrastructure.

    For example, here's a pipeline that ingests clickstream events and filters out bot traffic while extracting domain information:

    INSERT into events_table
    SELECT
      user_id,
      lower(event) AS event_type,
      to_timestamp_micros(ts_us) AS event_time,
      regexp_match(url, '^https?://([^/]+)')[1]  AS domain,
      url,
      referrer,
      user_agent
    FROM events_json
    WHERE event = 'page_view'
      AND NOT regexp_like(user_agent, '(?i)bot|spider');

    Get started by creating a pipeline in the dashboard or running a single command in Wrangler:

    Terminal window
    npx wrangler pipelines setup

    Check out our getting started guide to learn how to create a pipeline that delivers events to an Iceberg table you can query with R2 SQL. Read more about today's announcement in our blog post ↗.

  1. Announcing R2 SQL

    R2 SQL

    Today, we're launching the open beta for R2 SQL: A serverless, distributed query engine that can efficiently analyze petabytes of data in Apache Iceberg ↗ tables managed by R2 Data Catalog.

    R2 SQL is ideal for exploring analytical and time-series data stored in R2, such as logs, events from Pipelines, or clickstream and user behavior data.

    If you already have a table in R2 Data Catalog, running queries is as simple as:

    Terminal window
    npx wrangler r2 sql query YOUR_WAREHOUSE "
    SELECT
        user_id,
        event_type,
        value
    FROM events.user_events
    WHERE event_type = 'CHANGELOG' or event_type = 'BLOG'
      AND __ingest_ts > '2025-09-24T00:00:00Z'
    ORDER BY __ingest_ts DESC
    LIMIT 100"

    To get started with R2 SQL, check out our getting started guide or learn more about supported features in the SQL reference. For a technical deep dive into how we built R2 SQL, read our blog post ↗.

  1. Browser Rendering Playwright GA, Stagehand support (Beta), and higher limits

    Browser Run

    We’re shipping three updates to Browser Rendering:

    • Playwright support is now Generally Available and synced with Playwright v1.55 ↗, giving you a stable foundation for critical automation and AI-agent workflows.
    • We’re also adding Stagehand support (Beta) so you can combine code with natural language instructions to build more resilient automations.
    • Finally, we’ve tripled limits for paid plans across both the REST API and Browser Sessions to help you scale.

    To get started with Stagehand, refer to the Stagehand example that uses Stagehand and Workers AI to search for a movie on this example movie directory ↗, extract its details using natural language (title, year, rating, duration, and genre), and return the information along with a screenshot of the webpage.

    Stagehand example
    const stagehand = new Stagehand({
      env: "LOCAL",
      localBrowserLaunchOptions: { cdpUrl: endpointURLString(env.BROWSER) },
      llmClient: new WorkersAIClient(env.AI),
      verbose: 1,
    });
    

    await stagehand.init();
    const page = stagehand.page;
    

    await page.goto("https://demo.playwright.dev/movies");
    

    // if search is a multi-step action, stagehand will return an array of actions it needs to act on
    const actions = await page.observe('Search for "Furiosa"');
    for (const action of actions) await page.act(action);
    

    await page.act("Click the search result");
    

    // normal playwright functions work as expected
    await page.waitForSelector(".info-wrapper .cast");
    

    let movieInfo = await page.extract({
      instruction: "Extract movie information",
      schema: z.object({
        title: z.string(),
        year: z.number(),
        rating: z.number(),
        genres: z.array(z.string()),
        duration: z.number().describe("Duration in minutes"),
      }),
    });
    

    await stagehand.close();
    Stagehand video

  1. AI Search (formerly AutoRAG) now with More Models To Choose From

    AI Search

    AutoRAG is now AI Search! The new name marks a new and bigger mission: to make world-class search infrastructure available to every developer and business.

    With AI Search you can now use models from different providers like OpenAI and Anthropic. By attaching your provider keys to the AI Gateway linked to your AI Search instance, you can use many more models for both embedding and inference.

    To use AI Search with other model providers:

    1. Add provider keys to AI Gateway
      1. Go to AI > AI Gateway in the dashboard.
      2. Select or create an AI gateway.
      3. In Provider Keys, choose your provider, click Add, and enter the key.
    2. Connect a gateway to AI Search: When creating a new AI Search, select the AI Gateway with your provider keys. For an existing AI Search, go to Settings and switch to a gateway that has your keys under Resources.
    3. Select models: Embedding models are only available to be changed when creating a new AI Search. Generation model can be selected when creating a new AI Search and can be changed at any time in Settings.

    Once configured, your AI Search instance will be able to reference models available through your AI Gateway when making a /ai-search request:

    JavaScript
    export default {
      async fetch(request, env) {
    

        // Query your AI Search instance with a natural language question to an OpenAI model
        const result = await env.AI.autorag("my-ai-search").aiSearch({
          query: "What's new for Cloudflare Birthday Week?",
          model: "openai/gpt-5"
        });
    

        // Return only the generated answer as plain text
        return new Response(result.response, {
          headers: { "Content-Type": "text/plain" },
        });
      },
    };

    In the coming weeks we will also roll out updates to align the APIs with the new name. The existing APIs will continue to be supported for the time being. Stay tuned to the AI Search Changelog and Discord ↗ for more updates!

  1. Run more Containers with higher resource limits

    Containers

    You can now run more Containers concurrently with higher limits on CPU, memory, and disk.

    LimitNew LimitPrevious Limit
    Memory for concurrent live Container instances400GiB40GiB
    vCPU for concurrent live Container instances10020
    Disk for concurrent live Container instances2TB100GB

    You can now run 1000 instances of the dev instance type, 400 instances of basic, or 100 instances of standard concurrently.

    This opens up new possibilities for running larger-scale workloads on Containers.

    See the getting started guide to deploy your first Container, and the limits documentation for more details on the available instance types and limits.

  1. R2 Data Catalog now supports compaction

    R2

    You can now enable automatic compaction for Apache Iceberg ↗ tables in R2 Data Catalog to improve query performance.

    Compaction is the process of taking a group of small files and combining them into fewer larger files. This is an important maintenance operation as it helps ensure that query performance remains consistent by reducing the number of files that needs to be scanned.

    To enable automatic compaction in R2 Data Catalog, find it under R2 Data Catalog in your R2 bucket settings in the dashboard.

    compaction-dash

    Or with Wrangler, run:

    Terminal window
    npx wrangler r2 bucket catalog compaction enable <BUCKET_NAME>  --target-size 128 --token <API_TOKEN>

    To get started with compaction, check out manage catalogs. For best practices and limitations, refer to about compaction.

  1. Improved support for running multiple Workers with `wrangler dev`

    Workers

    You can run multiple Workers in a single dev command by passing multiple config files to wrangler dev:

    Terminal window
    wrangler dev --config ./web/wrangler.jsonc --config ./api/wrangler.jsonc

    Previously, if you ran the command above and then also ran wrangler dev for a different Worker, the Workers running in separate wrangler dev sessions could not communicate with each other. This prevented you from being able to use Service Bindings ↗ and Tail Workers ↗ in local development, when running separate wrangler dev sessions.

    Now, the following works as expected:

    Terminal window
    # Terminal 1: Run your application that includes both Web and API workers
    wrangler dev --config ./web/wrangler.jsonc --config ./api/wrangler.jsonc
    

    # Terminal 2: Run your auth worker separately
    wrangler dev --config ./auth/wrangler.jsonc

    These Workers can now communicate with each other across separate dev commands, regardless of your development setup.

    ./api/src/index.ts
    export default {
      async fetch(request, env) {
        // This service binding call now works across dev commands
        const authorized = await env.AUTH.isAuthorized(request);
    

        if (!authorized) {
          return new Response('Unauthorized', { status: 401 });
        }
    

        return new Response('Hello from API Worker!', { status: 200 });
      },
    };

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

  1. New Metrics View in AutoRAG

    AI Search

    AutoRAG now includes a Metrics tab that shows how your data is indexed and searched. Get a clear view of the health of your indexing pipeline, compare usage between ai-search and search, and see which files are retrieved most often.

    Metrics

    You can find these metrics within each AutoRAG instance:

    • Indexing: Track how files are ingested and see status changes over time.
    • Search breakdown: Compare usage between ai-search and search endpoints.
    • Top file retrievals: Identify which files are most frequently retrieved in a given period.

    Try it today in AutoRAG.

  1. Rate Limiting in Workers is now GA

    Workers

    Rate Limiting within Cloudflare Workers is now Generally Available (GA).

    The ratelimit binding is now stable and recommended for all production workloads. Existing deployments using the unsafe binding will continue to function to allow for a smooth transition.

    For more details, refer to Workers Rate Limiting documentation.

  1. Panic Recovery for Rust Workers

    Workers

    In workers-rs ↗, Rust panics were previously non-recoverable. A panic would put the Worker into an invalid state, and further function calls could result in memory overflows or exceptions.

    Now, when a panic occurs, in-flight requests will throw 500 errors, but the Worker will automatically and instantly recover for future requests.

    This ensures more reliable deployments. Automatic panic recovery is enabled for all new workers-rs deployments as of version 0.6.5, with no configuration required.

    Fixing Rust Panics with Wasm Bindgen

    Rust Workers are built with Wasm Bindgen, which treats panics as non-recoverable. After a panic, the entire Wasm application is considered to be in an invalid state.

    We now attach a default panic handler in Rust:

    std::panic::set_hook(Box::new(move |panic_info| {
      hook_impl(panic_info);
    }));

    Which is registered by default in the JS initialization:

    JavaScript
    import { setPanicHook } from "./index.js";
    setPanicHook(function (err) {
      console.error("Panic handler!", err);
    });

    When a panic occurs, we reset the Wasm state to revert the Wasm application to how it was when the application started.

    Resetting VM State in Wasm Bindgen

    We worked upstream on the Wasm Bindgen project to implement a new --experimental-reset-state-function compilation option ↗ which outputs a new __wbg_reset_state function.

    This function clears all internal state related to the Wasm VM, and updates all function bindings in place to reference the new WebAssembly instance.

    One other necessary change here was associating Wasm-created JS objects with an instance identity. If a JS object created by an earlier instance is then passed into a new instance later on, a new "stale object" error is specially thrown when using this feature.

    Layered Solution

    Building on this new Wasm Bindgen feature, layered with our new default panic handler, we also added a proxy wrapper to ensure all top-level exported class instantiations (such as for Rust Durable Objects) are tracked and fully reinitialized when resetting the Wasm instance. This was necessary because the workerd runtime will instantiate exported classes, which would then be associated with the Wasm instance.

    This approach now provides full panic recovery for Rust Workers on subsequent requests.

    Of course, we never want panics, but when they do happen they are isolated and can be investigated further from the error logs - avoiding broader service disruption.

    WebAssembly Exception Handling

    In the future, full support for recoverable panics could be implemented without needing reinitialization at all, utilizing the WebAssembly Exception Handling ↗ proposal, part of the newly announced WebAssembly 3.0 ↗ specification. This would allow unwinding panics as normal JS errors, and concurrent requests would no longer fail.

    We're making significant improvements to the reliability of Rust Workers ↗. Join us in #rust-on-workers on the Cloudflare Developers Discord ↗ to stay updated.

  1. Connect and secure any private or public app by hostname, not IP — with hostname routing for Cloudflare Tunnel

    Cloudflare Tunnel Cloudflare Tunnel for SASE

    You can now route private traffic to Cloudflare Tunnel based on a hostname or domain, moving beyond the limitations of IP-based routing. This new capability is free for all Cloudflare One customers.

    Previously, Tunnel routes could only be defined by IP address or CIDR range. This created a challenge for modern applications with dynamic or ephemeral IP addresses, often forcing administrators to maintain complex and brittle IP lists.

    Hostname-based routing in Cloudflare Tunnel

    What’s new:

    • Hostname & Domain Routing: Create routes for individual hostnames (e.g., payroll.acme.local) or entire domains (e.g., *.acme.local) and direct their traffic to a specific Tunnel.
    • Simplified Zero Trust Policies: Build resilient policies in Cloudflare Access and Gateway using stable hostnames, making it dramatically easier to apply per-resource authorization for your private applications.
    • Precise Egress Control: Route traffic for public hostnames (e.g., bank.example.com) through a specific Tunnel to enforce a dedicated source IP, solving the IP allowlist problem for third-party services.
    • No More IP Lists: This feature makes the workaround of maintaining dynamic IP Lists for Tunnel connections obsolete.

    Get started in the Tunnels section of the Zero Trust dashboard with your first private hostname or public hostname route.

    Learn more in our blog post ↗.

  1. Increased vCPU for Workers Builds on paid plans

    Workers

    We recently increased the available disk space from 8 GB to 20 GB for all plans. Building on that improvement, we’re now doubling the CPU power available for paid plans — from 2 vCPU to 4 vCPU.

    These changes continue our focus on making Workers Builds faster and more reliable.

    MetricFree PlanPaid Plans
    CPU2 vCPU4 vCPU

    Performance Improvements

    • Fast build times: Even single-threaded workloads benefit from having more vCPUs
    • 2x faster multi-threaded builds: Tools like esbuild ↗ and webpack ↗ can now utilize additional cores, delivering near-linear performance scaling

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

  1. Preview URLs now default to opt-in

    Workers

    To prevent the accidental exposure of applications, we've updated how Worker preview URLs (<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev) are handled. We made this change to ensure preview URLs are only active when intentionally configured, improving the default security posture of your Workers.

    One-Time Update for Workers with workers.dev Disabled

    We performed a one-time update to disable preview URLs for existing Workers where the workers.dev subdomain was also disabled.

    Because preview URLs were historically enabled by default, users who had intentionally disabled their workers.dev route may not have realized their Worker was still accessible at a separate preview URL. This update was performed to ensure that using a preview URL is always an intentional, opt-in choice.

    If your Worker was affected, its preview URL (<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev) will now direct to an informational page explaining this change.

    How to Re-enable Your Preview URL

    If your preview URL was disabled, you can re-enable it via the Cloudflare dashboard by navigating to your Worker's Settings page and toggling on the Preview URL.

    Alternatively, you can use Wrangler by adding the preview_urls = true setting to your Wrangler file and redeploying the Worker.

    JSONC
    {
      "preview_urls": true
    }

    Note: You can set preview_urls = true with any Wrangler version that supports the preview URL flag (v3.91.0+). However, we recommend updating to v4.34.0 or newer, as this version defaults preview_urls to false, ensuring preview URLs are always enabled by explicit choice.

  1. Remote bindings GA - Connect to remote resources (D1, KV, R2, etc.) during local development

    Workers

    Three months ago we announced the public beta of remote bindings for local development. Now, we're excited to say that it's available for everyone in Wrangler, Vite, and Vitest without using an experimental flag!

    With remote bindings, you can now connect to deployed resources like R2 buckets and D1 databases while running Worker code on your local machine. This means you can test your local code changes against real data and services, without the overhead of deploying for each iteration.

    Example configuration

    To enable remote bindings, add "remote" : true to each binding that you want to rely on a remote resource running on Cloudflare:

    JSONC
    {
      "name": "my-worker",
      // Set this to today's date
      "compatibility_date": "2026-04-30",
    

      "r2_buckets": [
        {
          "bucket_name": "screenshots-bucket",
          "binding": "screenshots_bucket",
          "remote": true,
        },
      ],
    }

    When remote bindings are configured, your Worker still executes locally, but all binding calls are proxied to the deployed resource that runs on Cloudflare's network.

    You can try out remote bindings for local development today with:

  1. D1 automatically retries read-only queries

    D1 Workers

    D1 now detects read-only queries and automatically attempts up to two retries to execute those queries in the event of failures with retryable errors. You can access the number of execution attempts in the returned response metadata property total_attempts.

    At the moment, only read-only queries are retried, that is, queries containing only the following SQLite keywords: SELECT, EXPLAIN, WITH. Queries containing any SQLite keyword ↗ that leads to database writes are not retried.

    The retry success ratio among read-only retryable errors varies from 5% all the way up to 95%, depending on the underlying error and its duration (like network errors or other internal errors).

    The retry success ratio among all retryable errors is lower, indicating that there are write-queries that could be retried. Therefore, we recommend D1 users to continue applying retries in their own code for queries that are not read-only but are idempotent according to the business logic of the application.

    D1 automatically query retries success ratio

    D1 ensures that any retry attempt does not cause database writes, making the automatic retries safe from side-effects, even if a query causing changes slips through the read-only detection. D1 achieves this by checking for modifications after every query execution, and if any write occurred due to a retry attempt, the query is rolled back.

    The read-only query detection heuristics are simple for now, and there is room for improvement to capture more cases of queries that can be retried, so this is just the beginning.

  1. Worker version rollback limit increased from 10 to 100

    Workers

    The number of recent versions available for a Worker rollback has been increased from 10 to 100.

    This allows you to:

    • Promote any of the 100 most recent versions to be the active deployment.

    • Split traffic using gradual deployments between your latest code and any of the 100 most recent versions.

    You can do this through the Cloudflare dashboard or with Wrangler's rollback command

    Learn more about versioned deployments and rollbacks.

  1. Agents SDK v0.1.0 and workers-ai-provider v2.0.0 with AI SDK v5 support

    Agents Workers

    We've shipped a new release for the Agents SDK ↗ bringing full compatibility with AI SDK v5 ↗ and introducing automatic message migration that handles all legacy formats transparently.

    This release includes improved streaming and tool support, tool confirmation detection (for "human in the loop" systems), enhanced React hooks with automatic tool resolution, improved error handling for streaming responses, and seamless migration utilities that work behind the scenes.

    This makes it ideal for building production AI chat interfaces with Cloudflare Workers AI models, agent workflows, human-in-the-loop systems, or any application requiring reliable message handling across SDK versions — all while maintaining backward compatibility.

    Additionally, we've updated workers-ai-provider v2.0.0, the official provider for Cloudflare Workers AI models, to be compatible with AI SDK v5.

    useAgentChat(options)

    Creates a new chat interface with enhanced v5 capabilities.

    TypeScript
    // Basic chat setup
    const { messages, sendMessage, addToolResult } = useAgentChat({
      agent,
      experimental_automaticToolResolution: true,
      tools,
    });
    

    // With custom tool confirmation
    const chat = useAgentChat({
      agent,
      experimental_automaticToolResolution: true,
      toolsRequiringConfirmation: ["dangerousOperation"],
    });

    Automatic Tool Resolution

    Tools are automatically categorized based on their configuration:

    TypeScript
    const tools = {
      // Auto-executes (has execute function)
      getLocalTime: {
        description: "Get current local time",
        inputSchema: z.object({}),
        execute: async () => new Date().toLocaleString(),
      },
    

      // Requires confirmation (no execute function)
      deleteFile: {
        description: "Delete a file from the system",
        inputSchema: z.object({
          filename: z.string(),
        }),
      },
    

      // Server-executed (no client confirmation)
      analyzeData: {
        description: "Analyze dataset on server",
        inputSchema: z.object({ data: z.array(z.number()) }),
        serverExecuted: true,
      },
    } satisfies Record<string, AITool>;

    Message Handling

    Send messages using the new v5 format with parts array:

    TypeScript
    // Text message
    sendMessage({
      role: "user",
      parts: [{ type: "text", text: "Hello, assistant!" }],
    });
    

    // Multi-part message with file
    sendMessage({
      role: "user",
      parts: [
        { type: "text", text: "Analyze this image:" },
        { type: "image", image: imageData },
      ],
    });

    Tool Confirmation Detection

    Simplified logic for detecting pending tool confirmations:

    TypeScript
    const pendingToolCallConfirmation = messages.some((m) =>
      m.parts?.some(
        (part) => isToolUIPart(part) && part.state === "input-available",
      ),
    );
    

    // Handle tool confirmation
    if (pendingToolCallConfirmation) {
      await addToolResult({
        toolCallId: part.toolCallId,
        tool: getToolName(part),
        output: "User approved the action",
      });
    }

    Automatic Message Migration

    Seamlessly handle legacy message formats without code changes.

    TypeScript
    // All these formats are automatically converted:
    

    // Legacy v4 string content
    const legacyMessage = {
      role: "user",
      content: "Hello world",
    };
    

    // Legacy v4 with tool calls
    const legacyWithTools = {
      role: "assistant",
      content: "",
      toolInvocations: [
        {
          toolCallId: "123",
          toolName: "weather",
          args: { city: "SF" },
          state: "result",
          result: "Sunny, 72°F",
        },
      ],
    };
    

    // Automatically becomes v5 format:
    // {
    //   role: "assistant",
    //   parts: [{
    //     type: "tool-call",
    //     toolCallId: "123",
    //     toolName: "weather",
    //     args: { city: "SF" },
    //     state: "result",
    //     result: "Sunny, 72°F"
    //   }]
    // }

    Tool Definition Updates

    Migrate tool definitions to use the new inputSchema property.

    TypeScript
    // Before (AI SDK v4)
    const tools = {
      weather: {
        description: "Get weather information",
        parameters: z.object({
          city: z.string(),
        }),
        execute: async (args) => {
          return await getWeather(args.city);
        },
      },
    };
    

    // After (AI SDK v5)
    const tools = {
      weather: {
        description: "Get weather information",
        inputSchema: z.object({
          city: z.string(),
        }),
        execute: async (args) => {
          return await getWeather(args.city);
        },
      },
    };

    Cloudflare Workers AI Integration

    Seamless integration with Cloudflare Workers AI models through the updated workers-ai-provider v2.0.0.

    Model Setup with Workers AI

    Use Cloudflare Workers AI models directly in your agent workflows:

    TypeScript
    import { createWorkersAI } from "workers-ai-provider";
    import { useAgentChat } from "agents/ai-react";
    

    // Create Workers AI model (v2.0.0 - same API, enhanced v5 internals)
    const model = createWorkersAI({
      binding: env.AI,
    })("@cf/meta/llama-3.2-3b-instruct");

    Enhanced File and Image Support

    Workers AI models now support v5 file handling with automatic conversion:

    TypeScript
    // Send images and files to Workers AI models
    sendMessage({
      role: "user",
      parts: [
        { type: "text", text: "Analyze this image:" },
        {
          type: "file",
          data: imageBuffer,
          mediaType: "image/jpeg",
        },
      ],
    });
    

    // Workers AI provider automatically converts to proper format

    Streaming with Workers AI

    Enhanced streaming support with automatic warning detection:

    TypeScript
    // Streaming with Workers AI models
    const result = await streamText({
      model: createWorkersAI({ binding: env.AI })("@cf/meta/llama-3.2-3b-instruct"),
      messages,
      onChunk: (chunk) => {
        // Enhanced streaming with warning handling
        console.log(chunk);
      },
    });

    Import Updates

    Update your imports to use the new v5 types:

    TypeScript
    // Before (AI SDK v4)
    import type { Message } from "ai";
    import { useChat } from "ai/react";
    

    // After (AI SDK v5)
    import type { UIMessage } from "ai";
    // or alias for compatibility
    import type { UIMessage as Message } from "ai";
    import { useChat } from "@ai-sdk/react";

    Resources

    Feedback Welcome

    We'd love your feedback! We're particularly interested in feedback on:

    • Migration experience - How smooth was the upgrade process?
    • Tool confirmation workflow - Does the new automatic detection work as expected?
    • Message format handling - Any edge cases with legacy message conversion?

  1. Built with Cloudflare button

    Workers

    We've updated our "Built with Cloudflare" button to make it easier to share that you're building on Cloudflare with the world. Embed it in your project's README, blog post, or wherever you want to let people know.

    Built with Cloudflare

    Check out the documentation for usage information.

  1. Deploy static sites to Workers without a configuration file

    Workers

    Deploying static site to Workers is now easier. When you run wrangler deploy [directory] or wrangler deploy --assets [directory] without an existing configuration file, Wrangler CLI now guides you through the deployment process with interactive prompts.

    Before and after

    Before: Required remembering multiple flags and parameters

    Terminal window
    wrangler deploy --assets ./dist --compatibility-date 2025-09-09 --name my-project

    After: Simple directory deployment with guided setup

    Terminal window
    wrangler deploy dist
    # Interactive prompts handle the rest as shown in the example flow below

    What's new

    Interactive prompts for missing configuration:

    • Wrangler detects when you're trying to deploy a directory of static assets
    • Prompts you to confirm the deployment type
    • Asks for a project name (with smart defaults)
    • Automatically sets the compatibility date to today

    Automatic configuration generation:

    • Creates a wrangler.jsonc file with your deployment settings
    • Stores your choices for future deployments
    • Eliminates the need to remember complex command-line flags

    Example workflow

    Terminal window
    # Deploy your built static site
    wrangler deploy dist
    

    # Wrangler will prompt:
    ✔ It looks like you are trying to deploy a directory of static assets only. Is this correct? … yes
    ✔ What do you want to name your project? … my-astro-site
    

    # Automatically generates a wrangler.jsonc file and adds it to your project:
    {
      "name": "my-astro-site",
      "compatibility_date": "2025-09-09",
      "assets": {
        "directory": "dist"
      }
    }
    

    # Next time you run wrangler deploy, this will use the configuration in your newly generated wrangler.jsonc file
    wrangler deploy

    Requirements

    • You must use Wrangler version 4.24.4 or later in order to use this feature

  1. Introducing EmbeddingGemma from Google on Workers AI

    Workers AI

    We're excited to be a launch partner alongside Google ↗ to bring their newest embedding model, EmbeddingGemma, to Workers AI that delivers best-in-class performance for its size, enabling RAG and semantic search use cases.

    @cf/google/embeddinggemma-300m is a 300M parameter embedding model from Google, built from Gemma 3 and the same research used to create Gemini models. This multilingual model supports 100+ languages, making it ideal for RAG systems, semantic search, content classification, and clustering tasks.

    Using EmbeddingGemma in AI Search: Now you can leverage EmbeddingGemma directly through AI Search for your RAG pipelines. EmbeddingGemma's multilingual capabilities make it perfect for global applications that need to understand and retrieve content across different languages with exceptional accuracy.

    To use EmbeddingGemma for your AI Search projects:

    1. Go to Create in the AI Search dashboard ↗
    2. Follow the setup flow for your new RAG instance
    3. In the Generate Index step, open up More embedding models and select @cf/google/embeddinggemma-300m as your embedding model
    4. Complete the setup to create an AI Search

    Try it out and let us know what you think!

  1. Increased static asset limits for Workers

    Workers Workers for Platforms

    You can now upload up to 100,000 static assets per Worker version

    • Paid and Workers for Platforms users can now upload up to 100,000 static assets per Worker version, a 5x increase from the previous limit of 20,000.
    • Customers on the free plan still have the same limit as before — 20,000 static assets per version of your Worker
    • The individual file size limit of 25 MiB remains unchanged for all customers.

    This increase allows you to build larger applications with more static assets without hitting limits.

    Wrangler

    To take advantage of the increased limits, you must use Wrangler version 4.34.0 or higher. Earlier versions of Wrangler will continue to enforce the previous 20,000 file limit.

    Learn more

    For more information about Workers static assets, see the Static Assets documentation and Platform Limits.

  1. A new, simpler REST API for Cloudflare Workers (Beta)

    Workers

    You can now manage Workers, Versions, and Deployments as separate resources with a new, resource-oriented API (Beta).

    This new API is supported in the Cloudflare Terraform provider ↗ and the Cloudflare Typescript SDK ↗, allowing platform teams to manage a Worker's infrastructure in Terraform, while development teams handle code deployments from a separate repository or workflow. We also designed this API with AI agents in mind, as a clear, predictable structure is essential for them to reliably build, test, and deploy applications.

    Try it out

    Before: Eight+ endpoints with mixed responsibilities

    Before

    The existing API was originally designed for simple, one-shot script uploads:

    Terminal window
    curl -X PUT "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/scripts/$SCRIPT_NAME" \
        -H "X-Auth-Email: $CLOUDFLARE_EMAIL" \
        -H "X-Auth-Key: $CLOUDFLARE_API_KEY" \
        -H "Content-Type: multipart/form-data" \
        -F 'metadata={
          "main_module": "worker.js",
          "compatibility_date": "$today$"
        }' \
        -F "worker.js=@worker.js;type=application/javascript+module"

    This API worked for creating a basic Worker, uploading all of its code, and deploying it immediately — but came with challenges:

    • A Worker couldn't exist without code: To create a Worker, you had to upload its code in the same API request. This meant platform teams couldn't provision Workers with the proper settings, and then hand them off to development teams to deploy the actual code.

    • Several endpoints implicitly created deployments: Simple updates like adding a secret or changing a script's content would implicitly create a new version and immediately deploy it.

    • Updating a setting was confusing: Configuration was scattered across eight endpoints with overlapping responsibilities. This ambiguity made it difficult for human developers (and even more so for AI agents) to reliably update a Worker via API.

    • Scripts used names as primary identifiers: This meant simple renames could turn into a risky migration, requiring you to create a brand new Worker and update every reference. If you were using Terraform, this could inadvertently destroy your Worker altogether.

    After: Three resources with clear boundaries

    After

    All endpoints now use simple JSON payloads, with script content embedded as base64-encoded strings -- a more consistent and reliable approach than the previous multipart/form-data format.

    • Worker: The parent resource representing your application. It has a stable UUID and holds persistent settings like name, tags, and logpush. You can now create a Worker to establish its identity and settings before any code is uploaded.

    • Version: An immutable snapshot of your code and its specific configuration, like bindings and compatibility_date. Creating a new version is a safe action that doesn't affect live traffic.

    • Deployment: An explicit action that directs traffic to a specific version.

    Why this matters

    You can now create Workers before uploading code

    Workers are now standalone resources that can be created and configured without any code. Platform teams can provision Workers with the right settings, then hand them off to development teams for implementation.

    Example: Typescript SDK

    TypeScript
    // Step 1: Platform team creates the Worker resource (no code needed)
    const worker = await client.workers.beta.workers.create({
      name: "payment-service",
      account_id: "...",
      observability: {
        enabled: true,
      },
    });
    

    // Step 2: Development team adds code and creates a version later
    const version = await client.workers.beta.workers.versions.create(worker.id, {
      account_id: "...",
      main_module: "worker.js",
      compatibility_date: "$today",
      bindings: [ /*...*/ ],
      modules: [
        {
          name: "worker.js",
          content_type: "application/javascript+module",
          content_base64: Buffer.from(scriptContent).toString("base64"),
        },
      ],
    });
    

    // Step 3: Deploy explicitly when ready
    const deployment = await client.workers.scripts.deployments.create(worker.name, {
      account_id: "...",
      strategy: "percentage",
      versions: [
        {
          percentage: 100,
          version_id: version.id,
        },
      ],
    });

    Example: Terraform

    If you use Terraform, you can now declare the Worker in your Terraform configuration and manage configuration outside of Terraform in your Worker's wrangler.jsonc file and deploy code changes using Wrangler.

    resource "cloudflare_worker" "my_worker" {
      account_id = "..."
      name = "my-important-service"
    }
    # Manage Versions and Deployments here or outside of Terraform
    # resource "cloudflare_worker_version" "my_worker_version" {}
    # resource "cloudflare_workers_deployment" "my_worker_deployment" {}

    Deployments are always explicit, never implicit

    Creating a version and deploying it are now always explicit, separate actions - never implicit side effects. To update version-specific settings (like bindings), you create a new version with those changes. The existing deployed version remains unchanged until you explicitly deploy the new one.

    Terminal window
    # Step 1: Create a new version with updated settings (doesn't affect live traffic)
    POST /workers/workers/{id}/versions
    {
      "compatibility_date": "$today",
      "bindings": [
        {
          "name": "MY_NEW_ENV_VAR",
          "text": "new_value",
          "type": "plain_text"
        }
      ],
      "modules": [...]
    }
    

    # Step 2: Explicitly deploy when ready (now affects live traffic)
    POST /workers/scripts/{script_name}/deployments
    {
      "strategy": "percentage",
      "versions": [
        {
          "percentage": 100,
          "version_id": "new_version_id"
        }
      ]
    }

    Settings are clearly organized by scope

    Configuration is now logically divided: Worker settings (like name and tags) persist across all versions, while Version settings (like bindings and compatibility_date) are specific to each code snapshot.

    Terminal window
    # Worker settings (the parent resource)
    PUT /workers/workers/{id}
    {
      "name": "payment-service",
      "tags": ["production"],
      "logpush": true,
    }
    Terminal window
    # Version settings (the "code")
    POST /workers/workers/{id}/versions
    {
      "compatibility_date": "$today",
      "bindings": [...],
      "modules": [...]
    }

    /workers API endpoints now support UUIDs (in addition to names)

    The /workers/workers/ path now supports addressing a Worker by both its immutable UUID and its mutable name.

    Terminal window
    # Both work for the same Worker
    GET /workers/workers/29494978e03748669e8effb243cf2515  # UUID (stable for automation)
    GET /workers/workers/payment-service                  # Name (convenient for humans)

    This dual approach means:

    • Developers can use readable names for debugging.
    • Automation can rely on stable UUIDs to prevent errors when Workers are renamed.
    • Terraform can rename Workers without destroying and recreating them.

    Learn more

    Technical notes

    • The pre-existing Workers REST API remains fully supported. Once the new API exits beta, we'll provide a migration timeline with ample notice and comprehensive migration guides.
    • Existing Terraform resources and SDK methods will continue to be fully supported through the current major version.
    • While the Deployments API currently remains on the /scripts/ endpoint, we plan to introduce a new Deployments endpoint under /workers/ to match the new API structure.

  1. Cloudflare Tunnel and Networks API will no longer return deleted resources by default starting December 1, 2025

    Cloudflare Tunnel Cloudflare Tunnel for SASE

    Starting December 1, 2025, list endpoints for the Cloudflare Tunnel API and Zero Trust Networks API will no longer return deleted tunnels, routes, subnets and virtual networks by default. This change makes the API behavior more intuitive by only returning active resources unless otherwise specified.

    No action is required if you already explicitly set is_deleted=false or if you only need to list active resources.

    This change affects the following API endpoints:

    What is changing?

    The default behavior of the is_deleted query parameter will be updated.

    ScenarioPrevious behavior (before December 1, 2025)New behavior (from December 1, 2025)
    is_deleted parameter is omittedReturns active & deleted tunnels, routes, subnets and virtual networksReturns only active tunnels, routes, subnets and virtual networks

    Action required

    If you need to retrieve deleted (or all) resources, please update your API calls to explicitly include the is_deleted parameter before December 1, 2025.

    To get a list of only deleted resources, you must now explicitly add the is_deleted=true query parameter to your request:

    Terminal window
    # Example: Get ONLY deleted Tunnels
    curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/tunnels?is_deleted=true" \
         -H "Authorization: Bearer $API_TOKEN"
    

    # Example: Get ONLY deleted Virtual Networks
    curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/virtual_networks?is_deleted=true" \
         -H "Authorization: Bearer $API_TOKEN"

    Following this change, retrieving a complete list of both active and deleted resources will require two separate API calls: one to get active items (by omitting the parameter or using is_deleted=false) and one to get deleted items (is_deleted=true).

    Why we’re making this change

    This update is based on user feedback and aims to:

    • Create a more intuitive default: Aligning with common API design principles where list operations return only active resources by default.
    • Reduce unexpected results: Prevents users from accidentally operating on deleted resources that were returned unexpectedly.
    • Improve performance: For most users, the default query result will now be smaller and more relevant.

    To learn more, please visit the Cloudflare Tunnel API and Zero Trust Networks API documentation.

  1. Terraform v5.9 now available

    Cloudflare Fundamentals Terraform

    Earlier this year, we announced the launch of the new Terraform v5 Provider. We are aware of the high number of issues ↗ reported by the Cloudflare community related to the v5 release. We have committed to releasing improvements on a 2 week cadence to ensure its stability and reliability, including the v5.9 release. We have also pivoted from an issue-to-issue approach to a resource-per-resource approach - we will be focusing on specific resources for every release, stabilizing the release, and closing all associated bugs with that resource before moving onto resolving migration issues.

    Thank you for continuing to raise issues. We triage them weekly and they help make our products stronger.

    This release includes a new resource, cloudflare_snippet, which replaces cloudflare_snippets. cloudflare_snippet is now considered deprecated but can still be used. Please utilize cloudflare_snippet as soon as possible.

    Changes

    • Resources stabilized:
      • cloudflare_zone_setting
      • cloudflare_worker_script
      • cloudflare_worker_route
      • tiered_cache
    • NEW resource cloudflare_snippet which should be used in place of cloudflare_snippets. cloudflare_snippets is now deprecated. This enables the management of Cloudflare's snippet functionality through Terraform.
    • DNS Record Improvements: Enhanced handling of DNS record drift detection
    • Load Balancer Fixes: Resolved created_on field inconsistencies and improved pool configuration handling
    • Bot Management: Enhanced auto-update model state consistency and fight mode configurations
    • Other bug fixes

    For a more detailed look at all of the changes, refer to the changelog ↗ in GitHub.

    Issues Closed

    If you have an unaddressed issue with the provider, we encourage you to check the open issues ↗ and open a new issue if one does not already exist for what you are experiencing.

    Upgrading

    We suggest holding off on migration to v5 while we work on stabilization. This help will you avoid any blocking issues while the Terraform resources are actively being stabilized.

    If you'd like more information on migrating from v4 to v5, please make use of the migration guide ↗. We have provided automated migration scripts using Grit which simplify the transition. These do not support implementations which use Terraform modules, so customers making use of modules need to migrate manually. Please make use of terraform plan to test your changes before applying, and let us know if you encounter any additional issues by reporting to our GitHub repository ↗.

    For more info

  1. Deepgram and Leonardo partner models now available on Workers AI

    Workers AI

    New state-of-the-art models have landed on Workers AI! This time, we're introducing new partner models trained by our friends at Deepgram ↗ and Leonardo ↗, hosted on Workers AI infrastructure.

    As well, we're introuding a new turn detection model that enables you to detect when someone is done speaking — useful for building voice agents!

    Read the blog ↗ for more details and check out some of the new models on our platform:

    You can filter out new partner models with the Partner capability on our Models page.

    As well, we're introducing WebSocket support for some of our audio models, which you can filter though the Realtime capability on our Models page. WebSockets allows you to create a bi-directional connection to our inference server with low latency — perfect for those that are building voice agents.

    An example python snippet on how to use WebSockets with our new Aura model:

    import json
    import os
    import asyncio
    import websockets
    

    uri = f"wss://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/deepgram/aura-1"
    

    input = [
        "Line one, out of three lines that will be provided to the aura model.",
        "Line two, out of three lines that will be provided to the aura model.",
        "Line three, out of three lines that will be provided to the aura model. This is a last line.",
    ]
    

    

    async def text_to_speech():
        async with websockets.connect(uri, additional_headers={"Authorization": os.getenv("CF_TOKEN")}) as websocket:
            print("connection established")
            for line in input:
                print(f"sending `{line}`")
                await websocket.send(json.dumps({"type": "Speak", "text": line}))
    

                print("line was sent, flushing")
                await websocket.send(json.dumps({"type": "Flush"}))
                print("flushed, recving")
                resp = await websocket.recv()
                print(f"response received {resp}")
    

    

    if __name__ == "__main__":
        asyncio.run(text_to_speech())
Search all changelog entries