Cloudflare’s Developer Platform Streamlines Local Development, Expands Compute Limits
Cloudflare continues to push its developer platform forward, with a broad set of releases aimed at reducing friction between local development and production and giving developers more compute headroom. The latest batch of updates spans general availability announcements, new instance types, expanded API compatibility, and a rename for its retrieval service.
AI Search: AutoRAG’s New Name and Broader Model Support
The service formerly known as AutoRAG is now AI Search. The rename reflects a broader mission: instead of focusing solely on retrieval for LLM applications, AI Search is positioned as a fast, flexible index for content that can power a wider range of AI experiences. Recent additions like NLWeb support extend the service beyond simple retrieval.
AI Search now supports models from multiple providers, including OpenAI and Anthropic. The bring-your-own-provider-keys capability that launched for AI Gateway last month has been extended to AI Search. By attaching your own keys to the AI Gateway linked to your AI Search instance, you can use a wider selection of models for both embedding and inference tasks.
Once configured, your AI Search instance can reference the models available through your AI Gateway when making a /ai-search request:
export default {
async fetch(request, env) {
// Query your AI Search instance with a natural language question to an OpenAI model
const result = await env.AI.autorag("my-ai-search").aiSearch({
query: "What's new for Cloudflare Birthday Week?",
model: "openai/gpt-5"
});
// Return only the generated answer as plain text
return new Response(result.response, {
headers: { "Content-Type": "text/plain" },
});
},
};API updates aligned with the new name are rolling out in the coming weeks. Existing APIs will continue to be supported for now, with further details available on the AI Search Changelog and Discord.
Remote Bindings Reach General Availability for Local Development
Remote bindings for local development are now generally available, supported in Wrangler v4.37.0, the Cloudflare Vite plugin, and the @cloudflare/vitest-pool-workers package. These bindings connect to a deployed resource on your Cloudflare account instead of the locally simulated resource.
For example, you can configure Wrangler or Vite to route all requests to env.MY_BUCKET to a real, deployed R2 bucket rather than a local simulation:
{
"name": "my-worker",
"compatibility_date": "2025-09-25",
"r2_buckets": [
{
"bucket_name": "my-bucket",
"binding": "MY_BUCKET",
"remote": true
},
],
}With this configuration, Worker code still executes locally while requests to env.MY_BUCKET are proxied to the remote resource. This provides the faster execution times of local development without requiring you to seed local databases with data.
Remote bindings can be paired with environments, letting you use staging data during local development while leaving production data untouched. For instance, you can direct Wrangler or Vite to send all requests to env.MY_BUCKET to staging-storage-bucket when running wrangler dev --env staging (or CLOUDFLARE_ENV=staging vite dev with Vite):
{
"name": "my-worker",
"compatibility_date": "2025-09-25",
"env": {
"staging": {
"r2_buckets": [
{
"binding": "MY_BUCKET",
"bucket_name": "staging-storage-bucket",
"remote": true
}
]
},
"production": {
"r2_buckets": [
{
"binding": "MY_BUCKET",
"bucket_name": "production-storage-bucket"
}
]
}
}
}Node.js Compatibility Expands Further
Workers compatibility with Node.js continues to grow. Recent work added support for node:http and node:https APIs, enabling backend Express and Koa.js applications to run with only a few extra lines of code:
import { httpServerHandler } from 'cloudflare:node';
import express from 'express';
const app = express();
app.get('/', (req, res) => {
res.json({ message: 'Express.js running on Cloudflare Workers!' });
});
app.listen(3000);
export default httpServerHandler({ port: 3000 });Additional APIs now available on Workers include:
- Read and write temporary files using
node:fs - DNS lookups via 1.1.1.1 with
node:dns - Native Socket support with
node:netandnode:tls - Common hashing libraries through
node:crypto - Node-style environment variable access on
process.env
Containers: Higher Concurrency Limits and a New Instance Type
Cloudflare Containers now supports higher limits on concurrent instances. Previously capped at 50 dev instances or 25 basic instances, you can now run concurrent containers using up to 400 GiB of memory, 100 vCPUs, and 2 TB of disk. This translates to up to 1000 dev instances or 400 basic instances concurrently. Enterprise customers can scale beyond these defaults on request.
A new standard-2 instance type is also coming soon, featuring 8 GiB of memory, 1 vCPU, and 12 GB of disk. It is intended as a default option for workloads like AI Sandboxes or data processing jobs that need more resources.
Workers Builds Goes GA with More Disk and CPU
Workers Builds, the integrated CI/CD pipeline launched in open beta last Birthday Week, is now generally available. The build system has also received resource upgrades:
- Increased disk space for all plans: Disk size has grown from 8 GB to 20 GB on both free and paid plans.
- More compute for paid plans: CPU power for paid plans has doubled from 2 vCPU to 4 vCPU.
- Faster single-core and multi-core performance: Builds now run on the fastest available CPUs at execution time.
You can try Workers Builds by connecting a Git repository to an existing Worker or by using any Deploy to Cloudflare button, such as the one for the Astro blog starter template:
Dashboard Updates for Consistency
The dashboards for Durable Objects, R2, and Workers now share a more consistent design with the rest of the developer platform. The pages load faster and have improved usability.
Storage product pages now let you customize resource tables — choose which data to display, sort by any column, and hide unnecessary columns. The Workers and Pages dashboard has been decluttered and modernized for quicker access to the data you need.
When creating a new Pipeline or Hyperdrive configuration, a new guided interface walks you through each step:
Media Transformations for Video Reaches GA
Media Transformations, which brings image transformation-style processing to short-form video, is now generally available. Originally launched in open beta in March 2025, the service works with video files stored outside of Cloudflare. Since beta, input and output limits have been increased and audio-only extraction has been added.
The service targets developers with large volumes of short videos — generative AI output, e-commerce product clips, or social media content — that can be fetched directly from storage like R2 or S3, optimized quickly, and delivered as small MP4 files or used for still image and audio extraction.
https://example.com/cdn-cgi/media/<OPTIONS>/<SOURCE-VIDEO>
EXAMPLE, RESIZE:
https://example.com/cdn-cgi/media/width=760/https://pub-d9fcbc1abcd244c1821f38b99017347f.r2.dev/aus-mobile.mp4
EXAMPLE, STILL THUMBNAIL:
https://example.com/cdn-cgi/media/mode=frame,time=3s,width=120,height=120,fit=cover/https://pub-d9fcbc1abcd244c1821f38b99017347f.r2.dev/aus-mobile.mp4Media Transformations includes a free tier for all customers and is included with Media Platform subscriptions. Full details are available in the transform videos documentation.
R2 Infrequent Access reaches general availability
The Infrequent Access storage class for R2 is now generally available. Designed for data that isn’t read often — long-tail user content, logs, backups — it has already been validated in production by customers running those workloads at scale, delivering lower storage costs without sacrificing performance or durability.
Pricing remains straightforward: storage is cheaper, while retrieval is billed per gigabyte to account for the extra compute needed to serve data from storage optimized for infrequent access. As with all R2 usage, there are no egress fees — you won’t pay for bandwidth when moving data out.
You can upload an object to the Infrequent Access class from Workers like this:
export default {
async fetch(request, env) {
// Upload the incoming request body to R2 in Infrequent Access class
await env.MY_BUCKET.put("my-object", request.body, {
storageClass: "InfrequentAccess",
});
return new Response("Object uploaded to Infrequent Access!", {
headers: { "Content-Type": "text/plain" },
});
},
};Per-bucket breakdowns of Infrequent Access versus Standard usage are available in the R2 dashboard.
Browser Rendering expands: Playwright GA, Stagehand support, higher limits
Cloudflare has announced three changes to Browser Rendering:
- Playwright support is now Generally Available, synced with the latest version v1.55.
- Stagehand, an open source browser automation framework, is now supported.
- Limits for paid plans are being tripled to help developers scale.
Browsers are no longer only for humans. AI agents need to navigate the web the way a person would — booking flights, filling in forms, scraping structured data — and Playwright gives them the ability to perform those tasks. Running browsers at scale, however, is a major infrastructure problem. Browser Rendering addresses that by offering headless browsers on demand, and the GA status gives developers a production-ready base for building reliable applications.
Stagehand takes a different approach to browser automation. Instead of dictating exact steps or selectors, developers combine code with natural-language instructions powered by Workers AI. That lets agents adapt when websites change, rather than breaking on rigid selectors.
For code examples and more details on getting started with Playwright and Stagehand, see the changelog announcement.
