Media Updates & Release Notes

You can now interact with your Stream video library using new bindings for Workers! This allows customers to upload content to Stream, provision direct uploads, manage videos, and generate signed URLs from a Worker without making authenticated API calls. We're excited to bring Stream and Workers closer together to empower more programmatic pipelines, tighter integrations, and support generative AI and inference workloads.

Use the Stream binding when you want to:

• Upload videos from URLs or create basic direct upload links for end users
• Generate signed playback tokens without managing signing keys
• Manage video metadata, captions, downloads, and watermarks
• Build video pipelines entirely within Workers

To get started, add the Stream binding to your Wrangler configuration:

Generate a video with AI and upload directly to Stream or send a URL of a file you already have:

Generate a signed URL without using a signing key or an API call:

Get and set video properties easily:

For setup instructions and the full API reference, refer to Bind to Workers API.

Add a binding for Cloudflare Stream (env.STREAM). On the watch page, use the Stream binding to get info based on the ID, and leverage video.meta.name as the page title.

Original source

You can now use a Workers binding to transform videos with Media Transformations. This allows you to resize, crop, extract frames, and extract audio from videos stored anywhere, even in private locations like R2 buckets.

The Media Transformations binding is useful when you want to:

• Transform videos stored in private or protected sources
• Optimize videos and store the output directly back to R2 for re-use
• Extract still frames for classification or description with Workers AI
• Extract audio tracks for transcription using Workers AI

To get started, add the Media binding to your Wrangler configuration:

Then use the binding in your Worker to transform videos:

Output modes include video for optimized MP4 clips, frame for still images, spritesheet for multiple frames, and audio for M4A extraction.

For more information, refer to the Media Transformations binding documentation.

Original source

Real-time transcription in RealtimeKit

Real-time transcription in RealtimeKit now supports 10 languages with regional variants in RealtimeKit now supports 10 languages with regional variants, powered by Deepgram Nova-3 running on Workers AI .

During a meeting, participant audio is routed through AI Gateway to Nova-3 on Workers AI — so transcription runs on Cloudflare's network end-to-end, reducing latency compared to routing through external speech-to-text services.

Set the language when creating a meeting via ai_config.transcription.language :

{
  "ai_config": {
    "transcription": {
      "language": "fr"
    }
  }
}

Supported languages include English, Spanish, French, German, Hindi, Russian, Portuguese, Japanese, Italian, and Dutch — with regional variants like en-AU, en-GB, en-IN, en-NZ, es-419, fr-CA, de-CH, pt-BR, , and pt-PT. Use multi for automatic multilingual detection.

If you are building voice agents or real-time translation workflows, your agent can now transcribe in the caller's language natively — no extra services or routing logic needed.

• Transcription docs
• Nova-3 model page
• Workers AI
• AI Gateway

Original source

Cloudflare Workflows: Access current retry attempt

Cloudflare Workflows allows you to configure specific retry logic for each step in your workflow execution. Now, you can access which retry attempt is currently executing for calls to step.do() :

await
step.do(
"my-step",
async (ctx) =>
=>
{
// ctx.attempt is 1 on first try, 2 on first retry, etc.

console.log(`Attempt${${ctx.attempt}}`);
}
);

You can use the step context for improved logging & observability, progressive backoff, or conditional logic in your workflow definition.

Note that the current attempt number is 1-indexed. For more information on retry behavior, refer to
Sleeping and Retrying.

Original source

Radar ships several new features that improve the flexibility and usability of the platform, as well as visibility into what is happening on the Internet.

Region filtering

All location-aware pages now support filtering by region, including continents, geographic subregions (Middle East ↗, Eastern Asia ↗, etc.), political regions (EU ↗, African Union ↗), and US Census regions/divisions (for example, New England ↗, US Northeast ↗).

Traffic volume by top autonomous systems and locations

A new traffic volume view shows the top autonomous systems and countries/territories for a given location. This is useful for quickly determining which network providers in a location may be experiencing connectivity issues, or how traffic is distributed across a region.

The new AS and location dimensions have also been added to the Data Explorer ↗ for the HTTP, DNS, and NetFlows datasets. Combined with other available filters, this provides a powerful tool for generating unique insights.

Finally, breadcrumb navigation is now available on most pages, allowing easier navigation between parent and related pages.

Check out these features on Cloudflare Radar ↗.

Original source

REST API rate limits

REST API rate limits for Workers Paid plans have been increased from 3 requests per second (180/min) to 10 requests per second (600/min). No action is needed to benefit from the higher limit.

The REST API lets you perform common browser tasks with a single API call, and you can now do it at a higher rate.

