Skip to content
Cloudflare Docs
Docs DirectoryAPIsSDKs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Workers
hero image

  1. Billing for SQLite Storage

    Durable Objects Workers

    Storage billing for SQLite-backed Durable Objects will be enabled in January 2026, with a target date of January 7, 2026 (no earlier).

    To view your SQLite storage usage, go to the Durable Objects page

    Go to Durable Objects

    If you do not want to incur costs, please take action such as optimizing queries or deleting unnecessary stored data in order to reduce your SQLite storage usage ahead of the January 7th target. Only usage on and after the billing target date will incur charges.

    Developers on the Workers Paid plan with Durable Object's SQLite storage usage beyond included limits will incur charges according to SQLite storage pricing announced in September 2024 with the public beta ↗. Developers on the Workers Free plan will not be charged.

    Compute billing for SQLite-backed Durable Objects has been enabled since the initial public beta. SQLite-backed Durable Objects currently incur charges for requests and duration, and no changes are being made to compute billing.

    For more information about SQLite storage pricing and limits, refer to the Durable Objects pricing documentation.

  1. Python cold start improvements

    Workers

    Python Workers now feature improved cold start performance, reducing initialization time for new Worker instances. This improvement is particularly noticeable for Workers with larger dependency sets or complex initialization logic.

    Every time you deploy a Python Worker, a memory snapshot is captured after the top level of the Worker is executed. This snapshot captures all imports, including package imports that are often costly to load. The memory snapshot is loaded when the Worker is first started, avoiding the need to reload the Python runtime and all dependencies on each cold start.

    We set up a benchmark that imports common packages (httpx ↗, fastapi ↗ and pydantic ↗) to see how Python Workers stack up against other platforms:

    PlatformMean Cold Start (ms)
    Cloudflare Python Workers1027
    AWS Lambda2502
    Google Cloud Run3069

    These benchmarks run continuously. You can view the results and the methodology on our benchmark page ↗.

    In additional testing, we have found that without any memory snapshot, the cold start for this benchmark takes around 10 seconds, so this change improves cold start performance by roughly a factor of 10.

    To get started with Python Workers, check out our Python Workers overview.

  1. Easy Python package management with Pywrangler

    Workers

    We are introducing a brand new tool called Pywrangler, which simplifies package management in Python Workers by automatically installing Workers-compatible Python packages into your project.

    With Pywrangler, you specify your Worker's Python dependencies in your pyproject.toml file:

    TOML
    [project]
    name = "python-beautifulsoup-worker"
    version = "0.1.0"
    description = "A simple Worker using beautifulsoup4"
    requires-python = ">=3.12"
    dependencies = [
        "beautifulsoup4"
    ]
    

    [dependency-groups]
    dev = [
      "workers-py",
      "workers-runtime-sdk"
    ]

    You can then develop and deploy your Worker using the following commands:

    Terminal window
    uv run pywrangler dev
    uv run pywrangler deploy

    Pywrangler automatically downloads and vendors the necessary packages for your Worker, and these packages are bundled with the Worker when you deploy.

    Consult the Python packages documentation for full details on Pywrangler and Python package management in Workers.

  1. Wrangler config is optional when using Vite plugin

    Workers

    When using the Cloudflare Vite plugin to build and deploy Workers, a Wrangler configuration file is now optional for assets-only (static) sites. If no wrangler.toml, wrangler.json, or wrangler.jsonc file is found, the plugin generates sensible defaults for an assets-only site. The name is based on the package.json or the project directory name, and the compatibility_date uses the latest date supported by your installed Miniflare version.

    This allows easier setup for static sites using Vite. Note that SPAs will still need to set assets.not_found_handling to single-page-application ↗ in order to function correctly.

  1. Configure Workers programmatically using the Vite plugin

    Workers

    The Cloudflare Vite plugin now supports programmatic configuration of Workers without a Wrangler configuration file. You can use the config option to define Worker settings directly in your Vite configuration, or to modify existing configuration loaded from a Wrangler config file. This is particularly useful when integrating with other build tools or frameworks, as it allows them to control Worker configuration without needing users to manage a separate config file.

    The config option

    The Vite plugin's new config option accepts either a partial configuration object or a function that receives the current configuration and returns overrides. This option is applied after any config file is loaded, allowing the plugin to override specific values or define Worker configuration entirely in code.

    Example usage

    Setting config to an object to provide configuration values that merge with defaults and config file settings:

    vite.config.ts
    import { defineConfig } from "vite";
    import { cloudflare } from "@cloudflare/vite-plugin";
    

    export default defineConfig({
      plugins: [
        cloudflare({
          config: {
            name: "my-worker",
            compatibility_flags: ["nodejs_compat"],
            send_email: [
              {
                name: "EMAIL",
              },
            ],
          },
        }),
      ],
    });

    Use a function to modify the existing configuration:

    vite.config.ts
    import { defineConfig } from "vite";
    import { cloudflare } from "@cloudflare/vite-plugin";
    export default defineConfig({
      plugins: [
        cloudflare({
          config: (userConfig) => {
            delete userConfig.compatibility_flags;
          },
        }),
      ],
    });

    Return an object with values to merge:

    vite.config.ts
    import { defineConfig } from "vite";
    import { cloudflare } from "@cloudflare/vite-plugin";
    

    export default defineConfig({
      plugins: [
        cloudflare({
          config: (userConfig) => {
            if (!userConfig.compatibility_flags.includes("no_nodejs_compat")) {
              return { compatibility_flags: ["nodejs_compat"] };
            }
          },
        }),
      ],
    });

    Auxiliary Workers

    Auxiliary Workers also support the config option, enabling multi-Worker architectures without config files.

    Define auxiliary Workers without config files using config inside the auxiliaryWorkers array:

    vite.config.ts
    import { defineConfig } from "vite";
    import { cloudflare } from "@cloudflare/vite-plugin";
    

    export default defineConfig({
      plugins: [
        cloudflare({
          config: {
            name: "entry-worker",
            main: "./src/entry.ts",
            services: [{ binding: "API", service: "api-worker" }],
          },
          auxiliaryWorkers: [
            {
              config: {
                name: "api-worker",
                main: "./src/api.ts",
              },
            },
          ],
        }),
      ],
    });

    For more details and examples, see Programmatic configuration.

  1. One-click Access protection for Workers now creates reusable Cloudflare Access policies

    Workers

    Workers applications now use reusable Cloudflare Access policies to reduce duplication and simplify access management across multiple Workers.

    Previously, enabling Cloudflare Access on a Worker created per-application policies, unique to each application. Now, we create reusable policies that can be shared across applications:

    • Preview URLs: All Workers preview URLs share a single "Cloudflare Workers Preview URLs" policy across your account. This policy is automatically created the first time you enable Access on any preview URL. By sharing a single policy across all preview URLs, you can configure access rules once and have them apply company-wide to all Workers which protect preview URLs. This makes it much easier to manage who can access preview environments without having to update individual policies for each Worker.

    • Production workers.dev URLs: When enabled, each Worker gets its own reusable policy (named <worker-name> - Production) by default. We recognize production services often have different access requirements and having individual policies here makes it easier to configure service-to-service authentication or protect internal dashboards or applications with specific user groups. Keeping these policies separate gives you the flexibility to configure exactly the right access rules for each production service. When you disable Access on a production Worker, the associated policy is automatically cleaned up if it's not being used by other applications.

    This change reduces policy duplication, simplifies cross-company access management for preview environments, and provides the flexibility needed for production services. You can still customize access rules by editing the reusable policies in the Zero Trust dashboard.

    To enable Cloudflare Access on your Worker:

    1. In the Cloudflare dashboard, go to Workers & Pages.
    2. Select your Worker.
    3. Go to Settings > Domains & Routes.
    4. For workers.dev or Preview URLs, click Enable Cloudflare Access.
    5. Optionally, click Manage Cloudflare Access to customize the policy.

    For more information on configuring Cloudflare Access for Workers, refer to the Workers Access documentation.

  1. Agents SDK v0.2.24 with resumable streaming, MCP improvements, and schedule fixes

    Agents Workers

    The latest release of @cloudflare/agents ↗ brings resumable streaming, significant MCP client improvements, and critical fixes for schedules and Durable Object lifecycle management.

    Resumable streaming

    AIChatAgent now supports resumable streaming, allowing clients to reconnect and continue receiving streamed responses without losing data. This is useful for:

    • Long-running AI responses
    • Users on unreliable networks
    • Users switching between devices mid-conversation
    • Background tasks where users navigate away and return
    • Real-time collaboration where multiple clients need to stay in sync

    Streams are maintained across page refreshes, broken connections, and syncing across open tabs and devices.

    Other improvements

    • Default JSON schema validator added to MCP client
    • Schedules ↗ can now safely destroy the agent

    MCP client API improvements

    The MCPClientManager API has been redesigned for better clarity and control:

    • New registerServer() method: Register MCP servers without immediately connecting
    • New connectToServer() method: Establish connections to registered servers
    • Improved reconnect logic: restoreConnectionsFromStorage() now properly handles failed connections
    TypeScript
    // Register a server to Agent
    const { id } = await this.mcp.registerServer({
      name: "my-server",
      url: "https://my-mcp-server.example.com",
    });
    

    // Connect when ready
    await this.mcp.connectToServer(id);
    

    // Discover tools, prompts and resources
    await this.mcp.discoverIfConnected(id);

    The SDK now includes a formalized MCPConnectionState enum with states: idle, connecting, authenticating, connected, discovering, and ready.

    Enhanced MCP discovery

    MCP discovery fetches the available tools, prompts, and resources from an MCP server so your agent knows what capabilities are available. The MCPClientConnection class now includes a dedicated discover() method with improved reliability:

    • Supports cancellation via AbortController
    • Configurable timeout (default 15s)
    • Discovery failures now throw errors immediately instead of silently continuing

    Bug fixes

    • Fixed a bug where schedules ↗ meant to fire immediately with this.schedule(0, ...) or this.schedule(new Date(), ...) would not fire
    • Fixed an issue where schedules that took longer than 30 seconds would occasionally time out
    • Fixed SSE transport now properly forwards session IDs and request headers
    • Fixed AI SDK stream events conversion to UIMessageStreamPart

    Upgrade

    To update to the latest version:

    Terminal window
    npm i agents@latest

  1. Environment variable limits increase for Workers Builds

    Workers

    Workers Builds now supports up to 64 environment variables, and each environment variable can be up to 5 KB in size. The previous limit was 5 KB total across all environment variables.

    This change enables better support for complex build configurations, larger application settings, and more flexible CI/CD workflows.

    For more details, refer to the build limits documentation.

  1. Better local deployment flow for Cloudflare Workers

    Workers

    Until now, if a Worker had been previously deployed via the Cloudflare Dashboard ↗, a subsequent deployment done via the Cloudflare Workers CLI, Wrangler (through the deploy command), would allow the user to override the Worker's dashboard settings without providing details on what dashboard settings would be lost.

    Now instead, wrangler deploy presents a helpful representation of the differences between the local configuration and the remote dashboard settings, and offers to update your local configuration file for you.

    See example below showing a before and after for wrangler deploy when a local configuration is expected to override a Worker's dashboard settings:

    Before

    wrangler deploy run before the improved workflow

    After

    wrangler deploy run after the improved workflow

    Also, if instead Wrangler detects that a deployment would override remote dashboard settings but in an additive way, without modifying or removing any of them, it will simply proceed with the deployment without requesting any user interaction.

    Update to Wrangler v4.50.0 or greater to take advantage of this improved deploy flow.

  1. More SQL aggregate, date and time functions available in Workers Analytics Engine

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

    • countIf() - count the number of rows which satisfy a provided condition
    • sumIf() - calculate a sum from rows which satisfy a provided condition
    • avgIf() - calculate an average from rows which satisfy a provided condition

    New date and time functions: ↗

    • toYear()
    • toMonth()
    • toDayOfMonth()
    • toDayOfWeek()
    • toHour()
    • toMinute()
    • toSecond()
    • toStartOfYear()
    • toStartOfMonth()
    • toStartOfWeek()
    • toStartOfDay()
    • toStartOfHour()
    • toStartOfFifteenMinutes()
    • toStartOfTenMinutes()
    • toStartOfFiveMinutes()
    • toStartOfMinute()
    • today()
    • toYYYYMM()

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

Search all changelog entries