Category: Uncategorized

  • AI Search – AI Search now has hybrid search and relevance boosting

    AI Search now supports hybrid search and relevance boosting, giving you more control over how results are found and ranked.

    Hybrid search

    Hybrid search combines vector (semantic) search with BM25 keyword search in a single query. Vector search finds chunks with similar meaning, even when the exact words differ. Keyword search matches chunks that contain your query terms exactly. When you enable hybrid search, both run in parallel and the results are fused into a single ranked list.

    You can configure the tokenizer (porter for natural language, trigram for code), keyword match mode (and for precision, or for recall), and fusion method (rrf or max) per instance:

    const instance = await env.AI_SEARCH.create({
    id: "my-instance",
    index_method: { vector: true, keyword: true },
    fusion_method: "rrf",
    indexing_options: { keyword_tokenizer: "porter" },
    retrieval_options: { keyword_match_mode: "and" },
    });

    Refer to Search modes for an overview and Hybrid search for configuration details.

    Relevance boosting

    Relevance boosting lets you nudge search rankings based on document metadata. For example, you can prioritize recent documents by boosting on timestamp, or surface high-priority content by boosting on a custom metadata field like priority.

    Configure up to 3 boost fields per instance or override them per request:

    const results = await env.AI_SEARCH.get("my-instance").search({
    messages: [{ role: "user", content: "deployment guide" }],
    ai_search_options: {
    retrieval: {
    boost_by: [
    { field: "timestamp", direction: "desc" },
    { field: "priority", direction: "desc" },
    ],
    },
    },
    });

    Refer to Relevance boosting for configuration 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.