• /content - Fetch HTML
• /screenshot - Capture screenshot
• /pdf - Render PDF
• /markdown - Extract Markdown from a webpage
• /snapshot - Take a webpage snapshot
• /scrape - Scrape HTML elements
• /json - Capture structured data using AI
• /links - Retrieve links from a webpage

If you use the Workers Bindings method, increases to concurrent browser and new browser limits are coming soon. Stay tuned.

For full details, refer to the Browser Rendering limits page.

Original source

The Gateway Authorization Proxy and PAC file hosting are now in open beta for all plan types.
Previously, proxy endpoints relied on static source IP addresses to authorize traffic, providing no user-level identity in logs or policies. The new authorization proxy replaces IP-based authorization with Cloudflare Access authentication, verifying who a user is before applying Gateway filtering without installing the WARP client.
This is ideal for environments where you cannot deploy a device client, such as virtual desktops (VDI), mergers and acquisitions, or compliance-restricted endpoints.

Key capabilities

• Identity-aware proxy traffic — Users authenticate through your identity provider (Okta, Microsoft Entra ID, Google Workspace, and others) via Cloudflare Access. Logs now show exactly which user accessed which site, and you can write identity-based policies like "only the Finance team can access this accounting tool."
• Multiple identity providers — Display one or multiple login methods simultaneously, giving flexibility for organizations managing users across different identity systems.
• Cloudflare-hosted PAC files — Create and host PAC files directly in Cloudflare One with pre-configured templates for Okta and Azure, hosted at https://pac.cloudflare-gateway.com// on Cloudflare's global network.
• Simplified billing — Each user occupies a seat, exactly like they do with the Cloudflare One Client. No new metrics to track.

Get started

• In Cloudflare One ↗, go to Networks > Resolvers & Proxies > Proxy endpoints.
• Create an authorization proxy endpoint and configure Access policies.
• Create a hosted PAC file or write your own.
• Configure browsers to use the PAC file URL.
• Install the Cloudflare certificate for HTTPS inspection.

For more details, refer to the proxy endpoints documentation and the announcement blog post announcement blog post.

Original source

Workflows on Workers

Each Workflow on Workers Paid now supports 10,000 steps by default, configurable up to 25,000 steps in your wrangler.jsonc file:

{
  "workflows": [
    {
      "name": "my-workflow",
      "binding": "MY_WORKFLOW",
      "class_name": "MyWorkflow",
      "limits": {
        "steps": 25000
      }
    }
  ]
}

Previously, each instance was limited to 1,024 steps. Now, Workflows can support more complex, long-running executions without the additional complexity of recursive or child workflow calls.

Note that the maximum persisted state limit per Workflow instance remains 100 MB for Workers Free and 1 GB for Workers Paid. Refer to Workflows limits for more information.

Original source

Sandboxes now support real-time filesystem watching via sandbox.watch(). The method returns a Server-Sent Events stream backed by native inotify, so your Worker receives create, modify, delete, and move events as they happen inside the container.

sandbox.watch(path, options)
Pass a directory path and optional filters. The returned stream is a standard ReadableStream you can proxy directly to a browser client or consume server-side.

Server-side consumption with parseSSEStream
Use parseSSEStream to iterate over events inside a Worker without forwarding them to a client.

Each event includes a type field (create, modify, delete, or move) and the affected path. Move events also include a from field with the original path.

Options

Option Type Description recursive boolean Watch subdirectories. Defaults to false. include string[] Glob patterns to filter events. Omit to receive all events.

Upgrade

To update to the latest version:

npm i @cloudflare/sandbox@latest

For full API details, refer to the Sandbox file watching reference.

Original source

Observability rewrite

The previous observability system used console.log() with a custom Observability.emit() interface. v0.7.0 replaces it with structured events published to diagnostics channels — silent by default, zero overhead when nobody is listening.
Every event has a type, payload, and timestamp. Events are routed to seven named channels:

Channel Event types agents:state state:update agents:rpc rpc, rpc:error agents:message message:request, message:response, message:clear, message:cancel, message:error, tool:result, tool:approval agents:schedule schedule:create, schedule:execute, schedule:cancel, schedule:retry, schedule:error, queue:retry, queue:error agents:lifecycle connect, destroy agents:workflow workflow:start, workflow:event, workflow:approved, workflow:rejected, workflow:terminated, workflow:paused, workflow:resumed, workflow:restarted agents:mcp mcp:client:preconnect, mcp:client:connect, mcp:client:authorize, mcp:client:discover

Use the typed subscribe() helper from agents/observability for type-safe access.

In production, all diagnostics channel messages are automatically forwarded to Tail Workers — no subscription code needed in the agent itself.

