--- title: Workers Changelog image: https://edgetunnel-b2h.pages.dev/cf-twitter-card.png --- > Documentation Index > Fetch the complete documentation index at: https://edgetunnel-b2h.pages.dev/changelog/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Changelog New updates and improvements at Cloudflare. [ Subscribe to RSS ](https://edgetunnel-b2h.pages.dev/changelog/rss/index.xml) [ View RSS feeds ](https://edgetunnel-b2h.pages.dev/fundamentals/new-features/available-rss-feeds/) Workers ![hero image](https://edgetunnel-b2h.pages.dev/_astro/hero.CVYJHPAd_26AMqX.svg) Jun 02, 2026 1. ### [Schedule Workflow instances directly from your Workflow binding](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-02-cron-workflows/) [ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) You can now attach cron schedules directly to a Workflow binding in `wrangler.jsonc`. Each scheduled run creates a new Workflow instance automatically, so you do not need to define a separate Worker with a `scheduled` handler just to trigger your Workflow on an interval. For example, you can configure hourly, every-15-minute, or weekday schedules on the same Workflow: **JSONC** ```jsonc { "workflows": [ { "name": "my-scheduled-workflow", "binding": "MY_WORKFLOW", "class_name": "MyScheduledWorkflow", "schedules": ["0 * * * *", "*/15 * * * *", "0 9 * * MON-FRI"], }, ], } ``` Cron workloads get all the same benefits of Workflows with built-in retries, multi-step durable execution, and configurable timeouts of Workflows. **TypeScript** ```ts import { WorkflowEntrypoint, WorkflowEvent, WorkflowStep, } from "cloudflare:workers"; // Runs automatically on each cron schedule defined for the MY_WORKFLOW binding in wrangler.jsonc. export class MyScheduledWorkflow extends WorkflowEntrypoint { async run(event: WorkflowEvent, step: WorkflowStep) { const data = await step.do("fetch source data", async () => { return await fetchSourceData(); }); // If this step fails, only this step is retried with the custom logic below await step.do( "process and store results", { retries: { limit: 5, delay: "30 seconds", backoff: "exponential" }, timeout: "10 minutes", }, async () => { await processAndStore(data); }, ); } } ``` This makes it easier to build recurring, scheduled jobs such as database backups, invoice generation, report aggregation, and cleanup tasks without wiring up a separate Cron Trigger entrypoint. For more information, refer to [Trigger Workflows](https://edgetunnel-b2h.pages.dev/workflows/build/trigger-workflows/). Jun 02, 2026 1. ### [Agents SDK v0.14.0: Agent Skills, messengers, scheduled tasks, Workflows, and hardened chat recovery](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-02-agents-sdk-v0140/) [ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) The latest release of the [Agents SDK ↗](https://github.com/cloudflare/agents) adds four new ways to build with `@cloudflare/think`: on-demand Agent Skills, chat messengers (starting with Telegram), declarative scheduled tasks, and durable reasoning steps inside Workflows. This release also significantly hardens durable chat recovery, so turns reliably ride through deploys, evictions, and stalled model streams in production. #### Agent Skills (experimental) Give an agent a catalog of on-demand instructions, resources, and scripts. A skill source adds a catalog to the system prompt, and the model activates a skill only when a task matches — so a large library of capabilities does not bloat every prompt. * [ JavaScript ](#tab-panel-2997) * [ TypeScript ](#tab-panel-2998) **JavaScript** ```js import { Think, skills } from "@cloudflare/think"; import bundledSkills from "agents:skills"; export class SkillsAgent extends Think { getSkills() { return [ bundledSkills, skills.r2(this.env.SKILLS_BUCKET, { prefix: "skills/" }), ]; } } ``` **TypeScript** ```ts import { Think, skills } from "@cloudflare/think"; import bundledSkills from "agents:skills"; export class SkillsAgent extends Think { getSkills() { return [ bundledSkills, skills.r2(this.env.SKILLS_BUCKET, { prefix: "skills/" }), ]; } } ``` The `agents:skills` import bundles a local `./skills` directory through the Agents Vite plugin (one directory per skill, each with a `SKILL.md`). Skills can also load from R2 or a manifest. When skills are available, Think exposes `activate_skill`, `read_skill_resource`, and an optional `run_skill_script` tool. Skill loading is resilient: a duplicate or failing source is skipped with a warning instead of breaking the agent. Agent Skills are **experimental**, and script execution in particular is early. The API may change in a future release. We would love your feedback — tell us what you are building and what is missing in the [Agents repository ↗](https://github.com/cloudflare/agents/discussions). #### Messengers Connect a Think agent directly to a chat platform. Think owns the webhook route, conversation routing, durable reply fiber, and streamed delivery back to the provider. Telegram ships as the first provider. * [ JavaScript ](#tab-panel-3009) * [ TypeScript ](#tab-panel-3010) **JavaScript** ```js import { Think } from "@cloudflare/think"; import { defineMessengers, ThinkMessengerStateAgent, } from "@cloudflare/think/messengers"; import telegramMessenger from "@cloudflare/think/messengers/telegram"; export { ThinkMessengerStateAgent }; export class SupportAgent extends Think { getMessengers() { return defineMessengers({ telegram: telegramMessenger({ token: this.env.TELEGRAM_BOT_TOKEN, userName: "support_bot", secretToken: this.env.TELEGRAM_WEBHOOK_SECRET_TOKEN, }), }); } } ``` **TypeScript** ```ts import { Think } from "@cloudflare/think"; import { defineMessengers, ThinkMessengerStateAgent, } from "@cloudflare/think/messengers"; import telegramMessenger from "@cloudflare/think/messengers/telegram"; export { ThinkMessengerStateAgent }; export class SupportAgent extends Think { getMessengers() { return defineMessengers({ telegram: telegramMessenger({ token: this.env.TELEGRAM_BOT_TOKEN, userName: "support_bot", secretToken: this.env.TELEGRAM_WEBHOOK_SECRET_TOKEN, }), }); } } ``` Each Chat SDK thread maps to its own Think sub-agent by default, so group chats and direct messages do not share memory. Multiple bots, custom conversation routing, and custom providers are all supported. #### Scheduled tasks Declare recurring, timezone-aware prompts and handlers with a typed domain-specific language (DSL). Think reconciles the declarations on startup and re-arms the next occurrence after each run, backed by durable idempotent submissions. * [ JavaScript ](#tab-panel-3005) * [ TypeScript ](#tab-panel-3006) **JavaScript** ```js import { Think, defineScheduledTasks } from "@cloudflare/think"; export class DigestAgent extends Think { getScheduledTasks() { return defineScheduledTasks({ weeklyCommitReport: { schedule: "every week on monday at 09:00", prompt: "Compile my GitHub commits for the last week and summarize them.", }, workout: { schedule: "every day at 08:00 in Europe/London", prompt: "Start my workout.", }, }); } } ``` **TypeScript** ```ts import { Think, defineScheduledTasks } from "@cloudflare/think"; export class DigestAgent extends Think { getScheduledTasks() { return defineScheduledTasks({ weeklyCommitReport: { schedule: "every week on monday at 09:00", prompt: "Compile my GitHub commits for the last week and summarize them.", }, workout: { schedule: "every day at 08:00 in Europe/London", prompt: "Start my workout.", }, }); } } ``` #### Think Workflows Run a model-driven reasoning step inside a Cloudflare Workflow with `ThinkWorkflow` and `step.prompt()`, with durable typed structured output, long waits, and approval gates. * [ JavaScript ](#tab-panel-3013) * [ TypeScript ](#tab-panel-3014) **JavaScript** ```js import { z } from "zod"; import { ThinkWorkflow } from "@cloudflare/think/workflows"; const draftSchema = z.object({ title: z.string(), summary: z.string(), labels: z.array(z.string()), }); export class TriageWorkflow extends ThinkWorkflow { async run(event, step) { const draft = await step.prompt("triage-issue", { prompt: `Triage issue #${event.payload.issueNumber}`, output: draftSchema, timeout: "3 days", }); await step.do("apply-labels", async () => { await this.agent.applyLabels(draft.labels); }); } } ``` **TypeScript** ```ts import { z } from "zod"; import { ThinkWorkflow } from "@cloudflare/think/workflows"; import type { ThinkWorkflowStep } from "@cloudflare/think/workflows"; import type { AgentWorkflowEvent } from "agents/workflows"; const draftSchema = z.object({ title: z.string(), summary: z.string(), labels: z.array(z.string()), }); export class TriageWorkflow extends ThinkWorkflow { async run(event: AgentWorkflowEvent, step: ThinkWorkflowStep) { const draft = await step.prompt("triage-issue", { prompt: `Triage issue #${event.payload.issueNumber}`, output: draftSchema, timeout: "3 days", }); await step.do("apply-labels", async () => { await this.agent.applyLabels(draft.labels); }); } } ``` #### Production hardening for durable chat recovery Durable chat turns have always been designed to survive a mid-turn deploy or Durable Object eviction. This release is a major hardening pass on that machinery for production. * **Better recovery during deploys.** Turns now ride through continuous deploys and evictions without losing completed work or re-running tools that already ran. * **A live "recovering…" signal.** `useAgentChat` exposes a new `isRecovering` flag, so a recovering turn shows progress instead of looking frozen. Most UIs render `isStreaming || isRecovering` as "busy". * **Stalled streams recover.** Set `chatStreamStallTimeoutMs` to route a hung provider stream into the same recovery path instead of leaving an infinite spinner. * **Sub-agents re-attach.** On parent recovery, an in-flight `agentTool()` child is re-attached to its result rather than abandoned and re-run, so long-running children no longer lose work under deploys. #### MCP transport improvements * **Resumable streams** — In-flight tool calls over Server-Sent Events (SSE) survive a dropped connection. Clients reconnect with `Last-Event-ID` and replay anything they missed. * **Readable server IDs** — `addMcpServer` accepts an optional `id`, so tools surface as readable keys (for example `tool_github_create_pull_request`) instead of opaque connection IDs. * **Better handling of concurrent requests** — Overlapping JSON-RPC requests are now correctly correlated to their responses across the HTTP and RPC transports. #### Other improvements * **Compaction** — A `Session`'s `tokenCounter` now also drives the compaction boundary decision ("what to compress"), not just the fire/no-fire trigger. * **`@cloudflare/worker-bundler`** — Adds a `virtualModules` option to `createWorker` to provide in-memory module source during bundling. * **Client-tool continuations** — Parallel tool results now coalesce into a single continuation, immediate resume requests attach to the pending continuation, and server-side `needsApproval` continuations resume reliably after approval. #### Upgrade To update to the latest version: npm yarn pnpm bun ``` npm i agents@latest @cloudflare/think@latest @cloudflare/ai-chat@latest ``` ``` yarn add agents@latest @cloudflare/think@latest @cloudflare/ai-chat@latest ``` ``` pnpm add agents@latest @cloudflare/think@latest @cloudflare/ai-chat@latest ``` ``` bun add agents@latest @cloudflare/think@latest @cloudflare/ai-chat@latest ``` Refer to the [Agents API reference](https://edgetunnel-b2h.pages.dev/agents/runtime/) and [Chat agents documentation](https://edgetunnel-b2h.pages.dev/agents/communication-channels/chat/chat-agents/) for more information. May 18, 2026 1. ### [Share local dev servers through Cloudflare Tunnel in Wrangler and Vite](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-18-local-dev-tunnels/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) You can now share local dev sessions through [Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/tunnel/) and get a public URL when using either [Wrangler](https://edgetunnel-b2h.pages.dev/workers/wrangler/) or the [Cloudflare Vite plugin](https://edgetunnel-b2h.pages.dev/workers/vite-plugin/). This is useful when you need to share a preview, test a webhook, or access your app from another device. ![Vite local dev tunnel demo](https://edgetunnel-b2h.pages.dev/_astro/vite-local-dev-tunnel.CW4xpgIR_ZmyQ8a.webp) This lets you either: * start a temporary [Quick tunnel](https://edgetunnel-b2h.pages.dev/tunnel/setup/#quick-tunnels-development) with a random `*.trycloudflare.com` hostname, or * use an existing [named tunnel](https://edgetunnel-b2h.pages.dev/tunnel/setup/#create-a-tunnel) for a stable hostname and to restrict access with [Cloudflare Access](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/). To start a tunnel, press `t` in Wrangler or `t + Enter` in Vite while your dev server is running. For details on setting up a named tunnel, refer to [Share a local dev server](https://edgetunnel-b2h.pages.dev/workers/local-development/local-dev-tunnels/). May 15, 2026 1. ### [Hyperdrive exposes database connection pool size metrics](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-15-hyperdrive-pool-size-metrics/) [ Hyperdrive ](https://edgetunnel-b2h.pages.dev/hyperdrive/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) You can now view the size of your Hyperdrive database connection pools, giving you the ability to self-diagnose connection issues. Using the Cloudflare dashboard or the `hyperdrivePoolSizesAdaptiveGroups` dataset in the [GraphQL Analytics API](https://edgetunnel-b2h.pages.dev/analytics/graphql-api/getting-started/), you can see `waitingClients`, `currentPoolSize`, `availablePoolSlots`, and `maxPoolSize` for each of your configurations. A new **Pool connections** chart has been added to the **Metrics** tab of each Hyperdrive configuration in the [Cloudflare dashboard ↗](https://dash.cloudflare.com). You can use the location selector to drill down into specific locations hosting your connection pool by airport code. ![Hyperdrive pool size metrics chart](https://edgetunnel-b2h.pages.dev/_astro/hyperdrive-pool-size-metrics-chart.DZxLTFgB_3zcIK.webp) The chart shows: * **Waiting clients**: Client requests waiting for an available connection. * **Open connections**: Active connections to your database. * **Pool size maximum**: Your configured origin connection limit. Connection contention appears as a spike in waiting clients, or when open connections consistently approach the pool size maximum. If your open connections regularly approach this limit, consider contacting Cloudflare to [increase your Hyperdrive connection limit](https://edgetunnel-b2h.pages.dev/hyperdrive/platform/limits/#request-a-limit-increase). #### Pool size metrics The `hyperdrivePoolSizesAdaptiveGroups` dataset in the [GraphQL Analytics API](https://edgetunnel-b2h.pages.dev/analytics/graphql-api/getting-started/) exposes the following key connection pool metrics for each Hyperdrive configuration: Under `avg`: * **`currentPoolSize`** — Average number of connections currently open in the pool. * **`availablePoolSlots`** — Average number of pool connections available for checkout. * **`waitingClients`** — Average number of clients waiting for a connection from the pool. Under `max`: * **`maxPoolSize`** — Configured maximum size of the connection pool. * **`currentPoolSize`** — Peak number of connections open in the pool. * **`waitingClients`** — Peak number of clients waiting for a connection from the pool. For more information, refer to [Metrics and analytics](https://edgetunnel-b2h.pages.dev/hyperdrive/observability/metrics/) and [Connection pooling](https://edgetunnel-b2h.pages.dev/hyperdrive/concepts/connection-pooling/). May 14, 2026 1. ### [New Domains tab in the Workers dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-14-domains-tab/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) In your Worker's dashboard, there is now a dedicated **Domains** tab where you can purchase a new domain through Cloudflare Registrar and have it automatically connected, add an [existing domain](https://edgetunnel-b2h.pages.dev/workers/configuration/routing/custom-domains/), and manage all of your Worker's routing in one place. ![The new Domains tab in the Workers dashboard](https://edgetunnel-b2h.pages.dev/_astro/domains-tab.Cey2Oyr-_B4kIf.webp) You can also enable or disable your [workers.dev subdomain](https://edgetunnel-b2h.pages.dev/workers/configuration/routing/workers-dev/) and [Preview URLs](https://edgetunnel-b2h.pages.dev/workers/versions-and-deployments/preview-urls/), put them behind [Cloudflare Access](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/) to require sign-in, and jump directly to [analytics](https://edgetunnel-b2h.pages.dev/analytics/) or domain overview for any connected domain. To get started, go to **Workers & Pages**, select a Worker, and open the **Domains** tab. [ Go to **Workers & Pages** ](https://dash.cloudflare.com/?to=/:account/workers-and-pages) May 13, 2026 1. ### [Agents SDK v0.12.4: chat recovery, routing retries, durable Think submissions, and Voice connection control](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-13-agents-sdk-v0124/) [ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) The latest release of the [Agents SDK ↗](https://github.com/cloudflare/agents) brings more reliable chat recovery, fixes Agent state synchronization during reconnects, adds durable submissions for Think, exposes routing retry configuration, and adds connection control for Voice agents. #### Chat recovery improvements `@cloudflare/ai-chat` now keeps server turns running when a browser or client stream is interrupted. This is useful for long-running AI responses where users refresh the page, close a tab, or temporarily lose connection. Calling `stop()` still cancels the server turn. Set `cancelOnClientAbort: true` if browser or client aborts should also cancel the server turn: * [ JavaScript ](#tab-panel-2999) * [ TypeScript ](#tab-panel-3000) **JavaScript** ```js const chat = useAgentChat({ agent: "assistant", name: "user-123", cancelOnClientAbort: true, }); ``` **TypeScript** ```ts const chat = useAgentChat({ agent: "assistant", name: "user-123", cancelOnClientAbort: true, }); ``` Notable bug fixes: * Chat stream resume negotiation no longer throws when replay races with a closed WebSocket connection. * Recovered chat continuations no longer leave `useAgentChat` stuck in a streaming state when the original socket disconnects before a terminal response. * Approval auto-continuation preserves reasoning parts and persists continuation reasoning in the final message. * `isServerStreaming` now resets correctly when a resumed stream moves from the fallback observer path to a transport-owned stream. #### Agent state and routing fixes `agents@0.12.4` prevents duplicate initial state frames during WebSocket connection setup. This avoids stale initial state messages overwriting state updates already sent by the client. Agent recovery is also more reliable when tool calls span a Durable Object restart. Recovery now defers user finish hooks until after agent startup and isolates hook failures, so one failed hook does not block other recovered runs from finalizing. `getAgentByName()` now supports `routingRetry` for transient Durable Object routing failures: * [ JavaScript ](#tab-panel-3001) * [ TypeScript ](#tab-panel-3002) **JavaScript** ```js import { getAgentByName } from "agents"; const agent = await getAgentByName(env.AssistantAgent, "user-123", { routingRetry: { maxAttempts: 3, }, }); ``` **TypeScript** ```ts import { getAgentByName } from "agents"; const agent = await getAgentByName(env.AssistantAgent, "user-123", { routingRetry: { maxAttempts: 3, }, }); ``` #### Durable Think submissions `@cloudflare/think` now supports durable programmatic submissions. `submitMessages()` provides durable acceptance, idempotent retries, status inspection, cancellation, and cleanup for server-driven turns that should continue after the caller returns. `Think.chat()` RPC turns now run inside chat recovery fibers and persist their stream chunks. Interrupted sub-agent turns can recover partial output instead of starting over. `ChatOptions.tools` has been removed from the TypeScript API. Define durable tools on the child agent or use agent tools for orchestration. Runtime `options.tools` values passed by legacy callers are ignored with a warning. #### Think message pruning behavior change `@cloudflare/think` no longer applies `pruneMessages({ toolCalls: "before-last-2-messages" })` to model context by default. The previous default could strip client-side tool results from longer multi-turn flows. `truncateOlderMessages` still runs as before, so context cost remains bounded. Subclasses that relied on the old aggressive pruning can opt back in from `beforeTurn`: * [ JavaScript ](#tab-panel-3011) * [ TypeScript ](#tab-panel-3012) **JavaScript** ```js import { Think } from "@cloudflare/think"; import { pruneMessages } from "ai"; export class MyAgent extends Think { beforeTurn(ctx) { return { messages: pruneMessages({ messages: ctx.messages, toolCalls: "before-last-2-messages", }), }; } } ``` **TypeScript** ```ts import { Think } from "@cloudflare/think"; import { pruneMessages } from "ai"; export class MyAgent extends Think { beforeTurn(ctx) { return { messages: pruneMessages({ messages: ctx.messages, toolCalls: "before-last-2-messages", }), }; } } ``` #### Voice agent connection control `@cloudflare/voice` adds an `enabled` option to `useVoiceAgent`. React apps can now delay creating and connecting a `VoiceClient` until prerequisites such as capability tokens are ready. * [ JavaScript ](#tab-panel-3003) * [ TypeScript ](#tab-panel-3004) **JavaScript** ```js const voice = useVoiceAgent({ agent: "MyVoiceAgent", enabled: Boolean(token), }); ``` **TypeScript** ```ts const voice = useVoiceAgent({ agent: "MyVoiceAgent", enabled: Boolean(token), }); ``` This release also fixes Workers AI speech-to-text session edge cases and `withVoice` text streaming from AI SDK `textStream` responses. #### Other improvements * **Streamable HTTP routing** — Server-to-client requests now route through the originating POST stream when no standalone SSE stream is available. * **Structured tool output** — Tool output shapes are preserved when truncating older messages or oversized persisted rows. * **Non-chat Think tool steps** — Think agent-tool children can complete without emitting assistant text and can return structured output through `getAgentToolOutput`. * **Sub-agent schedules** — Stale sub-agent schedule rows are pruned when their owning facet registry entry no longer exists. * **`@cloudflare/codemode`** — Adds a browser-safe export with an iframe sandbox executor and resolves OpenAPI specs inside the sandbox to avoid Worker Loader RPC size limits. #### Upgrade To update to the latest version: ```sh npm i agents@latest @cloudflare/ai-chat@latest @cloudflare/think@latest @cloudflare/voice@latest ``` Refer to the [Agents API reference](https://edgetunnel-b2h.pages.dev/agents/runtime/) and [Chat agents documentation](https://edgetunnel-b2h.pages.dev/agents/communication-channels/chat/chat-agents/) for more information. May 07, 2026 1. ### [WAF and framework adapter mitigations for React and Next.js vulnerabilities](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-06-react-nextjs-vulnerabilities/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/)[ WAF ](https://edgetunnel-b2h.pages.dev/waf/) Multiple security vulnerabilities were disclosed by the React team and Vercel affecting React Server Components and Next.js. These include denial of service, middleware and proxy bypass, server-side request forgery, cross-site scripting, and cache poisoning issues across a range of severity levels. **We strongly recommend updating your application and its dependencies immediately.** Patched versions are available for React (`react-server-dom-webpack`, `react-server-dom-parcel`, and `react-server-dom-turbopack` `19.0.6`, `19.1.7`, and `19.2.6`) and Next.js (`15.5.16` and `16.2.5`). #### WAF protections Cloudflare WAF rules deployed in response to prior React Server Component CVEs ([CVE-2025-55184 ↗](https://github.com/facebook/react/security/advisories/GHSA-2m3v-v2m8-q956) and [CVE-2026-23864 ↗](https://github.com/facebook/react/security/advisories/GHSA-83fc-fqcc-2hmg)) already provide coverage for the newly disclosed denial-of-service vulnerabilities. These rules are enabled by default with a Block action for all customers using the Cloudflare Managed Ruleset, including Free plan customers using the Free Managed Ruleset. | Ruleset | Rule description | Rule ID | Default action | | -------------------------- | ----------------------------------------------------------------------------------------------------------- | -------------------------------- | -------------- | | Cloudflare Managed Ruleset | React - DoS - [CVE-2025-55184 ↗](https://github.com/facebook/react/security/advisories/GHSA-2m3v-v2m8-q956) | 2694f1610c0b471393b21aef102ec699 | Block | | Cloudflare Managed Ruleset | React - DoS - [CVE-2026-23864 ↗](https://github.com/facebook/react/security/advisories/GHSA-83fc-fqcc-2hmg) | aaede80b4d414dc89c443cea61680354 | Block | The existing rules detect the underlying attack patterns generically. As a result, they apply to the new [CVE-2026-23870 ↗](https://github.com/facebook/react/security/advisories/GHSA-rv78-f8rc-xrxh) denial-of-service vulnerability in Server Components and the corresponding Next.js advisory [GHSA-8h8q-6873-q5fj ↗](https://github.com/vercel/next.js/security/advisories/GHSA-8h8q-6873-q5fj). Cloudflare is investigating whether WAF rules can be safely and effectively deployed for three of the high-severity advisories: [CVE-2026-23870 ↗](https://github.com/facebook/react/security/advisories/GHSA-rv78-f8rc-xrxh) / [GHSA-8h8q-6873-q5fj ↗](https://github.com/vercel/next.js/security/advisories/GHSA-8h8q-6873-q5fj), [GHSA-267c-6grr-h53f ↗](https://github.com/vercel/next.js/security/advisories/GHSA-267c-6grr-h53f), and [GHSA-mg66-mrh9-m8jx ↗](https://github.com/vercel/next.js/security/advisories/GHSA-mg66-mrh9-m8jx). If it is possible to create a managed WAF rule that mitigates these CVEs and does not potentially break application behavior, Cloudflare will add additional managed WAF rules. These rules will be announced through the [WAF changelog](https://edgetunnel-b2h.pages.dev/waf/change-log/changelog/). Because these vulnerabilities were shared with Cloudflare with minimal advance notice, we are still investigating what WAF mitigations are possible. Several of the disclosed vulnerabilities are not possible to block in WAF. We strongly recommend updating your applications so they are not purely reliant on WAF mitigations. Customers on Pro, Business, or Enterprise plans should ensure that [Managed Rules are enabled](https://edgetunnel-b2h.pages.dev/waf/get-started/#1-deploy-the-cloudflare-managed-ruleset). #### Next.js adapters **Vinext:** [Vinext ↗](https://github.com/cloudflare/vinext) is a Vite plugin that reimplements the Next.js API surface. Vinext's latest release is not vulnerable to any of the disclosed CVEs. Vinext's architecture differs from stock Next.js in ways that sidestep the affected code paths. For example, it does not implement the PPR resume protocol, does not expose Pages Router data-route endpoints, and strips internal headers such as `x-nextjs-data` at request boundaries. As an extra layer of defense, we added a React `19.2.6` or later requirement when running `vinext init` ([PR #1118 ↗](https://github.com/cloudflare/vinext/pull/1118), [PR #1112 ↗](https://github.com/cloudflare/vinext/pull/1112)) to prevent accidentally running a vulnerable version of React with Vinext. **OpenNext on Cloudflare:** OpenNext is an adapter that lets you deploy Next.js apps to the Cloudflare Workers platform. OpenNext itself is not directly vulnerable to the React denial-of-service CVE, but users must update the Next.js version in their application. The OpenNext team has updated the adapter to further harden against these vectors and released a new version of the Cloudflare adapter. Test fixtures and examples have been updated to use patched versions ([PR #1255 ↗](https://github.com/opennextjs/opennextjs-cloudflare/pull/1255)). #### Summary of disclosed vulnerabilities | Advisory | Severity | Issue | WAF status | | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | [CVE-2026-23870 ↗](https://github.com/facebook/react/security/advisories/GHSA-rv78-f8rc-xrxh) / [GHSA-8h8q-6873-q5fj ↗](https://github.com/vercel/next.js/security/advisories/GHSA-8h8q-6873-q5fj) | High | Denial of service in Server Components | **WAF rules in place:** 2694f1610c0b471393b21aef102ec699, aaede80b4d414dc89c443cea61680354Cloudflare is investigating additional managed WAF coverage | | [GHSA-267c-6grr-h53f ↗](https://github.com/vercel/next.js/security/advisories/GHSA-267c-6grr-h53f) | High | Middleware bypass via segment-prefetch routes | Cloudflare is investigating if this can be safely and effectively mitigated by a managed WAF rule | | [GHSA-mg66-mrh9-m8jx ↗](https://github.com/vercel/next.js/security/advisories/GHSA-mg66-mrh9-m8jx) | High | Denial of service via connection exhaustion in Cache Components | Cloudflare is investigating if this can be safely and effectively mitigated by a managed WAF rule | | [GHSA-492v-c6pp-mqqv ↗](https://github.com/vercel/next.js/security/advisories/GHSA-492v-c6pp-mqqv) | High | Middleware bypass via dynamic route parameter injection | Not possible to safely enable a managed WAF rule without potentially breaking application behavior | | [GHSA-c4j6-fc7j-m34r ↗](https://github.com/vercel/next.js/security/advisories/GHSA-c4j6-fc7j-m34r) | High | SSRF via WebSocket upgrades | Not possible to safely enable a managed WAF rule without potentially breaking application behavior | | [GHSA-36qx-fr4f-26g5 ↗](https://github.com/vercel/next.js/security/advisories/GHSA-36qx-fr4f-26g5) | High | Middleware bypass in Pages Router i18n | Custom WAF rule possible; global managed rule could potentially break application behavior | | [GHSA-ffhc-5mcf-pf4q ↗](https://github.com/vercel/next.js/security/advisories/GHSA-ffhc-5mcf-pf4q) | Moderate | XSS via CSP nonces | Custom WAF rule possible; global managed rule could potentially break application behavior | | [GHSA-gx5p-jg67-6x7h ↗](https://github.com/vercel/next.js/security/advisories/GHSA-gx5p-jg67-6x7h) | Moderate | XSS in beforeInteractive scripts | Not possible to safely enable a managed WAF rule without potentially breaking application behavior | | [GHSA-h64f-5h5j-jqjh ↗](https://github.com/vercel/next.js/security/advisories/GHSA-h64f-5h5j-jqjh) | Moderate | Denial of service in Image Optimization API | Custom WAF rule possible; global managed rule could potentially break application behavior | | [GHSA-wfc6-r584-vfw7 ↗](https://github.com/vercel/next.js/security/advisories/GHSA-wfc6-r584-vfw7) | Moderate | Cache poisoning in RSC responses | Custom WAF rule possible; global managed rule could potentially break application behavior | | [GHSA-vfv6-92ff-j949 ↗](https://github.com/vercel/next.js/security/advisories/GHSA-vfv6-92ff-j949) | Low | Cache poisoning via RSC cache-busting collisions | Not possible to safely enable a managed WAF rule without potentially breaking application behavior | | [GHSA-3g8h-86w9-wvmq ↗](https://github.com/vercel/next.js/security/advisories/GHSA-3g8h-86w9-wvmq) | Low | Middleware redirect cache poisoning | Custom WAF rule possible; global managed rule could potentially break application behavior | May 07, 2026 1. ### [Automatic tracing across Durable Object and Worker subrequests](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-07-automatic-tracing-across-do-and-worker-subrequests/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) You can now get a single unified trace across Worker-to-Worker subrequests, with trace context propagating automatically. Previously, [automatic tracing](https://edgetunnel-b2h.pages.dev/workers/observability/traces/) produced disconnected traces when a Worker called another Worker through a [service binding](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/bindings/service-bindings/) or [Durable Object](https://edgetunnel-b2h.pages.dev/durable-objects/). ![Unified trace showing nested spans across a Durable Object subrequest and a service binding call](https://edgetunnel-b2h.pages.dev/_astro/2026-04-28-worker-to-worker-context-prop.Db1qNQJL_BUxyi.webp) This means you can: * Follow a request through your entire Worker architecture in one trace view * See service binding and Durable Object calls as nested child spans instead of separate traces * Debug cross-Worker request flows in the Cloudflare dashboard or in an external observability platform via [OpenTelemetry](https://edgetunnel-b2h.pages.dev/workers/observability/exporting-opentelemetry-data/) [Tracing must be enabled](https://edgetunnel-b2h.pages.dev/workers/observability/traces/#how-to-enable-tracing) in your Wrangler configuration for traces to be recorded. Checkout [Workers tracing](https://edgetunnel-b2h.pages.dev/workers/observability/traces/) to get started. Up next, we are working on external trace context propagation using [W3C Trace Context standards ↗](https://www.w3.org/TR/trace-context/), which will allow traces from your Workers to link with traces from services outside of Cloudflare. May 01, 2026 1. ### [Run Workflows inside Dynamic Workers with the @cloudflare/dynamic-workflows library](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-01-dynamic-workflows/) [ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) You can now use [@cloudflare/dynamic-workflows ↗](https://github.com/cloudflare/dynamic-workflows) to run a [Workflow](https://edgetunnel-b2h.pages.dev/workflows/) inside a [Dynamic Worker](https://edgetunnel-b2h.pages.dev/dynamic-workers/), ensuring durable execution for code that is loaded at runtime. The Worker Loader loads Dynamic Workers on demand, which previously made durability challenging. Even within a Dynamic Worker, a Workflow might sleep for hours or days between steps, and by the time it resumes, the original Dynamic Worker code would no longer be in memory. The library solves this by tagging each Workflow instance with metadata that identifies which Dynamic Worker to load — for example, a tenant ID — then reloading the matching Dynamic Worker through the Worker Loader whenever a Workflow awakens. Because Dynamic Workers are created on-demand, you do not have to register each Workflow up front or manage them individually. Load the Workflow code in the Dynamic Worker when it is needed, and the Workflows engine handles persistence and retries behind the scenes. Your Workflow code itself is unaffected by the routing and behaves as normal. This unlocks patterns where the Workflow code itself is dynamic. For example, this is useful with: * **SaaS platforms** where each tenant defines their own automation, such as onboarding sequences, approval chains, or billing retry logic. * **AI agent frameworks** where agents generate and execute multi-step plans at runtime, surviving restarts and waiting for human approval between tool calls. * **Multi-tenant job systems** where each customer submits their own processing logic and every step persists progress and retries on failure. **TypeScript** ```ts import { createDynamicWorkflowEntrypoint, DynamicWorkflowBinding, wrapWorkflowBinding, type WorkflowRunner, } from "@cloudflare/dynamic-workflows"; export { DynamicWorkflowBinding }; interface Env { WORKFLOWS: Workflow; LOADER: WorkerLoader; } function loadTenant(env: Env, tenantId: string) { return env.LOADER.get(tenantId, async () => ({ compatibilityDate: "2026-01-01", mainModule: "index.js", modules: { "index.js": await fetchTenantCode(tenantId) }, // The Dynamic Worker uses this exactly like a real Workflow binding; // every create() is tagged with { tenantId } automatically. env: { WORKFLOWS: wrapWorkflowBinding({ tenantId }) }, })); } // The entrypoint name must match `class_name` in the workflows binding of your Wrangler config file. export const DynamicWorkflow = createDynamicWorkflowEntrypoint( async ({ env, metadata }) => { const stub = loadTenant(env, metadata.tenantId as string); return stub.getEntrypoint("TenantWorkflow") as unknown as WorkflowRunner; }, ); export default { fetch(request: Request, env: Env) { const tenantId = request.headers.get("x-tenant-id")!; return loadTenant(env, tenantId).getEntrypoint().fetch(request); }, }; ``` For a full walkthrough, refer to the [Dynamic Workflows guide](https://edgetunnel-b2h.pages.dev/dynamic-workers/usage/dynamic-workflows/). Apr 21, 2026 1. ### [Introducing Billable Usage dashboard and Budget alerts](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-13-billable-usage-dashboard-and-budget-alerts/) [ Cloudflare Fundamentals ](https://edgetunnel-b2h.pages.dev/fundamentals/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) Pay-as-you-go customers can now monitor usage-based costs and configure spend alerts through two new features: the Billable Usage dashboard and Budget alerts. #### Billable Usage dashboard The Billable Usage dashboard provides daily visibility into usage-based costs across your Cloudflare account. The data comes from the same system that generates your monthly invoice, so the figures match your bill. The dashboard displays: * A bar chart showing daily usage charges for your billing period * A sortable table breaking down usage by product, including total usage, billable usage, and cumulative costs * Ability to view previous billing periods Usage data aligns to your billing cycle, not the calendar month. The total usage cost shown at the end of a completed billing period matches the usage overage charges on your corresponding invoice. To access the dashboard, go to **Manage Account** \> **Billing** \> **Billable Usage**. ![Screenshot of the Billable Usage dashboard in the Cloudflare dashboard](https://edgetunnel-b2h.pages.dev/_astro/billable-usage-dashboard.CQvMdtrp_Z2qynps.webp) #### Budget alerts Budget alerts allow you to set dollar-based thresholds for your account-level usage spend. You receive an email notification when your projected monthly spend reaches your configured threshold, giving you proactive visibility into your bill before month-end. To configure a budget alert: 1. Go to **Manage Account** \> **Billing** \> **Billable Usage**. 2. Select **Set Budget Alert**. 3. Enter a budget threshold amount greater than $0. 4. Select **Create**. Alternatively, configure alerts via **Notifications** \> **Add** \> **Budget Alert**. ![Create Budget Alert modal in the Cloudflare dashboard](https://edgetunnel-b2h.pages.dev/_astro/budget-alert-modal.BjIzGOLV_Zr8DX5.webp) You can create multiple budget alerts at different dollar amounts. The notifications system automatically deduplicates alerts if multiple thresholds trigger at the same time. Budget alerts are calculated daily based on your usage trends and fire once per billing cycle when your projected spend first crosses your threshold. Both features are available to Pay-as-you-go accounts with usage-based products (Workers, R2, Images, etc.). Enterprise contract accounts are not supported. For more information, refer to the [Usage based billing documentation](https://edgetunnel-b2h.pages.dev/billing/understand/usage-based-billing/). Apr 21, 2026 1. ### [WebSocket binary messages now delivered as Blob by default](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-21-websocket-standard-binary-type/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) Binary frames received on a `WebSocket` are now delivered to the `message` event as [Blob ↗](https://developer.mozilla.org/en-US/docs/Web/API/Blob) objects by default. This matches the [WebSocket specification ↗](https://websockets.spec.whatwg.org/) and standard browser behavior. Previously, binary frames were always delivered as [ArrayBuffer ↗](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global%5FObjects/ArrayBuffer). The [binaryType](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/websockets/#binarytype) property on `WebSocket` controls the delivery type on a per-WebSocket basis. This change has been active for Workers with compatibility dates on or after `2026-03-17`, via the [websocket\_standard\_binary\_type](https://edgetunnel-b2h.pages.dev/workers/configuration/compatibility-flags/#websocket-standard-binary-type) compatibility flag. We should have documented this change when it shipped but didn't. We're sorry for the trouble that caused. If your Worker handles binary WebSocket messages and assumes `event.data` is an `ArrayBuffer`, the frames will arrive as `Blob` instead, and a naive `instanceof ArrayBuffer` check will silently drop every frame. To opt back into `ArrayBuffer` delivery, assign `binaryType` before calling `accept()`. This works regardless of the compatibility flag: **JavaScript** ```js const resp = await fetch("https://example.com", { headers: { Upgrade: "websocket" }, }); const ws = resp.webSocket; // Opt back into ArrayBuffer delivery for this WebSocket. ws.binaryType = "arraybuffer"; ws.accept(); ws.addEventListener("message", (event) => { if (typeof event.data === "string") { // Text frame. } else { // event.data is an ArrayBuffer because we set binaryType above. } }); ``` If you are not ready to migrate and want to keep `ArrayBuffer` as the default for all WebSockets in your Worker, add the `no_websocket_standard_binary_type` flag to your [Wrangler configuration file](https://edgetunnel-b2h.pages.dev/workers/wrangler/configuration/). This change has no effect on the Durable Object hibernatable WebSocket [webSocketMessage](https://edgetunnel-b2h.pages.dev/durable-objects/best-practices/websockets/) handler, which continues to receive binary data as `ArrayBuffer`. For more information, refer to [WebSockets binary messages](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/websockets/#binary-messages). Apr 15, 2026 1. ### [Increased concurrency, creation rate, and queued instance limits for Workflows instances](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-15-workflows-limits-raised/) [ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) [Workflows](https://edgetunnel-b2h.pages.dev/workflows/) limits have been raised to the following: | Limit | Previous | New | | ----------------------------------------------------- | ---------------------- | ----------------------------------------------- | | Concurrent instances (running in parallel) | 10,000 | 50,000 | | Instance creation rate (per account) | 100/second per account | 300/second per account, 100/second per workflow | | Queued instances per Workflow [1](#user-content-fn-1) | 1 million | 2 million | These increases apply to all users on the [Workers Paid plan](https://edgetunnel-b2h.pages.dev/workers/platform/pricing/). Refer to the [Workflows limits documentation](https://edgetunnel-b2h.pages.dev/workflows/reference/limits/) for more details. #### Footnotes 1. Queued instances are instances that have been created or awoken and are waiting for a concurrency slot. [↩](#user-content-fnref-1) Apr 13, 2026 1. ### [Local Explorer for local resource data](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-13-local-explorer/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) Local Explorer is a browser-based interface and REST API for viewing and editing local resource data during development. It removes the need to write throwaway scripts or dig through `.wrangler/state` to understand what data your Worker has stored locally. Local Explorer is available in Wrangler 4.82.1+ and the Cloudflare Vite plugin 1.32.0+. Start a local development session and press `e` in your terminal, or navigate to `/cdn-cgi/explorer` on your local dev server. #### Supported resources Local Explorer supports five resource types and works across multiple workers running locally: * **[KV](https://edgetunnel-b2h.pages.dev/kv/)** — Browse keys, view values and metadata, create, update, and delete key-value pairs. * **[R2](https://edgetunnel-b2h.pages.dev/r2/)** — List objects, view metadata, upload files, and delete objects. Supports directory views and multi-select. * **[D1](https://edgetunnel-b2h.pages.dev/d1/)** — Browse tables and rows, run arbitrary SQL queries, and edit schemas in a full data studio. * **[Durable Objects](https://edgetunnel-b2h.pages.dev/durable-objects/)** (SQLite storage) — Browse individual object SQLite tables, run SQL queries, and edit schemas. * **[Workflows](https://edgetunnel-b2h.pages.dev/workflows/)** — List instances, view status and step history, trigger new runs, and pause, resume, restart, or terminate instances. #### OpenAPI-powered REST API Local Explorer exposes a REST API at `/cdn-cgi/explorer/api` that provides programmatic access to the same operations available in the browser. The root endpoint returns an [OpenAPI specification ↗](https://www.openapis.org/) describing all available endpoints, parameters, and response formats. ```sh curl http://localhost:8787/cdn-cgi/explorer/api ``` Point an AI coding agent at `/cdn-cgi/explorer/api` and it can discover and interact with your local resources without manual setup. This enables iterative development loops where an agent can populate test data in KV or D1, inspect Durable Object state, trigger Workflow runs, or upload files to R2. For more details, refer to the [Local Explorer documentation](https://edgetunnel-b2h.pages.dev/workers/local-development/local-explorer/). Apr 09, 2026 1. ### [Relaxed simultaneous connection limiting for Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-09-relaxed-connection-limiting/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) The [simultaneous open connections limit](https://edgetunnel-b2h.pages.dev/workers/platform/limits/#simultaneous-open-connections) has been relaxed. Previously, each Worker invocation was limited to six open connections at a time for the entire lifetime of each connection, including while reading the response body. Now, a connection is freed as soon as response headers arrive, so the six-connection limit only constrains how many connections can be in the initial "waiting for headers" phase simultaneously. #### Before: New connections are blocked until an earlier connection fully completes ![A 7th fetch is queued until an earlier connection fully completes, including reading its entire response body](https://edgetunnel-b2h.pages.dev/_astro/connection-limit-before.DA5Xnf2k_Z15lWkB.svg) #### After: New connections can start as soon as response headers arrive ![A 7th fetch starts as soon as any earlier connection receives its response headers](https://edgetunnel-b2h.pages.dev/_astro/connection-limit-after.BnN2EWxG_Z15lWkB.svg) This means Workers can now have many more connections open at the same time without queueing, as long as no more than six are waiting for their initial response. This eliminates the `Response closed due to connection limit` exception that could previously occur when the runtime canceled stalled connections to prevent deadlocks. Previously, the runtime used a deadlock avoidance algorithm that watched each open connection for I/O activity. If all six connections appeared idle — even momentarily — the runtime would cancel the least-recently-used connection to make room for new requests. In practice, this heuristic was fragile. For example, when a response used `Content-Encoding: gzip`, the runtime's internal decompression created brief gaps between read and write operations. During these gaps, the connection appeared stalled despite being actively read by the Worker. If multiple connections hit these gaps at the same time, the runtime could spuriously cancel a connection that was working correctly. By only counting connections during the waiting-for-headers phase — where the runtime is fully in control and there is no ambiguity about whether the connection is active — this class of bug is eliminated entirely. #### Before: Connections could be canceled during brief internal pauses ![A connection with gaps from gzip decompression appears idle and is canceled by the runtime](https://edgetunnel-b2h.pages.dev/_astro/connection-cancel-before.B6J6v5SX_ZdXLqG.svg) #### After: Connections complete normally regardless of internal pauses ![The same connection completes normally because the body phase is no longer counted against the limit](https://edgetunnel-b2h.pages.dev/_astro/connection-cancel-after.0sUzrfMs_2fzdYj.svg) Apr 07, 2026 1. ### [WebSockets now automatically reply to Close frames](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-07-websocket-auto-reply-to-close/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) The Workers runtime now automatically sends a reciprocal Close frame when it receives a Close frame from the peer. The `readyState` transitions to `CLOSED` before the `close` event fires. This matches the [WebSocket specification ↗](https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/close%5Fevent) and standard browser behavior. This change is enabled by default for Workers using compatibility dates on or after `2026-04-07` (via the [web\_socket\_auto\_reply\_to\_close](https://edgetunnel-b2h.pages.dev/workers/configuration/compatibility-flags/#websocket-auto-reply-to-close) compatibility flag). Existing code that manually calls `close()` inside the `close` event handler will continue to work — the call is silently ignored when the WebSocket is already closed. **JavaScript** ```js const [client, server] = Object.values(new WebSocketPair()); server.accept(); server.addEventListener("close", (event) => { // readyState is already CLOSED — no need to call server.close(). console.log(server.readyState); // WebSocket.CLOSED console.log(event.code); // 1000 console.log(event.wasClean); // true }); ``` #### Half-open mode for WebSocket proxying The automatic close behavior can interfere with WebSocket proxying, where a Worker sits between a client and a backend and needs to coordinate the close on both sides independently. To support this use case, pass `{ allowHalfOpen: true }` to `accept()`: **JavaScript** ```js const [client, server] = Object.values(new WebSocketPair()); server.accept({ allowHalfOpen: true }); server.addEventListener("close", (event) => { // readyState is still CLOSING here, giving you time // to coordinate the close on the other side. console.log(server.readyState); // WebSocket.CLOSING // Manually close when ready. server.close(event.code, "done"); }); ``` For more information, refer to [WebSockets Close behavior](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/websockets/#close-behavior). Apr 01, 2026 1. ### [All Wrangler commands for Workflows now support local development](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-01-wrangler-workflows-local/) [ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) All `wrangler workflows` commands now accept a `--local` flag to target a Workflow running in a local `wrangler dev` session instead of the production API. You can now manage the full Workflow lifecycle locally, including triggering Workflows, listing instances, pausing, resuming, restarting, terminating, and sending events: ```sh npx wrangler workflows list --local npx wrangler workflows trigger my-workflow --local npx wrangler workflows instances list my-workflow --local npx wrangler workflows instances pause my-workflow --local npx wrangler workflows instances send-event my-workflow --type my-event --local ``` All commands also accept `--port` to target a specific `wrangler dev` session (defaults to `8787`). For more information, refer to [Workflows local development](https://edgetunnel-b2h.pages.dev/workflows/build/local-development/). Apr 01, 2026 1. ### [Deploy Hooks are now available for Workers Builds](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-01-deploy-hooks/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) [Workers Builds](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/) now supports Deploy Hooks — trigger builds from your headless CMS, a Cron Trigger, a Slack bot, or any system that can send an HTTP request. Each Deploy Hook is a unique URL tied to a specific branch. Send it a `POST` and your Worker builds and deploys. ```sh curl -X POST "https://api.cloudflare.com/client/v4/workers/builds/deploy_hooks/" ``` To create one, go to **Workers & Pages** \> your Worker > **Settings** \> **Builds** \> **Deploy Hooks**. Since a Deploy Hook is a URL, you can also call it from another Worker. For example, a Worker with a [Cron Trigger](https://edgetunnel-b2h.pages.dev/workers/configuration/cron-triggers/) can rebuild your project on a schedule: * [ JavaScript ](#tab-panel-3007) * [ TypeScript ](#tab-panel-3008) **JavaScript** ```js export default { async scheduled(event, env, ctx) { ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" })); }, }; ``` **TypeScript** ```ts export default { async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext): Promise { ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" })); }, } satisfies ExportedHandler; ``` You can also use Deploy Hooks to [rebuild when your CMS publishes new content](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/deploy-hooks/#cms-integration) or [deploy from a Slack slash command](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/deploy-hooks/#deploy-from-a-slack-slash-command). #### Built-in optimizations * **Automatic deduplication**: If a Deploy Hook fires multiple times before the first build starts running, redundant builds are automatically skipped. This keeps your build queue clean when webhooks retry or CMS events arrive in bursts. * **Last triggered**: The dashboard shows when each hook was last triggered. * **Build source**: Your Worker's build history shows which Deploy Hook started each build by name. Deploy Hooks are rate limited to 10 builds per minute per Worker and 100 builds per minute per account. For all limits, see [Limits & pricing](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/limits-and-pricing/). To get started, read the [Deploy Hooks documentation](https://edgetunnel-b2h.pages.dev/workers/ci-cd/builds/deploy-hooks/). Apr 01, 2026 1. ### [New L4 transport telemetry fields in Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-01-l4-transport-telemetry-fields/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) Three new properties are now available on `request.cf` in Workers that expose Layer 4 transport telemetry from the client connection. These properties let your Worker make decisions based on real-time connection quality signals — such as round-trip time and data delivery rate — without requiring any client-side changes. Previously, this telemetry was only available via the `Server-Timing: cfL4` response header. These new properties surface the same data directly in the Workers runtime, so you can use it for routing, logging, or response customization. #### New properties | Property | Type | Description | | ------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | clientTcpRtt | number \| undefined | The smoothed TCP round-trip time (RTT) between Cloudflare and the client in milliseconds. Only present for TCP connections (HTTP/1, HTTP/2). For example, 22. | | clientQuicRtt | number \| undefined | The smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only present for QUIC connections (HTTP/3). For example, 42. | | edgeL4 | Object \| undefined | Layer 4 transport statistics. Contains deliveryRate (number) — the most recent data delivery rate estimate for the connection, in bytes per second. For example, 123456. | #### Example: Log connection quality metrics **JavaScript** ```js export default { async fetch(request) { const cf = request.cf; const rtt = cf.clientTcpRtt ?? cf.clientQuicRtt ?? 0; const deliveryRate = cf.edgeL4?.deliveryRate ?? 0; const transport = cf.clientTcpRtt ? "TCP" : "QUIC"; console.log(`Transport: ${transport}, RTT: ${rtt}ms, Delivery rate: ${deliveryRate} B/s`); const headers = new Headers(request.headers); headers.set("X-Client-RTT", String(rtt)); headers.set("X-Delivery-Rate", String(deliveryRate)); return fetch(new Request(request, { headers })); }, }; ``` For more information, refer to [Workers Runtime APIs: Request](https://edgetunnel-b2h.pages.dev/workers/runtime-apis/request/). Mar 27, 2026 1. ### [New RFC 9440 mTLS certificate fields in Workers](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-27-rfc9440-mtls-fields/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) Four new fields are now available on `request.cf.tlsClientAuth` in Workers for requests that include a mutual TLS (mTLS) client certificate. These fields encode the client certificate and its intermediate chain in [RFC 9440 ↗](https://www.rfc-editor.org/rfc/rfc9440) format — the same standard format used by the `Client-Cert` and `Client-Cert-Chain` HTTP headers — so your Worker can forward them directly to your origin without any custom parsing or encoding logic. #### New fields | Field | Type | Description | | ------------------------ | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | certRFC9440 | String | The client leaf certificate in RFC 9440 format (:base64-DER:). Empty if no client certificate was presented. | | certRFC9440TooLarge | Boolean | true if the leaf certificate exceeded 10 KB and was omitted from certRFC9440. | | certChainRFC9440 | String | The intermediate certificate chain in RFC 9440 format as a comma-separated list. Empty if no intermediates were sent or if the chain exceeded 16 KB. | | certChainRFC9440TooLarge | Boolean | true if the intermediate chain exceeded 16 KB and was omitted from certChainRFC9440. | #### Example: forwarding client certificate headers to your origin **JavaScript** ```js export default { async fetch(request) { const tls = request.cf.tlsClientAuth; // Only forward if cert was verified and chain is complete if (!tls || !tls.certVerified || tls.certRevoked || tls.certChainRFC9440TooLarge) { return new Response("Unauthorized", { status: 401 }); } const headers = new Headers(request.headers); headers.set("Client-Cert", tls.certRFC9440); headers.set("Client-Cert-Chain", tls.certChainRFC9440); return fetch(new Request(request, { headers })); }, }; ``` For more information, refer to [Client certificate variables](https://edgetunnel-b2h.pages.dev/ssl/client-certificates/client-certificate-variables/#workers-variables) and [Mutual TLS authentication](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/service-credentials/mutual-tls-authentication/). Mar 26, 2026 1. ### [Access Durable Object jurisdiction via \`ctx.id.jurisdiction\`](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-26-durable-object-id-jurisdiction/) [ Durable Objects ](https://edgetunnel-b2h.pages.dev/durable-objects/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) `ctx.id.jurisdiction` inside a Durable Object now reports the [jurisdiction](https://edgetunnel-b2h.pages.dev/durable-objects/reference/data-location/#restrict-durable-objects-to-a-jurisdiction) the object was created in — for example `"eu"` when accessed through `env.MY_DURABLE_OBJECT.jurisdiction("eu")` — so you can make region-aware decisions without passing the jurisdiction through method arguments or persisting it in storage. For the full list of ID-construction paths that preserve `jurisdiction`, refer to the [Durable Object ID documentation](https://edgetunnel-b2h.pages.dev/durable-objects/api/id/#jurisdiction). **JavaScript** ```js export class RegionalRoom extends DurableObject { async fetch(request) { // "eu" when accessed through env.MY_DURABLE_OBJECT.jurisdiction("eu") const region = this.ctx.id.jurisdiction; return new Response(`Hello from ${region ?? "the default region"}!`); } } // Worker export default { async fetch(request, env) { const stub = env.MY_DURABLE_OBJECT.jurisdiction("eu").getByName("general"); return stub.fetch(request); }, }; ``` `ctx.id.jurisdiction` is `undefined` for Durable Objects that were not created in a jurisdiction-restricted namespace. Alarms scheduled before 2026-03-15 also do not have `jurisdiction` stored; to backfill the value, reschedule the alarm from a `fetch()` or RPC handler. Mar 25, 2026 1. ### [Declare required secrets in your Wrangler configuration](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-24-secrets-config-property/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) The new `secrets` configuration property lets you declare the secret names your Worker requires in your Wrangler configuration file. Required secrets are validated during local development and deploy, and used as the source of truth for type generation. * [ wrangler.jsonc ](#tab-panel-2995) * [ wrangler.toml ](#tab-panel-2996) **JSONC** ```jsonc { "secrets": { "required": ["API_KEY", "DB_PASSWORD"], }, } ``` **TOML** ```toml [secrets] required = [ "API_KEY", "DB_PASSWORD" ] ``` #### Local development When `secrets` is defined, `wrangler dev` and `vite dev` load only the keys listed in `secrets.required` from `.dev.vars` or `.env`/`process.env`. Additional keys in those files are excluded. If any required secrets are missing, a warning is logged listing the missing names. #### Type generation `wrangler types` generates typed bindings from `secrets.required` instead of inferring names from `.dev.vars` or `.env`. This lets you run type generation in CI or other environments where those files are not present. Per-environment secrets are supported — the aggregated `Env` type marks secrets that only appear in some environments as optional. #### Deploy `wrangler deploy` and `wrangler versions upload` validate that all secrets in `secrets.required` are configured on the Worker before the operation succeeds. If any required secrets are missing, the command fails with an error listing which secrets need to be set. For more information, refer to the [secrets configuration property](https://edgetunnel-b2h.pages.dev/workers/wrangler/configuration/#secrets-configuration-property) reference. Mar 24, 2026 1. ### [Dynamic Workers, now in open beta](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-24-dynamic-workers-open-beta/) [ Workers ](https://edgetunnel-b2h.pages.dev/workers/) [Dynamic Workers](https://edgetunnel-b2h.pages.dev/dynamic-workers/) are now in [open beta ↗](https://blog.cloudflare.com/dynamic-workers/) for all paid Workers users. You can now have a Worker spin up other Workers, called Dynamic Workers, at runtime to execute code on-demand in a secure, sandboxed environment. Dynamic Workers start in milliseconds, making them well suited for fast, secure code execution at scale. #### Use Dynamic Workers for * **[Code Mode](https://edgetunnel-b2h.pages.dev/agents/tools/codemode/)**: LLMs are trained to write code. Run tool-calling logic written in code instead of stepping through many tool calls, which can save up to 80% in inference tokens and cost. * **AI agents executing code**: Run code for tasks like data analysis, file transformation, API calls, and chained actions. * **Running AI-generated code**: Run generated code for prototypes, projects, and automations in a secure, isolated sandboxed environment. * **Fast development and previews**: Load prototypes, previews, and playgrounds in milliseconds. * **Custom automations**: Create custom tools on the fly that execute a task, call an integration, or automate a workflow. #### Executing Dynamic Workers Dynamic Workers support two loading modes: * `load(code)` — for one-time code execution (equivalent to calling `get()` with a null ID). * `get(id, callback)` — caches a Dynamic Worker by ID so it can stay warm across requests. Use this when the same code will receive subsequent requests. * [ JavaScript ](#tab-panel-3025) * [ TypeScript ](#tab-panel-3026) **JavaScript** ```js export default { async fetch(request, env) { const worker = env.LOADER.load({ compatibilityDate: "2026-01-01", mainModule: "src/index.js", modules: { "src/index.js": ` export default { fetch() { return new Response("Hello from a dynamic Worker"); }, }; `, }, // Block all outbound network access from the Dynamic Worker. globalOutbound: null, }); return worker.getEntrypoint().fetch(request); }, }; ``` **TypeScript** ```ts export default { async fetch(request: Request, env: Env): Promise { const worker = env.LOADER.load({ compatibilityDate: "2026-01-01", mainModule: "src/index.js", modules: { "src/index.js": ` export default { fetch() { return new Response("Hello from a dynamic Worker"); }, }; `, }, // Block all outbound network access from the Dynamic Worker. globalOutbound: null, }); return worker.getEntrypoint().fetch(request); }, }; ``` #### Helper libraries for Dynamic Workers Here are 3 new libraries to help you build with Dynamic Workers: * **[@cloudflare/codemode ↗](https://www.npmjs.com/package/@cloudflare/codemode)**: Replace individual tool calls with a single `code()` tool, so LLMs write and execute TypeScript that orchestrates multiple API calls in one pass. * **[@cloudflare/worker-bundler ↗](https://www.npmjs.com/package/@cloudflare/worker-bundler)**: Resolve npm dependencies and bundle source files into ready-to-load modules for Dynamic Workers, all at runtime. * **[@cloudflare/shell ↗](https://www.npmjs.com/package/@cloudflare/shell)**: Give your agent a virtual filesystem inside a Dynamic Worker with persistent storage backed by SQLite and R2. #### Try it out **Dynamic Workers Starter** [![Deploy to Workers](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/agents/tree/main/examples/dynamic-workers) Use this [starter ↗](https://github.com/cloudflare/agents/tree/main/examples/dynamic-workers) to deploy a Worker that can load and execute Dynamic Workers. **Dynamic Workers Playground** [![Deploy to Workers](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/agents/tree/main/examples/dynamic-workers-playground) Deploy the [Dynamic Workers Playground ↗](https://github.com/cloudflare/agents/tree/main/examples/dynamic-workers-playground) to write or import code, bundle it at runtime with `@cloudflare/worker-bundler`, execute it through a Dynamic Worker, and see real-time responses and execution logs. For the full API reference and configuration options, refer to the [Dynamic Workers documentation](https://edgetunnel-b2h.pages.dev/dynamic-workers/). #### Pricing Dynamic Workers [pricing](https://edgetunnel-b2h.pages.dev/dynamic-workers/pricing/) is based on three dimensions: Dynamic Workers created daily, requests, and CPU time. | | Included | Additional usage | | --------------------------------- | -------------------------------------- | ----------------------------------- | | **Dynamic Workers created daily** | 1,000 unique Dynamic Workers per month | +$0.002 per Dynamic Worker per day | | **Requests** ¹ | 10 million per month | +$0.30 per million requests | | **CPU time** ¹ | 30 million CPU milliseconds per month | +$0.02 per million CPU milliseconds | ¹ Uses [Workers Standard rates](https://edgetunnel-b2h.pages.dev/workers/platform/pricing/#workers) and will appear as part of your existing Workers bill, not as separate Dynamic Workers charges. Note: Dynamic Workers requests and CPU time are already billed as part of your Workers plan and will count toward your Workers requests and CPU usage. The Dynamic Workers created daily charge is not yet active — you will not be billed for the number of Dynamic Workers created at this time. Pricing information is shared in advance so you can estimate future costs. Mar 23, 2026 1. ### [Workflow instances now support pause(), resume(), restart(), and terminate() methods in local development](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-23-local-dev-instance-methods/) [ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) Workflow instance methods `pause()`, `resume()`, `restart()`, and `terminate()` are now available in local development when using `wrangler dev`. You can now test the full Workflow instance lifecycle locally: **TypeScript** ```ts const instance = await env.MY_WORKFLOW.create({ id: "my-instance-id", }); await instance.pause(); // pauses a running workflow instance await instance.resume(); // resumes a paused instance await instance.restart(); // restarts the instance from the beginning await instance.terminate(); // terminates the instance immediately ``` Mar 23, 2026 1. ### [Agents SDK v0.8.0: readable state, idempotent schedules, typed AgentClient, and Zod 4](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-23-agents-sdk-v080/) [ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) The latest release of the [Agents SDK ↗](https://github.com/cloudflare/agents) exposes agent state as a readable property, prevents duplicate schedule rows across Durable Object restarts, brings full TypeScript inference to `AgentClient`, and migrates to Zod 4. #### Readable `state` on `useAgent` and `AgentClient` Both `useAgent` (React) and `AgentClient` (vanilla JS) now expose a `state` property that reflects the current agent state. Previously, reading state required manually tracking it through the `onStateUpdate` callback. **React (`useAgent`)** * [ JavaScript ](#tab-panel-3015) * [ TypeScript ](#tab-panel-3016) **JavaScript** ```js const agent = useAgent({ agent: "game-agent", name: "room-123", }); // Read state directly — no separate useState + onStateUpdate needed return
Score: {agent.state?.score}
; // Spread for partial updates agent.setState({ ...agent.state, score: (agent.state?.score ?? 0) + 10 }); ``` **TypeScript** ```ts const agent = useAgent({ agent: "game-agent", name: "room-123", }); // Read state directly — no separate useState + onStateUpdate needed return
Score: {agent.state?.score}
; // Spread for partial updates agent.setState({ ...agent.state, score: (agent.state?.score ?? 0) + 10 }); ``` `agent.state` is reactive — the component re-renders when state changes from either the server or a client-side `setState()` call. **Vanilla JS (`AgentClient`)** * [ JavaScript ](#tab-panel-3017) * [ TypeScript ](#tab-panel-3018) **JavaScript** ```js const client = new AgentClient({ agent: "game-agent", name: "room-123", host: "your-worker.workers.dev", }); client.setState({ score: 100 }); console.log(client.state); // { score: 100 } ``` **TypeScript** ```ts const client = new AgentClient({ agent: "game-agent", name: "room-123", host: "your-worker.workers.dev", }); client.setState({ score: 100 }); console.log(client.state); // { score: 100 } ``` State starts as `undefined` and is populated when the server sends the initial state on connect (from `initialState`) or when `setState()` is called. Use optional chaining (`agent.state?.field`) for safe access. The `onStateUpdate` callback continues to work as before — the new `state` property is additive. #### Idempotent `schedule()` `schedule()` now supports an `idempotent` option that deduplicates by `(type, callback, payload)`, preventing duplicate rows from accumulating when called in places that run on every Durable Object restart such as `onStart()`. **Cron schedules are idempotent by default.** Calling `schedule("0 * * * *", "tick")` multiple times with the same callback, expression, and payload returns the existing schedule row instead of creating a new one. Pass `{ idempotent: false }` to override. Delayed and date-scheduled types support opt-in idempotency: * [ JavaScript ](#tab-panel-3019) * [ TypeScript ](#tab-panel-3020) **JavaScript** ```js import { Agent } from "agents"; class MyAgent extends Agent { async onStart() { // Safe across restarts — only one row is created await this.schedule(60, "maintenance", undefined, { idempotent: true }); } } ``` **TypeScript** ```ts import { Agent } from "agents"; class MyAgent extends Agent { async onStart() { // Safe across restarts — only one row is created await this.schedule(60, "maintenance", undefined, { idempotent: true }); } } ``` Two new warnings help catch common foot-guns: * Calling `schedule()` inside `onStart()` without `{ idempotent: true }` emits a `console.warn` with actionable guidance (once per callback; skipped for cron and when `idempotent` is set explicitly). * If an alarm cycle processes 10 or more stale one-shot rows for the same callback, the SDK emits a `console.warn` and a `schedule:duplicate_warning` diagnostics channel event. #### Typed `AgentClient` with `call` inference and `stub` proxy `AgentClient` now accepts an optional agent type parameter for full type inference on RPC calls, matching the typed experience already available with `useAgent`. * [ JavaScript ](#tab-panel-3023) * [ TypeScript ](#tab-panel-3024) **JavaScript** ```js const client = new AgentClient({ agent: "my-agent", host: window.location.host, }); // Typed call — method name autocompletes, args and return type inferred const value = await client.call("getValue"); // Typed stub — direct RPC-style proxy await client.stub.getValue(); await client.stub.add(1, 2); ``` **TypeScript** ```ts const client = new AgentClient({ agent: "my-agent", host: window.location.host, }); // Typed call — method name autocompletes, args and return type inferred const value = await client.call("getValue"); // Typed stub — direct RPC-style proxy await client.stub.getValue(); await client.stub.add(1, 2); ``` State is automatically inferred from the agent type, so `onStateUpdate` is also typed: * [ JavaScript ](#tab-panel-3021) * [ TypeScript ](#tab-panel-3022) **JavaScript** ```js const client = new AgentClient({ agent: "my-agent", host: window.location.host, onStateUpdate: (state) => { // state is typed as MyAgent's state type }, }); ``` **TypeScript** ```ts const client = new AgentClient({ agent: "my-agent", host: window.location.host, onStateUpdate: (state) => { // state is typed as MyAgent's state type }, }); ``` Existing untyped usage continues to work without changes. The RPC type utilities (`AgentMethods`, `AgentStub`, `RPCMethods`) are now exported from `agents/client` for advanced typing scenarios. `agents`, `@cloudflare/ai-chat`, and `@cloudflare/codemode` now require `zod ^4.0.0`. Zod v3 is no longer supported. #### `@cloudflare/ai-chat` fixes * **Turn serialization** — `onChatMessage()` and `_reply()` work is now queued so user requests, tool continuations, and `saveMessages()` never stream concurrently. * **Duplicate messages on stop** — Clicking stop during an active stream no longer splits the assistant message into two entries. * **Duplicate messages after tool calls** — Orphaned client IDs no longer leak into persistent storage. #### `keepAlive()` and `keepAliveWhile()` are no longer experimental `keepAlive()` now uses a lightweight in-memory ref count instead of schedule rows. Multiple concurrent callers share a single alarm cycle. The `@experimental` tag has been removed from both `keepAlive()` and `keepAliveWhile()`. #### `@cloudflare/codemode`: TanStack AI integration A new entry point `@cloudflare/codemode/tanstack-ai` adds support for [TanStack AI's ↗](https://tanstack.com/ai) `chat()` as an alternative to the Vercel AI SDK's `streamText()`: * [ JavaScript ](#tab-panel-3027) * [ TypeScript ](#tab-panel-3028) **JavaScript** ```js import { createCodeTool, tanstackTools, } from "@cloudflare/codemode/tanstack-ai"; import { chat } from "@tanstack/ai"; const codeTool = createCodeTool({ tools: [tanstackTools(myServerTools)], executor, }); const stream = chat({ adapter, tools: [codeTool], messages }); ``` **TypeScript** ```ts import { createCodeTool, tanstackTools } from "@cloudflare/codemode/tanstack-ai"; import { chat } from "@tanstack/ai"; const codeTool = createCodeTool({ tools: [tanstackTools(myServerTools)], executor, }); const stream = chat({ adapter, tools: [codeTool], messages }); ``` #### Upgrade To update to the latest version: ```sh npm i agents@latest @cloudflare/ai-chat@latest ``` Mar 19, 2026 1. ### [Manage Cloudflare Tunnels with Wrangler](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-19-wrangler-tunnel-commands/) [ Cloudflare Tunnel ](https://edgetunnel-b2h.pages.dev/tunnel/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) You can now manage [Cloudflare Tunnels](https://edgetunnel-b2h.pages.dev/tunnel/) directly from [Wrangler](https://edgetunnel-b2h.pages.dev/workers/wrangler/), the CLI for the Cloudflare Developer Platform. The new [wrangler tunnel](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/tunnel/) commands let you create, run, and manage tunnels without leaving your terminal. ![Wrangler tunnel commands demo](https://edgetunnel-b2h.pages.dev/_astro/wrangler-tunnel.DOqrtGGg_7EDX0.webp) Available commands: * `wrangler tunnel create` — Create a new remotely managed tunnel. * `wrangler tunnel list` — List all tunnels in your account. * `wrangler tunnel info` — Display details about a specific tunnel. * `wrangler tunnel delete` — Delete a tunnel. * `wrangler tunnel run` — Run a tunnel using the cloudflared daemon. * `wrangler tunnel quick-start` — Start a free, temporary tunnel without an account using [Quick Tunnels](https://edgetunnel-b2h.pages.dev/tunnel/setup/#quick-tunnels-development). Wrangler handles downloading and managing the [cloudflared](https://edgetunnel-b2h.pages.dev/tunnel/downloads/) binary automatically. On first use, you will be prompted to download `cloudflared` to a local cache directory. These commands are currently experimental and may change without notice. To get started, refer to the [Wrangler tunnel commands documentation](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/tunnel/). ```json {"@context":"https://schema.org","@type":"BlogPosting","@id":"https://edgetunnel-b2h.pages.dev/changelog/product/workers/2/#page","headline":"Workers Changelog | Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/changelog/product/workers/2/","inLanguage":"en","image":"https://edgetunnel-b2h.pages.dev/cf-twitter-card.png","publisher":{"@type":"Organization","name":"Cloudflare","url":"https://www.cloudflare.com/"},"isPartOf":{"@type":"WebSite","@id":"https://edgetunnel-b2h.pages.dev/#website","name":"Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/"}} ```