Product
Product Sep 14, 2026 9 min read

Sandbox networking APIs: Freestyle, E2B, Daytona, Blaxel, and Box

A practical, documentation-based comparison of sandbox ingress, egress controls, private networking, custom domains, and raw protocol access.

“Does this sandbox have networking?” is not a useful buying question. Almost every sandbox can make an HTTP request and expose a web server. The real question is how much of the network the provider lets you control through an API—and how much you have to build yourself.

That difference matters quickly. A coding agent may need to publish a preview on your own hostname, accept a webhook without making the whole sandbox public, call an API without seeing its credential, reach a private database, or run a protocol that is not HTTP.

What to look for

Start with six requirements:

  • Custom hostnames. If users will see or integrate with the URL, a provider-generated subdomain is usually not enough. Check whether the provider verifies your domain and manages TLS, or merely documents how to run your own reverse proxy.
  • Ingress authentication. Look for private-by-default routes, header tokens, expiring URLs, revocation, or a hook into your own authorization service.
  • Egress policy. Untrusted code should not automatically reach the entire internet. Check for IP, CIDR, and domain rules—and whether they are enforced outside the guest.
  • Secret injection. The strongest model lets a sandbox use API, database, or proxy credentials for approved destinations without ever receiving their plaintext values.
  • Private networking and tunnels. Sandbox-to-sandbox links, a real VPC, a managed VPN from a developer's laptop, and site-to-site routing into an existing cloud or office network are four different capabilities.
  • Protocol support. An HTTPS preview proxy is not raw TCP or UDP ingress. That distinction matters for databases, SSH, mTLS, and custom protocols.

Feature matrix

Native, documented capabilityFreestyleE2BDaytonaBlaxelBox by ASCII
Managed HTTPS URL
Gated ingress
Bring-your-own forward auth at the edge
Custom hostnames with managed TLS
Managed hostname TLS passthrough
Egress allow/deny API
Change egress policy while running
Secret injection outside the guest
Postgres credentials injected outside the guest
External SOCKS5 proxy credentials kept outside the guest
Native private sandbox network
Managed WireGuard tunnel from a laptop
Site-to-site routes into a cloud VPC or office LAN
Raw TCP/UDP public ingress

✅ means a documented platform feature. ❌ means no documented first-party API; DIY proxies, VPNs, and guest firewalls do not count.

There are also maturity and plan caveats behind some checks. E2B's request transforms and Blaxel's outbound proxy are public beta or preview. Daytona's live per-sandbox firewall updates require higher tiers, and its private link network is limited to ephemeral parent-child groups. Blaxel custom domains are a Custom-plan feature.

Why tunnels deserve two rows

Installing Tailscale or OpenVPN inside a sandbox is not the same as having a tunnel in the provider's control plane. Freestyle's WireGuard tunnel API creates a lasting client identity that can attach to multiple VPCs. Attachments can change without regenerating the client configuration. The same tunnel can run on a cloud gateway or office router and advertise remoteCidrs, giving VMs routed access to private infrastructure on the other side. Traffic arriving through the tunnel can even wake a paused or stopped VM.

Freestyle: the weird features are the point

Freestyle has the broadest native networking API in this group. Firewall rules cover TCP, UDP, and ICMP between VMs, VPCs, tunnels, CIDRs, and the public internet. TLS rules separately handle named ingress, TLS passthrough, egress routing, and credential injection.

The less common features are where it separates from a standard preview proxy:

  • Forward auth puts your product's login in front of generated applications. For every request to a custom hostname, Freestyle can call your authorization service before traffic reaches the VM. This lets a sandbox preview use the same users, teams, and session flow as the rest of your product without teaching the generated app how to authenticate. Selected cookies reach the authorizer but are stripped before the untrusted VM sees them, and failures deny access rather than falling open.
  • Database access does not require putting a database password in the agent's environment. A Postgres egress rule lets software inside the VM use an ordinary Postgres client with no password. The edge substitutes the configured user and database, completes authentication upstream, and keeps the write-only password outside the guest. A coding or migration agent can use the database account without being able to print or exfiltrate its reusable credential. The account still needs least-privilege database permissions: hiding the password does not limit what an authenticated session may do.
  • External proxies can be integrated without handing their credentials to the VM. A SOCKS5 egress rule routes sandbox traffic through a proxy you or your customer already operates while Freestyle authenticates to it at the edge. This is useful for customer-controlled egress, fixed source-IP allowlists, corporate secure web gateways, and external egress providers. The guest gets the routed connection, not a proxy username and password it can reuse elsewhere, and the rule can restrict which destination domains are allowed through it.
  • HTTP controls can change the request, not only allow it. Rules can match an exact method and path, inject destination-specific headers, and patch JSON bodies at the edge. That lets you enforce an approved model or add an API credential while keeping those policy values out of agent-controlled files, process arguments, and logs.
  • A hostname can route more than HTTP. A TLS rule can terminate ordinary HTTPS, publish Postgres or IMAP on their standard ports, route Minecraft by the hostname in its handshake, or splice SNI-matched TCP through to a certificate and mTLS policy owned by the guest. The practical value is keeping a stable, branded network identity even when the service is not a web application.
  • Private networks connect to the world outside the platform. Dual-stack VPCs isolate groups of VMs. One managed WireGuard tunnel can connect a laptop to several VPCs or turn a cloud VM or office gateway into a site-to-site router. That lets an agent reach private RDS, internal APIs, or customer infrastructure without publishing those services to the internet. Firewall rules can match the tunnel as an identity instead of relying only on its address.

