Author: guillaume

  • AI Search – AI Search instances now include built-in storage and namespace Workers Bindings

    New AI Search instances created after today will work differently. New instances come with built-in storage and a vector index, so you can upload a file, have it indexed immediately, and search it right away.

    Additionally new Workers Bindings are now available to use with AI Search. The new namespace binding lets you create and manage instances at runtime, and cross-instance search API lets you query across multiple instances in one call.

    Built-in storage and vector index

    All new instances now comes with built-in storage which allows you to upload files directly to it using the Items API or the dashboard. No R2 buckets to set up, no external data sources to connect first.

    const instance = env.AI_SEARCH.get("my-instance");
    // upload and wait for indexing to complete
    const item = await instance.items.uploadAndPoll("faq.md", content);
    // search immediately after indexing
    const results = await instance.search({
    messages: [{ role: "user", content: "onboarding guide" }],
    });

    Namespace binding

    The new ai_search_namespaces binding replaces the previous env.AI.autorag() API provided through the AI binding. It gives your Worker access to all instances within a namespace and lets you create, update, and delete instances at runtime without redeploying.

    // wrangler.jsonc
    {
    "ai_search_namespaces": [
    {
    "binding": "AI_SEARCH",
    "namespace": "default",
    },
    ],
    }
    // create an instance at runtime
    const instance = await env.AI_SEARCH.create({
    id: "my-instance",
    });

    For migration details, refer to Workers binding migration. For more on namespaces, refer to Namespaces.

    Cross-instance search

    Within the new AI Search binding, you now have access to a Search and Chat API on the namespace level. Pass an array of instance IDs and get one ranked list of results back.

    const results = await env.AI_SEARCH.search({
    messages: [{ role: "user", content: "What is Cloudflare?" }],
    ai_search_options: {
    instance_ids: ["product-docs", "customer-abc123"],
    },
    });

    Refer to Namespace-level search for details.

  • Artifacts – Artifacts now in beta: versioned filesystem with Git access

    Artifacts is now in private beta. Artifacts is Git-compatible storage built for scale: create tens of millions of repos, fork from any remote, and hand off a URL to any Git client. It provides a versioned filesystem for storing and exchanging file trees across Workers, the REST API, and any Git client, running locally or within an agent.

    You can read the announcement blog to learn more about what Artifacts does, how it works, and how to create repositories for your agents to use.

    Artifacts has three API surfaces:

    • Workers bindings (for creating and managing repositories)
    • REST API (for creating and managing repos from any other compute platform)
    • Git protocol (for interacting with repos)

    As an example: you can use the Workers binding to create a repo and read back its remote URL:

    # Create a thousand, a million or ten million repos: one for every agent, for every upstream branch, or every user.
    const created = await env.PROD_ARTIFACTS.create("agent-007");
    const remote = (await created.repo.info())?.remote;

    Or, use the REST API to create a repo inside a namespace from your agent(s) running on any platform:

    curl --request POST "https://artifacts.cloudflare.net/v1/api/namespaces/some-namespace/repos" --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" --header "Content-Type: application/json" --data '{"name":"agent-007"}'

    Any Git client that speaks smart HTTP can use the returned remote URL:

    # Agents know git.
    # Every repository can act as a git repo, allowing agents to interact with Artifacts the way they know best: using the git CLI.
    git clone https://x:${REPO_TOKEN}@artifacts.cloudflare.net/some-namespace/agent-007.git

    To learn more, refer to Get started, Workers binding, and Git protocol.

  • Workflows, Workers – Increased concurrency, creation rate, and queued instance limits for Workflows instances

    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 1 million 2 million

    These increases apply to all users on the Workers Paid plan. Refer to the Workflows limits documentation for more details.

    Footnotes

    1. Queued instances are instances that have been created or awoken and are waiting for a concurrency slot.

  • Workflows, Workers – Increased concurrency, creation rate, and queued instance limits for Workflows instances

    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 1 million 2 million

    These increases apply to all users on the Workers Paid plan. Refer to the Workflows limits documentation for more details.

    Footnotes

    1. Queued instances are instances that have been created or awoken and are waiting for a concurrency slot.

  • Browser Run – Browser Rendering is now Browser Run

    We are renaming Browser Rendering to Browser Run. The name Browser Rendering never fully captured what the product does. Browser Run lets you run full browser sessions on Cloudflare’s global network, drive them with code or AI, record and replay sessions, crawl pages for content, debug in real time, and let humans intervene when your agent needs help.

    Along with the rename, we have increased limits for Workers Paid plans and redesigned the Browser Run dashboard.

    We have 4x-ed concurrency limits for Workers Paid plan users:

    • Concurrent browsers per account: 30 → 120 per account
    • New browser instances: 30 per minute → 1 per second
    • REST API rate limits: recently increased from 3 to 10 requests per second

    Rate limits across the limits page are now expressed in per-second terms, matching how they are enforced. No action is needed to benefit from the higher limits.

    The redesigned dashboard now shows every request in a single Runs tab, not just browser sessions but also quick actions like screenshots, PDFs, markdown, and crawls. Filter by endpoint, view target URLs, status, and duration, and expand any row for more detail.

    Browser Run dashboard Runs tab with browser sessions and quick actions visible in one list, and an expanded crawl job showing its progress

    We are also shipping several new features:

    • Live View, Human in the Loop, and Session Recordings – See what your agent is doing in real time, let humans step in when automation hits a wall, and replay any session after it ends.
    • WebMCP – Websites can expose structured tools for AI agents to discover and call directly, replacing slow screenshot-analyze-click loops.

    For the full story, read our Agents Week blog Browser Run: Give your agents a browser.

  • Browser Run – Browser Rendering is now Browser Run

    We are renaming Browser Rendering to Browser Run. The name Browser Rendering never fully captured what the product does. Browser Run lets you run full browser sessions on Cloudflare’s global network, drive them with code or AI, record and replay sessions, crawl pages for content, debug in real time, and let humans intervene when your agent needs help.

    Along with the rename, we have increased limits for Workers Paid plans and redesigned the Browser Run dashboard.

    We have 4x-ed concurrency limits for Workers Paid plan users:

    • Concurrent browsers per account: 30 → 120 per account
    • New browser instances: 30 per minute → 1 per second
    • REST API rate limits: recently increased from 3 to 10 requests per second

    Rate limits across the limits page are now expressed in per-second terms, matching how they are enforced. No action is needed to benefit from the higher limits.

    The redesigned dashboard now shows every request in a single Runs tab, not just browser sessions but also quick actions like screenshots, PDFs, markdown, and crawls. Filter by endpoint, view target URLs, status, and duration, and expand any row for more detail.

    Browser Run dashboard Runs tab with browser sessions and quick actions visible in one list, and an expanded crawl job showing its progress

    We are also shipping several new features:

    • Live View, Human in the Loop, and Session Recordings – See what your agent is doing in real time, let humans step in when automation hits a wall, and replay any session after it ends.
    • WebMCP – Websites can expose structured tools for AI agents to discover and call directly, replacing slow screenshot-analyze-click loops.

    For the full story, read our Agents Week blog Browser Run: Give your agents a browser.

  • Cloudflare One – Introducing Cloudflare Mesh

    Cloudflare Mesh is now available (blog post). Mesh connects your services and devices with post-quantum encrypted networking, allowing you to route traffic privately between servers, laptops, and phones over TCP, UDP, and ICMP.

    Cloudflare Mesh network map showing nodes and devices connected through Cloudflare

    What Cloudflare Mesh does

    • Assigns a private Mesh IP to every enrolled device and node.
    • Enables any participant to reach any other participant by IP — including client-to-client, without deploying any infrastructure.
    • Supports CIDR routes for subnet routing through Mesh nodes.
    • Supports high availability with active-passive replicas for nodes with routes.
    • All traffic flows through Cloudflare, so Gateway network policies, device posture checks, and access rules apply to every connection.

    What changed

    • WARP Connector is now Cloudflare Mesh. Existing WARP Connectors are now called mesh nodes. All existing deployments continue to work — no migration required.
    • Peer-to-peer connectivity is now called Mesh connectivity and is part of the Cloudflare Mesh documentation.
    • Mesh node limit increased from 10 to 50 per account.
    • New dashboard experience at Networking > Mesh with an interactive network map, node management, route configuration, diagnostics, and a setup wizard.

    Get started

    Refer to the Cloudflare Mesh documentation to set up your first Mesh network.

  • Containers – Containers and Sandboxes are now generally available

    Cloudflare Containers and Sandboxes are now generally available.

    Containers let you run more workloads on the Workers platform, including resource-intensive applications, different languages, and CLI tools that need full Linux environments.

    Since the initial launch of Containers, there have been significant improvements to Containers’ performance, stability, and feature set. Some highlights include:

    The Sandbox SDK provides isolated environments for running untrusted code securely, with a simple TypeScript API for executing commands, managing files, and exposing services. This makes it easier to secure and manage your agents at scale. Some additions since launch include:

    For more information, refer to Containers and Sandbox SDK documentation.

  • Containers, Agents – Secure credential injection and dynamic egress policies for Sandboxes

    Outbound Workers for Sandboxes and Containers now support zero-trust credential injection, TLS interception, allow/deny lists, and dynamic per-instance egress policies. These features give platforms running agentic workloads full control over what leaves the sandbox, without exposing secrets to untrusted workloads, like user-generated code or coding agents.

    Credential injection

    Because outbound handlers run in the Workers runtime, outside the sandbox, they can hold secrets the sandbox never sees. A sandboxed workload can make a plain request, and credentials are transparently attached before a request is forwarded upstream.

    For instance, you could run an agent in a sandbox and ensure that any requests it makes to Github are authenticated.
    But it will never be able to accesss the credentials:

    export class MySandbox extends Sandbox {}
    MySandbox.outboundByHost = {
    "github.com": (request: Request, env: Env, ctx: OutboundHandlerContext) => {
    const requestWithAuth = new Request(request);
    requestWithAuth.headers.set("x-auth-token", env.SECRET);
    return fetch(requestWithAuth);
    },
    };

    You can easily inject unique credentials for different instances
    by using ctx.containerId:

    MySandbox.outboundByHost = {
    "my-internal-vcs.dev": async (
    request: Request,
    env: Env,
    ctx: OutboundHandlerContext,
    ) => {
    const authKey = await env.KEYS.get(ctx.containerId);
    const requestWithAuth = new Request(request);
    requestWithAuth.headers.set("x-auth-token", authKey);
    return fetch(requestWithAuth);
    },
    };

    No token is ever passed into the sandbox. You can rotate secrets in the Worker environment
    and every request will pick them up immediately.

    TLS interception

    Outbound Workers now intercept HTTPS traffic. A unique ephemeral certificate authority (CA) and private key are created for each sandbox instance. The CA is placed into the sandbox and trusted by default. The ephemeral private key never leaves the container runtime sidecar process and is never shared across instances.

    With TLS interception active, outbound Workers can act as a transparent proxy for both HTTP and HTTPS traffic.

    Allow and deny hosts

    Easily filter outbound traffic with allowedHosts and deniedHosts. When allowedHosts is set, it becomes a deny-by-default allowlist. Both properties support glob patterns.

    export class MySandbox extends Sandbox {
    allowedHosts = ["github.com", "npmjs.org"];
    }

    Dynamic outbound handlers

    Define named outbound handlers then apply or remove them at runtime using setOutboundHandler() or setOutboundByHost(). This lets you change egress policy for a running sandbox without restarting it.

    export class MySandbox extends Sandbox {}
    MySandbox.outboundHandlers = {
    allowHosts: async (req: Request, env: Env, ctx: OutboundHandlerContext ) => {
    const url = new URL(req.url);
    if (ctx.params.allowedHostnames.includes(url.hostname)) {
    return fetch(req);
    }
    return new Response(null, { status: 403 });
    },
    noHttp: async () => {
    return new Response(null, { status: 403 });
    },
    };

    Apply handlers programmatically from your Worker:

    const sandbox = getSandbox(env.Sandbox, userId);
    // Open network for setup
    await sandbox.setOutboundHandler("allowHosts", {
    allowedHostnames: ["github.com", "npmjs.org"],
    });
    await sandbox.exec("npm install");
    // Lock down after setup
    await sandbox.setOutboundHandler("noHttp");

    Handlers accept params, so you can customize behavior per instance without defining separate handler functions.

    Get started

    Upgrade to @cloudflare/[email protected] or @cloudflare/[email protected] to use these features.

    For more details, refer to Sandbox outbound traffic and Container outbound traffic.

  • Browser Rendering – Browser Rendering adds Chrome DevTools Protocol (CDP) and MCP client support

    Browser Rendering now exposes the Chrome DevTools Protocol (CDP), the low-level protocol that powers browser automation. The growing ecosystem of CDP-based agent tools, along with existing CDP automation scripts, can now use Browser Rendering directly.

    Any CDP-compatible client, including Puppeteer and Playwright, can connect from any environment, whether that is Cloudflare Workers, your local machine, or a cloud environment. All you need is your Cloudflare API key.

    For any existing CDP script, switching to Browser Rendering is a one-line change:

    const puppeteer = require("puppeteer-core");
    const browser = await puppeteer.connect({
    browserWSEndpoint:
    `wss://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/browser-rendering/devtools/browser?keep_alive=600000`,
    headers: { Authorization: `Bearer ${API_TOKEN}` },
    });
    const page = await browser.newPage();
    await page.goto("https://example.com");
    console.log(await page.title());
    await browser.close();

    Additionally, MCP clients like Claude Desktop, Claude Code, Cursor, and OpenCode can now use Browser Rendering as their remote browser via the chrome-devtools-mcp package.

    Here is an example of how to configure Browser Rendering for Claude Desktop:

    {
    "mcpServers": {
    "browser-rendering": {
    "command": "npx",
    "args": [
    "-y",
    "chrome-devtools-mcp@latest",
    "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-rendering/devtools/browser?keep_alive=600000",
    "--wsHeaders={"Authorization":"Bearer <API_TOKEN>"}"
    ]
    }
    }
    }

    To get started, refer to the CDP documentation.