Skip to main content
All sandbox traffic flows through a host-controlled networking stack. From inside the VM it looks like a normal network interface; from the host side, every packet is checked against policy before it leaves.

Defaults

By default, sandboxes can reach the public internet but cannot reach private networks, loopback, link-local addresses, or cloud metadata endpoints. Only published ports accept inbound traffic. To block network access:
The TypeScript and Rust examples disable the network device. Python Network.none(), Go NetworkPolicy.None(), and CLI --no-net retain the device but deny traffic in both directions through policy.

Deployment profiles

single-tenant is the default and preserves the network configuration requested by the sandbox. multi-tenant adds a host-runtime isolation floor: traffic must pass both the platform public-network policy and the sandbox’s policy, and DNS rebinding protection is forced on. Custom DNS servers and interface overrides are removed, host CA import and published ports are disabled. Sandbox policy can further restrict this floor but cannot broaden it. The per-sandbox maxTcpConnections setting optionally limits concurrent TCP connections. maxConnections remains a deprecated TCP-only alias. When omitted, single-tenant has no connection-count cap and multi-tenant defaults to 1,024. An explicit positive value overrides either default; zero explicitly selects unlimited. These are runtime defaults, not operator-enforced ceilings. Services accepting tenant configuration must enforce their own policy on overrides. Legacy v0.6.x launch contracts keep their historical default of 256 TCP connections when the limit is omitted. The current SDK rejects explicit unlimited TCP connections, values above 4,096, or multi-tenant values above 256 when launching an older runtime because those peers cannot preserve the requested meaning. A current runtime also rejects legacy zero TCP limits: old zero meant deny all connections, not unlimited. Current-contract defaults and explicit limits are unchanged. maxUdpConnections independently limits host-side UDP relay sessions. Omission is unlimited in single-tenant mode and defaults to 1,024 in multi-tenant mode; zero explicitly selects unlimited. At a finite limit, a new session evicts the least recently active session. Sessions expire after 60 seconds of inactivity. Historical runtime launch contracts do not support an explicit UDP limit, including zero; the SDK rejects that override with an upgrade-required error instead of silently ignoring it. Each tracked TCP socket currently allocates 64 KiB for receiving and 64 KiB for sending. A ceiling of 1024 therefore requires up to 128 MiB of socket-buffer capacity per sandbox, in addition to other runtime allocations. Reserve that capacity on the host when configuring a ceiling. Selecting unlimited does not remove memory or operating-system resource constraints. Closing sockets remain tracked until their TCP state permits removal. Host file descriptors and shared egress source ports impose additional constraints. For NAT64, microsandbox evaluates destinations in configured /96 NAT64 prefixes against the embedded IPv4 address as well as the IPv6 address. The well-known 64:ff9b::/96 prefix is configured by default; add environment-specific routed prefixes only when your platform actually uses them. Custom NAT64 prefixes are supported only for local sandboxes. Cloud creation rejects non-default or empty prefix lists because the cloud API cannot carry this setting.
An operator can set an authoritative profile with the top-level deployment_profile field in ~/.microsandbox/config.json or programmatically on LocalBackend. That operator choice overrides the sandbox request on create and restart. Managed cloud create requests intentionally do not carry a deployment profile. The hosting driver selects it.

High-level profiles

For common access shapes, compose high-level profiles. Every non-empty profile set automatically adds narrow DNS access through the sandbox gateway.
The composable profiles are public, private, and host. none and all remain terminal whole-policy choices rather than profiles. Duplicate profiles are ignored, generated rules use a stable order, and explicit low-level rules can be placed before generated profile rules to override them.

Low-level custom policies

A policy has two defaults and an ordered list of rules. The first matching rule wins.
For example, this creates a deny-by-default sandbox that can make HTTPS requests to the public internet and DNS requests through the host gateway:
Rules can target groups like public, private, and host, or specific IPs, CIDRs, domains, and port ranges. See the CLI reference or your language’s SDK networking reference for exact syntax.

Hostname rules and HTTPS

Domain and domain-suffix rules start with the hostname microsandbox can observe. DNS rules see the query name, and TLS connections usually expose SNI before the encrypted session starts. That is enough to decide whether a connection may be opened, but it is not the same as seeing the HTTP request authority. For plaintext HTTP, microsandbox can inspect the Host header and require it to match the hostname that policy allowed. For HTTPS without TLS interception, or for a host that is configured to bypass interception, the HTTP Host header and HTTP/2 :authority value are encrypted. In that case microsandbox cannot prove which application hostname the request is using after the TLS session starts. Strict hostname policy mode is enabled by default: hostname allowlists fail closed unless microsandbox can inspect the request authority. In strict mode, hostname-based allow rules still work for plaintext HTTP and TLS-intercepted HTTPS. Non-intercepted HTTPS is denied when it would otherwise be allowed only by a hostname rule. IP, CIDR, group, and default allow rules are not treated as hostname-based allows. Set --net-strict=false or network.strict: false in sandbox configuration to opt out.