Custom hostnames are first-class throughout this model. You can use a free style.dev name or a verified custom domain, including wildcards, with certificates handled at the edge.

The tradeoff is surface area. Freestyle exposes networking as several explicit resources rather than one preview URL, and its default-deny model means you have to grant ordinary setup traffic intentionally.

E2B

E2B keeps ingress simple: getHost(port) returns a predictable HTTPS hostname. A sandbox can require a per-sandbox header token, although URLs are public by default.

Its egress API supports internet on/off, IP and CIDR rules, domain allowlists, live policy changes, and beta request transforms that inject stored secrets outside the sandbox. Domain filtering is limited to HTTP on port 80 and TLS on port 443, and E2B warns that shared CDN-style infrastructure weakens it as a strict security boundary.

The notable gap is branded ingress. E2B's custom-domain guide has you run Caddy on a separate GCP VM and manage Cloudflare DNS yourself. That is a valid workaround, but not native custom-hostname support. Hosted E2B also does not expose a general private-network object; enterprise BYOC is a separate deployment model.

Daytona

Daytona has strong preview-sharing controls. A private preview accepts a header token, while a signed URL works for browsers and other clients that cannot add headers. Signed links expire and can be revoked early.

Network limits provide block-all, IPv4 CIDR, or domain allowlists. Higher tiers can update them without restarting the sandbox. Daytona's Secrets API swaps opaque placeholders for real credentials in outbound HTTPS headers, keeping plaintext outside the guest.

Daytona also supplies a native network for linked sandboxes, but it is a constrained topology: ephemeral children share a runner and network with one parent. It is not a persistent general-purpose VPC. Custom hostnames require a preview proxy you operate, so Daytona gets an X for native custom domains.

Blaxel

Blaxel's strength is preview management. A sandbox can have multiple named preview resources, each with public or private access, expiring tokens, a URL prefix, and response headers. Verified custom domains and wildcard routing are native on the Custom plan.

Its outbound proxy supports domain filtering, secret injection, and live configuration changes. The important caveat is that the feature is public preview and works through proxy environment variables and an installed CA. Software that ignores those proxy settings needs explicit configuration, so the checkmark should not be read as equivalent to a packet-level firewall.

Blaxel does not document a general private VPC or raw public TCP/UDP ingress. You can enable guest iptables and install Tailscale, but that leaves the network inside the sandbox rather than making it a platform resource.

Box by ASCII

Box has the smallest available networking surface here. Its host command exposes a port at an on.ascii.dev HTTPS URL. Routes are protected by a query-string token by default and can be made public. A Box also has a routable machine address, so you can open a guest firewall port and use raw TCP or UDP directly.

Box does not provide native custom hostnames, forward auth, managed TLS passthrough, an egress-policy API, secret injection outside the guest, a private sandbox network, or managed client and site-to-site tunnels. Implementing network controls inside the guest is a weak isolation boundary because the code being sandboxed may be able to modify or disable them.

Box is reasonable when you want a simple sandbox and don't care about networking. It is a weak fit when the networking control plane itself is part of the product requirement.

The actual decision

There are two different products hiding behind “sandbox networking.” One gives you a URL for a port. Every provider in this comparison can do that. The other gives you a network control plane: branded domains, application-aware ingress auth, enforced egress policy, private networks, tunnels, raw protocols, and credentials the guest can use but never read.

That distinction matters because the guest is the thing you do not trust. A firewall, VPN daemon, reverse proxy, or secret stored inside the sandbox is not a strong boundary if agent-controlled code can modify it, disable it, or print its configuration. The valuable controls live outside the VM and remain in force even when the workload is compromised.

If you only need a disposable web preview, networking should not decide which sandbox you buy. If the sandbox must safely touch customer data, production infrastructure, authenticated users, or external services, treat networking as its own product. Freestyle is the only provider in this comparison that covers that entire control plane natively. Every ❌ in the table is infrastructure your team must either do without or build and secure itself.

esc