The custom Observability override interface is still supported for users who need to filter or forward events to external services.

For the full event reference, refer to the Observability documentation.

keepAlive() and keepAliveWhile()

Durable Objects are evicted after a period of inactivity (typically 70-140 seconds with no incoming requests, WebSocket messages, or alarms). During long-running operations — streaming LLM responses, waiting on external APIs, running multi-step computations — the agent can be evicted mid-flight.
keepAlive() prevents this by creating a 30-second heartbeat schedule. The alarm firing resets the inactivity timer. Returns a disposer function that cancels the heartbeat when called.

keepAliveWhile() wraps an async function with automatic cleanup — the heartbeat starts before the function runs and stops when it completes.

Key details:

• Multiple concurrent callers — Each keepAlive() call returns an independent disposer. Disposing one does not affect others.
• AIChatAgent built-in — AIChatAgent automatically calls keepAlive() during streaming responses. You do not need to add it yourself.
• Uses the scheduling system — The heartbeat does not conflict with your own schedules. It shows up in getSchedules() if you need to inspect it.

Note: keepAlive() is marked @experimental and may change between releases.

For the full API reference and when-to-use guidance, refer to Schedule tasks — Keeping the agent alive.

waitForMcpConnections

AIChatAgent now waits for MCP server connections to settle before calling onChatMessage. This ensures this.mcp.getAITools() returns the full set of tools, especially after Durable Object hibernation when connections are being restored in the background.

Other improvements

• MCP deduplication by name and URL — addMcpServer with HTTP transport now deduplicates on both server name and URL. Calling it with the same name but a different URL creates a new connection. URLs are normalized before comparison (trailing slashes, default ports, hostname case).
• callbackHost optional for non-OAuth servers — addMcpServer no longer requires callbackHost when connecting to MCP servers that do not use OAuth.
• MCP URL security — Server URLs are validated before connection to prevent SSRF. Private IP ranges, loopback addresses, link-local addresses, and cloud metadata endpoints are blocked.
• Custom denial messages — addToolOutput now supports state: "output-error" with errorText for custom denial messages in human-in-the-loop tool approval flows.
• requestId in chat options — onChatMessage options now include a requestId for logging and correlating events.

Upgrade

To update to the latest version:

npm i agents@latest @cloudflare/ai-chat@latest

Original source

Gateway Protocol Detection now supports seven additional protocols in beta

• IMAP: Internet Message Access Protocol — email retrieval
• POP3: Post Office Protocol v3 — email retrieval
• SMTP: Simple Mail Transfer Protocol — email sending
• MYSQL: MySQL database wire protocol
• RSYNC-DAEMON: rsync daemon protocol
• LDAP: Lightweight Directory Access Protocol
• NTP: Network Time Protocol

These protocols join the existing set of detected protocols (HTTP, HTTP2, SSH, TLS, DCERPC, MQTT, and TPKT) and can be used with the Detected Protocol selector in Network policies to identify and filter traffic based on the application-layer protocol, without relying on port-based identification.

If protocol detection is enabled on your account, these protocols will automatically be logged when detected in your Gateway network traffic.

For more information on using Protocol Detection, refer to the Protocol detection documentation.

Original source

Post-quantum origin support

Radar now tracks post-quantum encryption support on origin servers, provides a tool to test any host for post-quantum compatibility, and introduces a Key Transparency dashboard for monitoring end-to-end encrypted messaging audit logs.

The new Post-Quantum API provides the following endpoints:

• /post_quantum/tls/support - Tests whether a host supports post-quantum TLS key exchange.
• /post_quantum/origin/summary/{dimension} - Returns origin post-quantum data summarized by key agreement algorithm.
• /post_quantum/origin/timeseries_groups/{dimension} - Returns origin post-quantum timeseries data grouped by key agreement algorithm.

The new Post-Quantum Encryption page shows the share of customer origins supporting X25519MLKEM768, derived from daily automated TLS scans of TLS 1.3-compatible origins. The scanner tests for algorithm support rather than the origin server's configured preference.

A host test tool allows checking any publicly accessible website for post-quantum encryption compatibility. Enter a hostname and optional port to see whether the server negotiates a post-quantum key exchange algorithm.

Key Transparency

A new Key Transparency section displays the audit status of Key Transparency logs for end-to-end encrypted messaging services. The page launches with two monitored logs: WhatsApp and Facebook Messenger Transport.

Each log card shows the current status, last signed epoch, last verified epoch, and the root hash of the Auditable Key Directory tree. The data is also available through the Key Transparency Auditor API.

Learn more about these features in our blog post and check out the Post-Quantum Encryption and Key Transparency pages to explore the data.

Original source