Agents - Share sandbox previews through Cloudflare Tunnel
Sandboxes can now expose services running inside containers on public preview URLs through the sandbox.tunnels namespace. Supports both quick tunnels on auto-generated *.trycloudflare.com URLs and named tunnels with persistent custom domains backed by Cloudflare Tunnel.
Sandboxes can expose a service running inside the container on a public preview URL through the sandbox.tunnels namespace. The SDK uses cloudflared inside the sandbox so you can share a running service without configuring exposePort() or a custom domain.
By default, sandbox.tunnels.get(port) creates a quick tunnel ↗ on a zero-config *.trycloudflare.com URL — no Cloudflare account, DNS record, or custom domain required. This is perfect for quick development and for .workers.dev deployments.
import { getSandbox } from "@cloudflare/sandbox";
const sandbox = getSandbox(env.Sandbox, "my-sandbox");
await sandbox.startProcess("python -m http.server 8080");
const tunnel = await sandbox.tunnels.get(8080);
console.log(tunnel.url); // → https://random-words-here.trycloudflare.comimport { getSandbox } from "@cloudflare/sandbox";
const sandbox = getSandbox(env.Sandbox, "my-sandbox");
await sandbox.startProcess("python -m http.server 8080");
const tunnel = await sandbox.tunnels.get(8080);
console.log(tunnel.url); // → https://random-words-here.trycloudflare.com
Named tunnels
For more control you can create a named tunnel through sandbox.tunnels.get(port, { name }). A named tunnel binds a hostname (<name>.<your-zone>) backed by a Cloudflare Tunnel and a CNAME record on your zone resulting in something like https://my-app-preview.example.com ↗.
Unlike quick tunnels, which generate a new random URL each time, a named tunnel produces a persistent URL that survives container restarts. This makes named tunnels suitable for production use cases where you want control over the tunnel and it's origin.
const tunnel = await sandbox.tunnels.get(8080, { name: "my-app-preview" });
console.log(tunnel.url); // → https://my-app-preview.example.comconst tunnel = await sandbox.tunnels.get(8080, { name: "my-app-preview" });
console.log(tunnel.url); // → https://my-app-preview.example.com
Calling sandbox.destroy() tears down the Cloudflare Tunnel and the associated DNS record alongside the container, so you do not leave dangling tunnels or records behind.
Upgrade
To update to the latest version:
npmyarnpnpmbunnpm i @cloudflare/sandbox@latestyarn add @cloudflare/sandbox@latestpnpm add @cloudflare/sandbox@latestbun add @cloudflare/sandbox@latest
For full API details, refer to the Sandbox tunnels reference.
Source: original entry ↗
More from Cloudflare
Follow Cloudflare to get its new changes in your feed and email digest.
Cloudflare One Client for macOS 2026.8.2100.0
GA release for macOS Cloudflare One Client with improved split tunnel handling that no longer briefly blocks traffic during reconnects, support for non-RFC 1918 local IPv4 networks, faster connects with lower memory use, and numerous reliability fixes across DNS, reauthentication, and client stability.
Cloudflare One Client for Windows 2026.8.2100.0
This GA release improves split tunnel reliability, adds support for non-RFC 1918 local networks, optimizes connection performance with faster reconnections and lower memory usage, and includes numerous bug fixes for DNS, registration, and network handling. The client now features a service recovery mechanism that automatically restarts on system unlock and better handles large hosts files without blocking traffic.
Cloudflare One Client for Linux 2026.8.2100.0
New GA release for Linux with improved split tunnel handling that no longer briefly blocks traffic during reconnects, support for non-RFC 1918 local IPv4 networks, faster tunnel reconnections, and lower memory usage. Includes numerous stability and reliability fixes for DNS, reconnection behavior, and crash issues.