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. Select Wrangler environments using the CLOUDFLARE_ENV environment variable

    Workers

    Wrangler now supports using the CLOUDFLARE_ENV environment variable to select the active environment for your Worker commands. This provides a more flexible way to manage environments, especially when working with build tools and CI/CD pipelines.

    What's new

    Environment selection via environment variable:

    • Set CLOUDFLARE_ENV to specify which environment to use for Wrangler commands
    • Works with all Wrangler commands that support the --env flag
    • The --env command line argument takes precedence over the CLOUDFLARE_ENV environment variable

    Example usage

    Terminal window
    # Deploy to the production environment using CLOUDFLARE_ENV
    CLOUDFLARE_ENV=production wrangler deploy
    

    # Upload a version to the staging environment
    CLOUDFLARE_ENV=staging wrangler versions upload
    

    # The --env flag takes precedence over CLOUDFLARE_ENV
    CLOUDFLARE_ENV=dev wrangler deploy --env production
    # This will deploy to production, not dev

    Use with build tools

    The CLOUDFLARE_ENV environment variable is particularly useful when working with build tools like Vite. You can set the environment once during the build process, and it will be used for both building and deploying your Worker:

    Terminal window
    # Set the environment for both build and deploy
    CLOUDFLARE_ENV=production npm run build & wrangler deploy

    When using @cloudflare/vite-plugin, the build process generates a "redirected deploy config" that is flattened to only contain the active environment. Wrangler will validate that the environment specified matches the environment used during the build to prevent accidentally deploying a Worker built for one environment to a different environment.

    Learn more

  1. Workers automatic tracing, now in open beta

    Workers

    Enable automatic tracing on your Workers, giving you detailed metadata and timing information for every operation your Worker performs.

    Tracing example

    Tracing helps you identify performance bottlenecks, resolve errors, and understand how your Worker interacts with other services on the Workers platform. You can now answer questions like:

    • Which calls are slowing down my application?
    • Which queries to my database take the longest?
    • What happened within a request that resulted in an error?

    You can now:

    To get started, set:

    JSONC
    {
      "observability": {
        "tracing": {
          "enabled": true,
        },
      },
    }

    Want to learn more?

  1. D1 can restrict data localization with jurisdictions

    D1 Workers

    You can now set a jurisdiction when creating a D1 database to guarantee where your database runs and stores data. Jurisdictions can help you comply with data localization regulations such as GDPR. Supported jurisdictions include eu and fedramp.

    A jurisdiction can only be set at database creation time via wrangler, REST API or the UI and cannot be added/updated after the database already exists.

    Terminal window
    npx wrangler@latest d1 create db-with-jurisdiction --jurisdiction eu
    curl -X POST "https://api.cloudflare.com/client/v4/accounts/<account_id>/d1/database" \
         -H "Authorization: Bearer $TOKEN" \
         -H "Content-Type: application/json" \
         --data '{"name": "db-with-jurisdiction", "jurisdiction": "eu" }'

    To learn more, visit D1's data location documentation.

  1. Announcing Workers VPC Services (Beta)

    Workers VPC

    Workers VPC Services is now available, enabling your Workers to securely access resources in your private networks, without having to expose them on the public Internet.

    What's new

    • VPC Services: Create secure connections to internal APIs, databases, and services using familiar Worker binding syntax
    • Multi-cloud Support: Connect to resources in private networks in any external cloud (AWS, Azure, GCP, etc.) or on-premise using Cloudflare Tunnels
    JavaScript
    export default {
      async fetch(request, env, ctx) {
        // Perform application logic in Workers here
    

        // Sample call to an internal API running on ECS in AWS using the binding
        const response = await env.AWS_VPC_ECS_API.fetch("https://internal-host.example.com");
    

        // Additional application logic in Workers
        return new Response();
      },
    };

    Getting started

    Set up a Cloudflare Tunnel, create a VPC Service, add service bindings to your Worker, and access private resources securely. Refer to the documentation to get started.

  1. Capture Wrangler command output in structured format

    Workers

    You can now capture Wrangler command output in a structured ND-JSON ↗ format by setting the WRANGLER_OUTPUT_FILE_PATH or WRANGLER_OUTPUT_FILE_DIRECTORY environment variables. This feature is particularly useful for CI/CD pipelines and automation tools that need programmatic access to deployment information such as worker names, version IDs, deployment URLs, and error details. Commands that support this feature include wrangler deploy, wrangler versions upload, wrangler versions deploy, and wrangler pages deploy.

  1. Workers WebSocket message size limit increased from 1 MiB to 32 MiB

    Workers Durable Objects Browser Run

    Workers, including those using Durable Objects and Browser Rendering, may now process WebSocket messages up to 32 MiB in size. Previously, this limit was 1 MiB.

    This change allows Workers to handle use cases requiring large message sizes, such as processing Chrome Devtools Protocol messages.

    For more information, please see the Durable Objects startup limits.

  1. Increased Workflows instance and concurrency limits

    Workflows Workers

    We've raised the Cloudflare Workflows account-level limits for all accounts on the Workers paid plan:

    • Instance creation rate increased from 100 workflow instances per 10 seconds to 100 instances per second
    • Concurrency limit increased from 4,500 to 10,000 workflow instances per account

    These increases mean you can create new instances up to 10x faster, and have more workflow instances concurrently executing. To learn more and get started with Workflows, refer to the getting started guide.

    If your application requires a higher limit, fill out the Limit Increase Request Form or contact your account team. Please refer to Workflows pricing for more information.

  1. Access Workers preview URLs from the Build details page

    Workers

    You can now access preview URLs directly from the build details page, making it easier to test your changes when reviewing builds in the dashboard.

    preview button

    What's new

    • A Preview button now appears in the top-right corner of the build details page for successful builds
    • Click it to instantly open the latest preview URL
    • Matches the same experience you're familiar with from Pages

  1. Reranking and API-based system prompt configuration in AI Search

    AI Search

    AI Search now supports reranking for improved retrieval quality and allows you to set the system prompt directly in your API requests.

    Rerank for more relevant results

    You can now enable reranking to reorder retrieved documents based on their semantic relevance to the user’s query. Reranking helps improve accuracy, especially for large or noisy datasets where vector similarity alone may not produce the optimal ordering.

    You can enable and configure reranking in the dashboard or directly in your API requests:

    JavaScript
    const answer = await env.AI.autorag("my-autorag").aiSearch({
      query: "How do I train a llama to deliver coffee?",
      model: "@cf/meta/llama-3.3-70b-instruct-fp8-fast",
      reranking: {
        enabled: true,
        model: "@cf/baai/bge-reranker-base",
      },
    });

    Set system prompts in API

    Previously, system prompts could only be configured in the dashboard. You can now define them directly in your API requests, giving you per-query control over behavior. For example:

    JavaScript
    // Dynamically set query and system prompt in AI Search
    async function getAnswer(query, tone) {
      const systemPrompt = `You are a ${tone} assistant.`;
    

      const response = await env.AI.autorag("my-autorag").aiSearch({
        query: query,
        system_prompt: systemPrompt,
      });
    

      return response;
    }
    

    // Example usage
    const query = "What is Cloudflare?";
    const tone = "friendly";
    

    const answer = await getAnswer(query, tone);
    console.log(answer);

    Learn more about Reranking and System Prompt in AI Search.

  1. Automatic resource provisioning for KV, R2, and D1

    Workers

    Previously, if you wanted to develop or deploy a worker with attached resources, you'd have to first manually create the desired resources. Now, if your Wrangler configuration file includes a KV namespace, D1 database, or R2 bucket that does not yet exist on your account, you can develop locally and deploy your application seamlessly, without having to run additional commands.

    Automatic provisioning is launching as an open beta, and we'd love to hear your feedback to help us make improvements! It currently works for KV, R2, and D1 bindings. You can disable the feature using the --no-x-provision flag.

    To use this feature, update to wrangler@4.45.0 and add bindings to your config file without resource IDs e.g.:

    JSONC
    {
      "kv_namespaces": [{ "binding": "MY_KV" }],
      "d1_databases": [{ "binding": "MY_DB" }],
      "r2_buckets": [{ "binding": "MY_R2" }],
    }

    wrangler dev will then automatically create these resources for you locally, and on your next run of wrangler deploy, Wrangler will call the Cloudflare API to create the requested resources and link them to your Worker.

    Though resource IDs will be automatically written back to your Wrangler config file after resource creation, resources will stay linked across future deploys even without adding the resource IDs to the config file. This is especially useful for shared templates, which now no longer need to include account-specific resource IDs when adding a binding.

  1. Build TanStack Start apps with the Cloudflare Vite plugin

    Workers

    The Cloudflare Vite plugin now supports TanStack Start ↗ apps. Get started with new or existing projects.

    New projects

    Create a new TanStack Start project that uses the Cloudflare Vite plugin via the create-cloudflare CLI:

    npm create cloudflare@latest -- my-tanstack-start-app --framework=tanstack-start

    Existing projects

    Migrate an existing TanStack Start project to use the Cloudflare Vite plugin:

    1. Install @cloudflare/vite-plugin and wrangler
    npm i -D @cloudflare/vite-plugin wrangler
    1. Add the Cloudflare plugin to your Vite config
    vite.config.ts
    import { defineConfig } from "vite";
    import { tanstackStart } from "@tanstack/react-start/plugin/vite";
    import viteReact from "@vitejs/plugin-react";
    import { cloudflare } from "@cloudflare/vite-plugin";
    

    export default defineConfig({
      plugins: [
        cloudflare({ viteEnvironment: { name: "ssr" } }),
        tanstackStart(),
        viteReact(),
      ],
    });
    1. Add your Worker config file
    JSONC
    {
      "$schema": "./node_modules/wrangler/config-schema.json",
      "name": "my-tanstack-start-app",
      // Set this to today's date
      "compatibility_date": "2026-04-29",
      "compatibility_flags": [
        "nodejs_compat"
      ],
      "main": "@tanstack/react-start/server-entry"
    }
    1. Modify the scripts in your package.json
    package.json
    {
      "scripts": {
        "dev": "vite dev",
        "build": "vite build && tsc --noEmit",
        "start": "node .output/server/index.mjs",
        "preview": "vite preview",
        "deploy": "npm run build && wrangler deploy",
        "cf-typegen": "wrangler types"
      }
    }

    See the TanStack Start framework guide for more info.

  1. Workers AI Markdown Conversion: New endpoint to list supported formats

    Workers AI

    Developers can now programmatically retrieve a list of all file formats supported by the Markdown Conversion utility in Workers AI.

    You can use the env.AI binding:

    TypeScript
    await env.AI.toMarkdown().supported()

    Or call the REST API:

    Terminal window
    curl https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/tomarkdown/supported \
      -H 'Authorization: Bearer {API_TOKEN}'

    Both return a list of file formats that users can convert into Markdown:

    [
      {
        "extension": ".pdf",
        "mimeType": "application/pdf",
      },
      {
        "extension": ".jpeg",
        "mimeType": "image/jpeg",
      },
      ...
    ]

    Learn more about our Markdown Conversion utility.

  1. Workers Preview URL default behavior now matches your workers.dev setting

    Workers

    We have updated the default behavior for Cloudflare Workers Preview URLs. Going forward, if a preview URL setting is not explicitly configured during deployment, its default behavior will automatically match the setting of your workers.dev subdomain.

    This change is intended to provide a more intuitive and secure experience by aligning your preview URL's default state with your workers.dev configuration to prevent cases where a preview URL might remain public even after you disabled your workers.dev route.

    What this means for you:

    • If neither setting is configured: both the workers.dev route and the preview URL will default to enabled
    • If your workers.dev route is enabled and you do not explicitly set Preview URLs to enabled or disabled: Preview URLs will default to enabled
    • If your workers.dev route is disabled and you do not explicitly set Preview URLs to enabled or disabled: Preview URLs will default to disabled

    You can override the default setting by explicitly enabling or disabling the preview URL in your Worker's configuration through the API, Dashboard, or Wrangler.

    Wrangler Version Behavior

    The default behavior depends on the version of Wrangler you are using. This new logic applies to the latest version. Here is a summary of the behavior across different versions:

    • Before v4.34.0: Preview URLs defaulted to enabled, regardless of the workers.dev setting.
    • v4.34.0 up to (but not including) v4.44.0: Preview URLs defaulted to disabled, regardless of the workers.dev setting.
    • v4.44.0 or later: Preview URLs now default to matching your workers.dev setting.

    Why we’re making this change

    In July, we introduced preview URLs to Workers, which let you preview code changes before deploying to production. This made disabling your Worker’s workers.dev URL an ambiguous action — the preview URL, served as a subdomain of workers.dev (ex: preview-id-worker-name.account-name.workers.dev) would still be live even if you had disabled your Worker’s workers.dev route. If you misinterpreted what it meant to disable your workers.dev route, you might unintentionally leave preview URLs enabled when you didn’t mean to, and expose them to the public Internet.

    To address this, we made a one-time update to disable preview URLs on existing Workers that had their workers.dev route disabled and changed the default behavior to be disabled for all new deployments where a preview URL setting was not explicitly configured.

    While this change helped secure many customers, it was disruptive for customers who keep their workers.dev route enabled and actively use the preview functionality, as it now required them to explicitly enable preview URLs on every redeployment.This new, more intuitive behavior ensures that your preview URL settings align with your workers.dev configuration by default, providing a more secure and predictable experience.

    Securing access to workers.dev and preview URL endpoints

    To further secure your workers.dev subdomain and preview URL, you can enable Cloudflare Access with a single click in your Worker's settings to limit access to specific users or groups.

  1. View and edit Durable Object data in UI with Data Studio (Beta)

    Durable Objects Workers
    Screenshot of Durable Objects Data Studio

    You can now view and write to each Durable Object's storage using a UI editor on the Cloudflare dashboard. Only Durable Objects using SQLite storage can use Data Studio.

    Go to Durable Objects

    Data Studio unlocks easier data access with Durable Objects for prototyping application data models to debugging production storage usage. Before, querying your Durable Objects data required deploying a Worker.

    To access a Durable Object, you can provide an object's unique name or ID generated by Cloudflare. Data Studio requires you to have at least the Workers Platform Admin role, and all queries are captured with audit logging for your security and compliance needs. Queries executed by Data Studio send requests to your remote, deployed objects and incur normal usage billing.

    To learn more, visit the Data Studio documentation. If you have feedback or suggestions for the new Data Studio, please share your experience on Discord ↗

  1. Worker startup time limit increased to 1 second

    Workers

    You can now upload a Worker that takes up 1 second to parse and execute its global scope. Previously, startup time was limited to 400 ms.

    This allows you to run Workers that import more complex packages and execute more code prior to requests being handled.

    For more information, see the documentation on Workers startup limits.

  1. You can now deploy full-stack apps on Workers using Terraform

    Workers

    You can now upload Workers with static assets (like HTML, CSS, JavaScript, images) with the Cloudflare Terraform provider v5.11.0 ↗, making it even easier to deploy and manage full-stack apps with IaC.

    Previously, you couldn't use Terraform to upload static assets without writing custom scripts to handle generating an asset manifest, calling the Cloudflare API to upload assets in chunks, and handling change detection.

    Now, you simply define the directory where your assets are built, and we handle the rest. Check out the examples for what this looks like in Terraform configuration.

    You can get started today with the Cloudflare Terraform provider (v5.11.0) ↗, using either the existing cloudflare_workers_script resource ↗, or the beta cloudflare_worker_version resource ↗.

    Examples

    With cloudflare_workers_script

    Here's how you can use the existing cloudflare_workers_script ↗ resource to upload your Worker code and assets in one shot.

    resource "cloudflare_workers_script" "my_app" {
      account_id  = var.account_id
      script_name = "my-app"
    

      content_file   = "./dist/worker/index.js"
      content_sha256 = filesha256("./dist/worker/index.js")
      main_module    = "index.js"
    

      # Just point to your assets directory - that's it!
      assets = {
        directory = "./dist/static"
      }
    }

    With cloudflare_worker, cloudflare_worker_version, and cloudflare_workers_deployment

    And here's an example using the beta cloudflare_worker_version ↗ resource, alongside the cloudflare_worker ↗ and cloudflare_workers_deployment ↗ resources:

    # This tracks the existence of your Worker, so that you
    # can upload code and assets separately from tracking Worker state.
    

    resource "cloudflare_worker" "my_app" {
      account_id = var.account_id
      name       = "my-app"
    }
    

    resource "cloudflare_worker_version" "my_app_version" {
      account_id = var.account_id
      worker_id  = cloudflare_worker.my_app.id
    

      # Just point to your assets directory - that's it!
      assets = {
        directory = "./dist/static"
      }
    

      modules = [{
        name         = "index.js"
        content_file = "./dist/worker/index.js"
        content_type = "application/javascript+module"
      }]
    }
    

    resource "cloudflare_workers_deployment" "my_app_deployment" {
      account_id  = var.account_id
      script_name = cloudflare_worker.my_app.name
    

      strategy = "percentage"
      versions = [{
        version_id = cloudflare_worker_version.my_app_version.id
        percentage = 100
      }]
    }

    What's changed

    Under the hood, the Cloudflare Terraform provider now handles the same logic that Wrangler uses for static asset uploads. This includes scanning your assets directory, computing hashes for each file, generating a manifest with file metadata, and calling the Cloudflare API to upload any missing files in chunks. We support large directories with parallel uploads and chunking, and when the asset manifest hash changes, we detect what's changed and trigger an upload for only those changed files.

    Try it out

  1. You can now deploy and manage Workflows in Terraform

    Workers

    You can now create and manage Workflows using Terraform, now supported in the Cloudflare Terraform provider v5.11.0 ↗. Workflows allow you to build durable, multi-step applications -- without needing to worry about retrying failed tasks or managing infrastructure.

    Now, you can deploy and manage Workflows through Terraform using the new cloudflare_workflow resource ↗:

    resource "cloudflare_workflow" "my_workflow" {
      account_id    = var.account_id
      workflow_name = "my-workflow"
      class_name    = "MyWorkflow"
      script_name   = "my-worker"
    }

    Examples

    Here are full examples of how to configure cloudflare_workflow in Terraform, using the existing cloudflare_workers_script resource ↗, and the beta cloudflare_worker_version resource ↗.

    With cloudflare_workflow and cloudflare_workers_script

    resource "cloudflare_workers_script" "workflow_worker" {
      account_id  = var.cloudflare_account_id
      script_name = "my-workflow-worker"
    

      content_file   = "${path.module}/../dist/worker/index.js"
      content_sha256 = filesha256("${path.module}/../dist/worker/index.js")
      main_module    = "index.js"
    }
    

    resource "cloudflare_workflow" "workflow" {
      account_id    = var.cloudflare_account_id
      workflow_name = "my-workflow"
      class_name    = "MyWorkflow"
      script_name   = cloudflare_workers_script.workflow_worker.script_name
    }

    With cloudflare_workflow, and the new beta resources

    You can more granularly control the lifecycle of each Worker resource using the beta cloudflare_worker_version ↗ resource, alongside the cloudflare_worker ↗ and cloudflare_workers_deployment ↗ resources.

    resource "cloudflare_worker" "workflow_worker" {
      account_id = var.cloudflare_account_id
      name       = "my-workflow-worker"
    }
    

    resource "cloudflare_worker_version" "workflow_worker_version" {
      account_id = var.cloudflare_account_id
      worker_id  = cloudflare_worker.workflow_worker.id
    

      main_module         = "index.js"
    

      modules = [{
        name         = "index.js"
        content_file = "${path.module}/../dist/worker/index.js"
        content_type = "application/javascript+module"
      }]
    }
    

    resource "cloudflare_workers_deployment" "workflow_deployment" {
      account_id  = var.cloudflare_account_id
      script_name = cloudflare_worker.workflow_worker.name
    

      strategy = "percentage"
      versions = [{
        version_id = cloudflare_worker_version.workflow_worker_version.id
        percentage = 100
      }]
    }
    

    resource "cloudflare_workflow" "my_workflow" {
      account_id    = var.cloudflare_account_id
      workflow_name = "my-workflow"
      class_name    = "MyWorkflow"
      script_name   = cloudflare_worker.workflow_worker.name
    }

    Try it out

  1. New Overview Page for Cloudflare Workers

    Workers
    Screenshot of the Workers overview page in the Cloudflare dashboard

    Each of your Workers now has a new overview page in the Cloudflare dashboard.

    The goal is to make it easier to understand your Worker without digging through multiple tabs. Think of it as a new home base, a place to get a high-level overview on what's going on.

    It's the first place you land when you open a Worker in the dashboard, and it gives you an immediate view of what’s going on. You can see requests, errors, and CPU time at a glance. You can view and add bindings, and see recent versions of your app, including who published them.

    Navigation is also simpler, with visually distinct tabs at the top of the page. At the bottom right you'll find guided steps for what to do next that are based on the state of your Worker, such as adding a binding or connecting a custom domain.

    We plan to add more here over time. Better insights, more controls, and ways to manage your Worker from one page.

    If you have feedback or suggestions for the new Overview page or your Cloudflare Workers experience in general, we'd love to hear from you. Join the Cloudflare developer community on Discord ↗.

  1. R2 Data Catalog table-level compaction

    R2

    You can now enable compaction for individual Apache Iceberg ↗ tables in R2 Data Catalog, giving you fine-grained control over different workloads.

    Terminal window
    # Enable compaction for a specific table (no token required)
    npx wrangler r2 bucket catalog compaction enable <BUCKET> <NAMESPACE> <TABLE> --target-size 256

    This allows you to:

    • Apply different target file sizes per table
    • Disable compaction for specific tables
    • Optimize based on table-specific access patterns

    Learn more at Manage catalogs.

  1. One-click Cloudflare Access for Workers

    Workers

    You can now enable Cloudflare Access for your workers.dev and Preview URLs in a single click.

    Screenshot of the Enable/Disable Cloudflare Access button on the workers.dev route settings page

    Access allows you to limit access to your Workers to specific users or groups. You can limit access to yourself, your teammates, your organization, or anyone else you specify in your Access policy.

    To enable Cloudflare Access:

    1. In the Cloudflare dashboard, go to the Workers & Pages page.

      Go to Workers & Pages

    2. In Overview, select your Worker.

    3. Go to Settings > Domains & Routes.

    4. For workers.dev or Preview URLs, click Enable Cloudflare Access.

    5. Optionally, to configure the Access application, click Manage Cloudflare Access. There, you can change the email addresses you want to authorize. View Access policies to learn about configuring alternate rules.

    To fully secure your application, it is important that you validate the JWT that Cloudflare Access adds to the Cf-Access-Jwt-Assertion header on the incoming request.

    The following code will validate the JWT using the jose NPM package ↗:

    JavaScript
    import { jwtVerify, createRemoteJWKSet } from "jose";
    

    export default {
      async fetch(request, env, ctx) {
        // Verify the POLICY_AUD environment variable is set
        if (!env.POLICY_AUD) {
          return new Response("Missing required audience", {
            status: 403,
            headers: { "Content-Type": "text/plain" },
          });
        }
    

        // Get the JWT from the request headers
        const token = request.headers.get("cf-access-jwt-assertion");
    

        // Check if token exists
        if (!token) {
          return new Response("Missing required CF Access JWT", {
            status: 403,
            headers: { "Content-Type": "text/plain" },
          });
        }
    

        try {
          // Create JWKS from your team domain
          const JWKS = createRemoteJWKSet(
            new URL(`${env.TEAM_DOMAIN}/cdn-cgi/access/certs`),
          );
    

          // Verify the JWT
          const { payload } = await jwtVerify(token, JWKS, {
            issuer: env.TEAM_DOMAIN,
            audience: env.POLICY_AUD,
          });
    

          // Token is valid, proceed with your application logic
          return new Response(`Hello ${payload.email || "authenticated user"}!`, {
            headers: { "Content-Type": "text/plain" },
          });
        } catch (error) {
          // Token verification failed
          return new Response(`Invalid token: ${error.message}`, {
            status: 403,
            headers: { "Content-Type": "text/plain" },
          });
        }
      },
    };

    Required environment variables

    Add these environment variables to your Worker:

    • POLICY_AUD: Your application's AUD tag
    • TEAM_DOMAIN: https://<your-team-name>.cloudflareaccess.com

    Both of these appear in the modal that appears when you enable Cloudflare Access.

    You can set these variables by adding them to your Worker's Wrangler configuration file, or via the Cloudflare dashboard under Workers & Pages > your-worker > Settings > Environment Variables.

  1. New Deepgram Flux model available on Workers AI

    Workers AI

    Deepgram's newest Flux model @cf/deepgram/flux is now available on Workers AI, hosted directly on Cloudflare's infrastructure. We're excited to be a launch partner with Deepgram and offer their new Speech Recognition model built specifically for enabling voice agents. Check out Deepgram's blog ↗ for more details on the release.

    The Flux model can be used in conjunction with Deepgram's speech-to-text model @cf/deepgram/nova-3 and text-to-speech model @cf/deepgram/aura-1 to build end-to-end voice agents. Having Deepgram on Workers AI takes advantage of our edge GPU infrastructure, for ultra low latency voice AI applications.

    Promotional Pricing

    For the month of October 2025, Deepgram's Flux model will be free to use on Workers AI. Official pricing will be announced soon and charged after the promotional pricing period ends on October 31, 2025. Check out the model page for pricing details in the future.

    Example Usage

    The new Flux model is WebSocket only as it requires live bi-directional streaming in order to recognize speech activity.

    1. Create a worker that establishes a websocket connection with @cf/deepgram/flux
    JavaScript
    export default {
      async fetch(request, env, ctx): Promise<Response> {
        const resp = await env.AI.run("@cf/deepgram/flux", {
          encoding: "linear16",
          sample_rate: "16000"
        }, {
          websocket: true
        });
        return resp;
      },
    } satisfies ExportedHandler<Env>;
    1. Deploy your worker
    Terminal window
    npx wrangler deploy
    1. Write a client script to connect to your worker and start sending random audio bytes to it
    JavaScript
    const ws = new WebSocket('wss://<your-worker-url.com>');
    

    ws.onopen = () => {
      console.log('Connected to WebSocket');
    

      // Generate and send random audio bytes
      // You can replace this part with a function
      // that reads from your mic or other audio source
      const audioData = generateRandomAudio();
      ws.send(audioData);
      console.log('Audio data sent');
    };
    

    ws.onmessage = (event) => {
      // Transcription will be received here
      // Add your custom logic to parse the data
      console.log('Received:', event.data);
    };
    

    ws.onerror = (error) => {
      console.error('WebSocket error:', error);
    };
    

    ws.onclose = () => {
      console.log('WebSocket closed');
    };
    

    // Generate random audio data (1 second of noise at 44.1kHz, mono)
    function generateRandomAudio() {
      const sampleRate = 44100;
      const duration = 1;
      const numSamples = sampleRate * duration;
      const buffer = new ArrayBuffer(numSamples * 2);
      const view = new Int16Array(buffer);
    

      for (let i = 0; i < numSamples; i++) {
        view[i] = Math.floor(Math.random() * 65536 - 32768);
      }
    

      return buffer;
    }

  1. Workers Analytics Engine adds supports for new SQL functions

    Workers Analytics Engine Workers

    You can now perform more powerful queries directly in Workers Analytics Engine ↗ with a major expansion of our SQL function library.

    Workers Analytics Engine allows you to ingest and store high-cardinality data at scale (such as custom analytics) and query your data through a simple SQL API.

    Today, we've expanded Workers Analytics Engine's SQL capabilities with several new functions:

    New aggregate functions: ↗

    • argMin() - Returns the value associated with the minimum in a group
    • argMax() - Returns the value associated with the maximum in a group
    • topK() - Returns an array of the most frequent values in a group
    • topKWeighted() - Returns an array of the most frequent values in a group using weights
    • first_value() - Returns the first value in an ordered set of values within a partition
    • last_value() - Returns the last value in an ordered set of values within a partition

    New bit functions: ↗

    • bitAnd() - Returns the bitwise AND of two expressions
    • bitCount() - Returns the number of bits set to one in the binary representation of a number
    • bitHammingDistance() - Returns the number of bits that differ between two numbers
    • bitNot() - Returns a number with all bits flipped
    • bitOr() - Returns the inclusive bitwise OR of two expressions
    • bitRotateLeft() - Rotates all bits in a number left by specified positions
    • bitRotateRight() - Rotates all bits in a number right by specified positions
    • bitShiftLeft() - Shifts all bits in a number left by specified positions
    • bitShiftRight() - Shifts all bits in a number right by specified positions
    • bitTest() - Returns the value of a specific bit in a number
    • bitXor() - Returns the bitwise exclusive-or of two expressions

    New mathematical functions: ↗

    • abs() - Returns the absolute value of a number
    • log() - Computes the natural logarithm of a number
    • round() - Rounds a number to a specified number of decimal places
    • ceil() - Rounds a number up to the nearest integer
    • floor() - Rounds a number down to the nearest integer
    • pow() - Returns a number raised to the power of another number

    New string functions: ↗

    • lowerUTF8() - Converts a string to lowercase using UTF-8 encoding
    • upperUTF8() - Converts a string to uppercase using UTF-8 encoding

    New encoding functions: ↗

    • hex() - Converts a number to its hexadecimal representation
    • bin() - Converts a string to its binary representation

    New type conversion functions: ↗

    • toUInt8() - Converts any numeric expression, or expression resulting in a string representation of a decimal, into an unsigned 8 bit integer

    Ready to get started?

    Whether you're building usage-based billing systems, customer analytics dashboards, or other custom analytics, these functions let you get the most out of your data. Get started with Workers Analytics Engine and explore all available functions in our SQL reference documentation.

  1. Larger Container instance types

    Containers

    New instance types provide up to 4 vCPU, 12 GiB of memory, and 20 GB of disk per container instance.

    Instance TypevCPUMemoryDisk
    lite1/16256 MiB2 GB
    basic1/41 GiB4 GB
    standard-11/24 GiB8 GB
    standard-216 GiB12 GB
    standard-328 GiB16 GB
    standard-4412 GiB20 GB

    The dev and standard instance types are preserved for backward compatibility and are aliases for lite and standard-1, respectively. The standard-1 instance type now provides up to 8 GB of disk instead of only 4 GB.

    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. Automatic loopback bindings via ctx.exports

    Workers

    The ctx.exports API contains automatically-configured bindings corresponding to your Worker's top-level exports. For each top-level export extending WorkerEntrypoint, ctx.exports will contain a Service Binding by the same name, and for each export extending DurableObject (and for which storage has been configured via a migration), ctx.exports will contain a Durable Object namespace binding. This means you no longer have to configure these bindings explicitly in wrangler.jsonc/wrangler.toml.

    Example:

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

    export class Greeter extends WorkerEntrypoint {
      greet(name) {
        return `Hello, ${name}!`;
      }
    }
    

    export default {
      async fetch(request, env, ctx) {
        let greeting = await ctx.exports.Greeter.greet("World")
        return new Response(greeting);
      }
    }

    At present, you must use the enable_ctx_exports compatibility flag to enable this API, though it will be on by default in the future.

    See the API reference for more information.

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

Search all changelog entries