Skip to content
Cloudflare Docs

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS
View all RSS feeds

hero image

  1. Hyperdrive Free plan makes fast, global database access available to all

    Hyperdrive

    Hyperdrive is now available on the Free plan of Cloudflare Workers, enabling you to build Workers that connect to PostgreSQL or MySQL databases without compromise.

    Low-latency access to SQL databases is critical to building full-stack Workers applications. We want you to be able to build on fast, global apps on Workers, regardless of the tools you use. So we made Hyperdrive available for all, to make it easier to build Workers that connect to PostgreSQL and MySQL.

    If you want to learn more about how Hyperdrive works, read the deep dive ↗ on how Hyperdrive can make your database queries up to 4x faster.

    Hyperdrive provides edge connection setup and global connection pooling for optimal latencies.

    Visit the docs to get started with Hyperdrive for PostgreSQL or MySQL.

  1. Full-stack frameworks are now Generally Available on Cloudflare Workers

    Workers Workers for Platforms

    Full-stack on Cloudflare Workers

    The following full-stack frameworks now have Generally Available ("GA") adapters for Cloudflare Workers, and are ready for you to use in production:

    The following frameworks are now in beta, with GA support coming very soon:

    You can also build complete full-stack apps on Workers without a framework:

    Get started building today with our framework guides, or read our Developer Week 2025 blog post ↗ about all the updates to building full-stack applications on Workers.

  1. The Cloudflare Vite plugin is now Generally Available

    Workers

    The Cloudflare Vite plugin has reached v1.0 ↗ and is now Generally Available ("GA").

    When you use @cloudflare/vite-plugin, you can use Vite's local development server and build tooling, while ensuring that while developing, your code runs in workerd ↗, the open-source Workers runtime.

    This lets you get the best of both worlds for a full-stack app — you can use Hot Module Replacement ↗ from Vite right alongside Durable Objects and other runtime APIs and bindings that are unique to Cloudflare Workers.

    @cloudflare/vite-plugin is made possible by the new environment API ↗ in Vite, and was built in partnership with the Vite team ↗.

    Framework support

    You can build any type of application with @cloudflare/vite-plugin, using any rendering mode, from single page applications (SPA) and static sites to server-side rendered (SSR) pages and API routes.

    React Router v7 (Remix) is the first full-stack framework to provide full support for Cloudflare Vite plugin, allowing you to use all parts of Cloudflare's developer platform, without additional build steps.

    You can also build complete full-stack apps on Workers without a framework — "just use Vite" ↗ and React together, and build a back-end API in the same Worker. Follow our React SPA with an API tutorial to learn how.

    Configuration

    If you're already using Vite ↗ in your build and development toolchain, you can start using our plugin with minimal changes to your vite.config.ts:

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

    export default defineConfig({
      plugins: [cloudflare()],
    });

    Take a look at the documentation for our Cloudflare Vite plugin for more information!

  1. Local development support for Email Workers

    Email Routing

    Email Workers enables developers to programmatically take action on anything that hits their email inbox. If you're building with Email Workers, you can now test the behavior of an Email Worker script, receiving, replying and sending emails in your local environment using wrangler dev.

    Below is an example that shows you how you can receive messages using the email() handler and parse them using postal-mime ↗:

    import * as PostalMime from 'postal-mime';
    

    export default {
      async email(message, env, ctx) {
        const parser = new PostalMime.default();
        const rawEmail = new Response(message.raw);
        const email = await parser.parse(await rawEmail.arrayBuffer());
        console.log(email);
      },
    };

    Now when you run npx wrangler dev, wrangler will expose a local /cdn-cgi/handler/email endpoint that you can POST email messages to and trigger your Worker's email() handler:

    Terminal window
    curl -X POST 'http://localhost:8787/cdn-cgi/handler/email' \
      --url-query 'from=sender@example.com' \
      --url-query 'to=recipient@example.com' \
      --header 'Content-Type: application/json' \
      --data-raw 'Received: from smtp.example.com (127.0.0.1)
            by cloudflare-email.com (unknown) id 4fwwffRXOpyR
            for <recipient@example.com>; Tue, 27 Aug 2024 15:50:20 +0000
    From: "John" <sender@example.com>
    Reply-To: sender@example.com
    To: recipient@example.com
    Subject: Testing Email Workers Local Dev
    Content-Type: text/html; charset="windows-1252"
    X-Mailer: Curl
    Date: Tue, 27 Aug 2024 08:49:44 -0700
    Message-ID: <6114391943504294873000@ZSH-GHOSTTY>
    

    Hi there'

    This is what you get in the console:

    {
      headers: [
        {
          key: 'received',
          value: 'from smtp.example.com (127.0.0.1) by cloudflare-email.com (unknown) id 4fwwffRXOpyR for <recipient@example.com>; Tue, 27 Aug 2024 15:50:20 +0000'
        },
        { key: 'from', value: '"John" <sender@example.com>' },
        { key: 'reply-to', value: 'sender@example.com' },
        { key: 'to', value: 'recipient@example.com' },
        { key: 'subject', value: 'Testing Email Workers Local Dev' },
        { key: 'content-type', value: 'text/html; charset="windows-1252"' },
        { key: 'x-mailer', value: 'Curl' },
        { key: 'date', value: 'Tue, 27 Aug 2024 08:49:44 -0700' },
        {
          key: 'message-id',
          value: '<6114391943504294873000@ZSH-GHOSTTY>'
        }
      ],
      from: { address: 'sender@example.com', name: 'John' },
      to: [ { address: 'recipient@example.com', name: '' } ],
      replyTo: [ { address: 'sender@example.com', name: '' } ],
      subject: 'Testing Email Workers Local Dev',
      messageId: '<6114391943504294873000@ZSH-GHOSTTY>',
      date: '2024-08-27T15:49:44.000Z',
      html: 'Hi there\n',
      attachments: []
    }

    Local development is a critical part of the development flow, and also works for sending, replying and forwarding emails. See our documentation for more information.

  1. Hyperdrive introduces support for MySQL and MySQL-compatible databases

    Hyperdrive

    Hyperdrive now supports connecting to MySQL and MySQL-compatible databases, including Amazon RDS and Aurora MySQL, Google Cloud SQL for MySQL, Azure Database for MySQL, PlanetScale and MariaDB.

    Hyperdrive makes your regional, MySQL databases fast when connecting from Cloudflare Workers. It eliminates unnecessary network roundtrips during connection setup, pools database connections globally, and can cache query results to provide the fastest possible response times.

    Best of all, you can connect using your existing drivers, ORMs, and query builders with Hyperdrive's secure credentials, no code changes required.

    import { createConnection } from "mysql2/promise";
    

    export interface Env {
      HYPERDRIVE: Hyperdrive;
    }
    

    export default {
      async fetch(request, env, ctx): Promise<Response> {
        const connection = await createConnection({
          host: env.HYPERDRIVE.host,
          user: env.HYPERDRIVE.user,
          password: env.HYPERDRIVE.password,
          database: env.HYPERDRIVE.database,
          port: env.HYPERDRIVE.port,
          disableEval: true, // Required for Workers compatibility
        });
    

        const [results, fields] = await connection.query("SHOW tables;");
    

        ctx.waitUntil(connection.end());
    

        return new Response(JSON.stringify({ results, fields }), {
          headers: {
            "Content-Type": "application/json",
            "Access-Control-Allow-Origin": "*",
          },
        });
      },
    } satisfies ExportedHandler<Env>;

    Learn more about how Hyperdrive works and get started building Workers that connect to MySQL with Hyperdrive.

  1. Improved support for Node.js Crypto and TLS APIs in Workers

    Workers

    When using a Worker with the nodejs_compat compatibility flag enabled, the following Node.js APIs are now available:

    This make it easier to reuse existing Node.js code in Workers or use npm packages that depend on these APIs.

    node:crypto

    The full node:crypto ↗ API is now available in Workers.

    You can use it to verify and sign data:

    import { sign, verify } from "node:crypto";
    

    const signature = sign("sha256", "-data to sign-", env.PRIVATE_KEY);
    const verified = verify("sha256", "-data to sign-", env.PUBLIC_KEY, signature);

    Or, to encrypt and decrypt data:

    import { publicEncrypt, privateDecrypt } from "node:crypto";
    

    const encrypted = publicEncrypt(env.PUBLIC_KEY, "some data");
    const plaintext = privateDecrypt(env.PRIVATE_KEY, encrypted);

    See the node:crypto documentation for more information.

    node:tls

    The following APIs from node:tls are now available:

    This enables secure connections over TLS (Transport Layer Security) to external services.

    import { connect } from "node:tls";
    

    // ... in a request handler ...
    const connectionOptions = { key: env.KEY, cert: env.CERT };
    const socket = connect(url, connectionOptions, () => {
      if (socket.authorized) {
        console.log("Connection authorized");
      }
    });
    

    socket.on("data", (data) => {
      console.log(data);
    });
    

    socket.on("end", () => {
      console.log("server ends connection");
    });

    See the node:tls documentation for more information.

  1. Deploy a Workers application in seconds with one-click

    Workers

    You can now add a Deploy to Cloudflare button to the README of your Git repository containing a Workers application — making it simple for other developers to quickly set up and deploy your project!

    Deploy to Cloudflare

    The Deploy to Cloudflare button:

    1. Creates a new Git repository on your GitHub/ GitLab account: Cloudflare will automatically clone and create a new repository on your account, so you can continue developing.
    2. Automatically provisions resources the app needs: If your repository requires Cloudflare primitives like a Workers KV namespace, a D1 database, or an R2 bucket, Cloudflare will automatically provision them on your account and bind them to your Worker upon deployment.
    3. Configures Workers Builds (CI/CD): Every new push to your production branch on your newly created repository will automatically build and deploy courtesy of Workers Builds.
    4. Adds preview URLs to each pull request: If you'd like to test your changes before deploying, you can push changes to a non-production branch and preview URLs will be generated and posted back to GitHub as a comment.
    Import repo or choose template

    To create a Deploy to Cloudflare button in your README, you can add the following snippet, including your Git repository URL:

    [![Deploy to Cloudflare](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=<YOUR_GIT_REPO_URL>)

    Check out our documentation for more information on how to set up a deploy button for your application and best practices to ensure a successful deployment for other developers.

  1. Build MCP servers with the Agents SDK

    Agents Workers

    The Agents SDK now includes built-in support for building remote MCP (Model Context Protocol) servers directly as part of your Agent. This allows you to easily create and manage MCP servers, without the need for additional infrastructure or configuration.

    The SDK includes a new MCPAgent class that extends the Agent class and allows you to expose resources and tools over the MCP protocol, as well as authorization and authentication to enable remote MCP servers.

    export class MyMCP extends McpAgent {
      server = new McpServer({
        name: "Demo",
        version: "1.0.0",
      });
    

      async init() {
        this.server.resource(`counter`, `mcp://resource/counter`, (uri) => {
          // ...
        });
    

        this.server.tool(
          "add",
          "Add two numbers together",
          { a: z.number(), b: z.number() },
          async ({ a, b }) => {
            // ...
          },
        );
      }
    }

    See the example ↗ for the full code and as the basis for building your own MCP servers, and the client example ↗ for how to build an Agent that acts as an MCP client.

    To learn more, review the announcement blog ↗ as part of Developer Week 2025.

    Agents SDK updates

    We've made a number of improvements to the Agents SDK, including:

    • Support for building MCP servers with the new MCPAgent class.
    • The ability to export the current agent, request and WebSocket connection context using import { context } from "agents", allowing you to minimize or avoid direct dependency injection when calling tools.
    • Fixed a bug that prevented query parameters from being sent to the Agent server from the useAgent React hook.
    • Automatically converting the agent name in useAgent or useAgentChat to kebab-case to ensure it matches the naming convention expected by routeAgentRequest.

    To install or update the Agents SDK, run npm i agents@latest in an existing project, or explore the agents-starter project:

    Terminal window
    npm create cloudflare@latest -- --template cloudflare/agents-starter

    See the full release notes and changelog on the Agents SDK repository ↗ and

  1. Workflows is now Generally Available

    Workflows Workers

    Workflows is now Generally Available (or "GA"): in short, it's ready for production workloads. Alongside marking Workflows as GA, we've introduced a number of changes during the beta period, including:

    • A new waitForEvent API that allows a Workflow to wait for an event to occur before continuing execution.
    • Increased concurrency: you can run up to 4,500 Workflow instances concurrently — and this will continue to grow.
    • Improved observability, including new CPU time metrics that allow you to better understand which Workflow instances are consuming the most resources and/or contributing to your bill.
    • Support for vitest for testing Workflows locally and in CI/CD pipelines.

    Workflows also supports the new increased CPU limits that apply to Workers, allowing you to run more CPU-intensive tasks (up to 5 minutes of CPU time per instance), not including the time spent waiting on network calls, AI models, or other I/O bound tasks.

    Human-in-the-loop

    The new step.waitForEvent API allows a Workflow instance to wait on events and data, enabling human-in-the-the-loop interactions, such as approving or rejecting a request, directly handling webhooks from other systems, or pushing event data to a Workflow while it's running.

    Because Workflows are just code, you can conditionally execute code based on the result of a waitForEvent call, and/or call waitForEvent multiple times in a single Workflow based on what the Workflow needs.

    For example, if you wanted to implement a human-in-the-loop approval process, you could use waitForEvent to wait for a user to approve or reject a request, and then conditionally execute code based on the result.

    import { Workflow, WorkflowEvent } from "cloudflare:workflows";
    

    export class MyWorkflow extends WorkflowEntrypoint {
      async run(event, step) {
        // Other steps in your Workflow
        let event = await step.waitForEvent(
          "receive invoice paid webhook from Stripe",
          { type: "stripe-webhook", timeout: "1 hour" },
        );
        // Rest of your Workflow
      }
    }

    You can then send a Workflow an event from an external service via HTTP or from within a Worker using the Workers API for Workflows:

    export default {
      async fetch(req, env) {
        const instanceId = new URL(req.url).searchParams.get("instanceId");
        const webhookPayload = await req.json();
    

        let instance = await env.MY_WORKFLOW.get(instanceId);
        // Send our event, with `type` matching the event type defined in
        // our step.waitForEvent call
        await instance.sendEvent({
          type: "stripe-webhook",
          payload: webhookPayload,
        });
    

        return Response.json({
          status: await instance.status(),
        });
      },
    };

    Read the GA announcement blog ↗ to learn more about what landed as part of the Workflows GA.

  1. Create fully-managed RAG pipelines for your AI applications with AutoRAG

    AutoRAG Vectorize

    AutoRAG is now in open beta, making it easy for you to build fully-managed retrieval-augmented generation (RAG) pipelines without managing infrasturcture. Just upload your docs to R2, and AutoRAG handles the rest: embeddings, indexing, retrieval, and response generation via API.

    AutoRAG open beta demo

    With AutoRAG, you can:

    • Customize your pipeline: Choose from Workers AI models, configure chunking strategies, edit system prompts, and more.
    • Instant setup: AutoRAG provisions everything you need from Vectorize, AI gateway, to pipeline logic for you, so you can go from zero to a working RAG pipeline in seconds.
    • Keep your index fresh: AutoRAG continuously syncs your index with your data source to ensure responses stay accurate and up to date.
    • Ask questions: Query your data and receive grounded responses via a Workers binding or API.

    Whether you're building internal tools, AI-powered search, or a support assistant, AutoRAG gets you from idea to deployment in minutes.

    Get started in the Cloudflare dashboard ↗ or check out the guide for instructions on how to build your RAG pipeline today.