Port mapping

Publish a guest port when a service inside the sandbox should be reachable from the host. Published ports bind to 127.0.0.1 by default.
Use an explicit bind address, such as 0.0.0.0, only when you intentionally want to listen beyond localhost. -p 8080:80 and SDK helpers like .port(8080, 80) bind to 127.0.0.1; -p 127.0.0.1:8080:80 is the same loopback-only shape. -p 0.0.0.0:8080:80 or a specific LAN interface address makes the host listener reachable outside the machine, subject to your OS firewall and network policy. If the host starts without IPv4 or IPv6 routes, microsandbox assigns private guest addresses for published ports unless guest addresses are already configured. A specific host bind address must still exist at startup. On Windows, the first published port may trigger a Windows Defender Firewall prompt for msb.exe because the runtime opens a host listening socket. For local development, keep the bind address on 127.0.0.1. Only allow private/public network access in the firewall prompt when you intentionally bind a published port beyond loopback.

Rate limits

Network rate limits apply only to traffic crossing a sandbox’s virtual network device. They do not limit CPU, memory, disk I/O, API requests, or how many sandboxes can run. If you do not configure a limiter, microsandbox does not throttle the sandbox’s network bandwidth or packet rate. Once configured, the limiter is enforced independently for outbound (egress) and inbound (ingress) traffic. For each direction, you can configure a bandwidth bucket measured in bytes per refill interval, a packet-rate bucket measured in packets per interval, or both. An omitted direction or bucket remains unthrottled. Buckets start full, refill continuously, and can include a one-time startup burst that does not refill. Limits are set at creation and take effect on the next sandbox start.
The --net-ingress-* flags mirror the egress flags for inbound traffic (--net-ingress-bandwidth, --net-ingress-bandwidth-burst, --net-ingress-ops, --net-ingress-ops-burst). Sizes accept raw bytes plus K, M, and G suffixes; the interval defaults to one second when omitted. A frame larger than the bandwidth bucket is delivered once and the limiter then pauses long enough to pay it off, so oversized packets are throttled instead of stuck.

What a denied HTTP request sees

Denied connections fail without an HTTP response by default. Set http.deny_response to true (denyResponse(true) in TypeScript) to return a readable 403 Forbidden instead. This applies to HTTP/1.0 and HTTP/1.1 in plaintext or over HTTPS on an intercepted port (see TLS interception). The gateway never dials upstream. When enabled without a custom message, the response body is:
Enabling denial responses requires a supporting local runtime. The SDK rejects deny_response: true on older runtimes and on cloud. With it disabled, existing workflows need no new capability. An HTTP 403 is a response, not a connection error. Check the status in your client, or use curl --fail when relying on its exit code. Setting a message alone does not enable responses. Configure HTTP’s deny_message (denyMessage in TypeScript) to replace the body; {host} is substituted with the blocked hostname. Use it to name the tool or workflow your agent should use to request access.
DNS-level denies (a name matched by a deny domain rule, or a deny-by-default policy without a DNS allow) still fail at resolution with NXDOMAIN, before any HTTP exchange. HTTPS on a port that is not intercepted, or to a name on the TLS bypass list, is closed without a response: the gateway cannot answer inside a TLS session it does not terminate. HTTP/2 and non-HTTP protocols are closed without an HTTP response. The gateway buffers fragmented request lines within a fixed size and time limit; incomplete requests, silent clients, and malformed input also close without a response.

Reaching the host

From inside the sandbox, host.microsandbox.internal resolves to the host machine. The default policy denies host access, so allow the host group when a sandbox needs to call a dev server, database, or other local service.
loopback means the sandbox’s own 127.0.0.1, not your laptop’s localhost. Use host for host.microsandbox.internal.

Reference

For exact network APIs, see TypeScript, Rust, Python, or Go. For CLI flags and configuration fields, see Sandbox commands and Sandbox configuration.

Next

  • DNS: domain blocking, pinned nameservers, and query timeouts
  • Proxies: route outbound TCP and non-DNS UDP through an external SOCKS proxy
  • TLS inspection: inspect HTTPS with an auto-generated CA
  • Host sockets: connect guest applications to local host IPC without opening a TCP port
  • Security model: understand the trust boundary, and network defenses for SSRF, rebinding, and metadata protection