Egress controls

Sandboxes exist to run real code, so outbound internet access is on by default. This page describes how that traffic is contained and attributed, and where the platform draws hard lines.

Per-VM egress via NAT

Every VM's traffic leaves through its own network namespace: packets are source-NATed to the VM's unique per-slot address before they reach the host, then masqueraded out the host's WAN interface. Two consequences matter for security:

• Attribution. Egress is attributable to a specific VM — and therefore a specific workspace — at the connection level. Abuse investigations do not have to guess which tenant generated the traffic.
• No ambient identity. A VM has no cloud service account, no instance credentials, and no access to the host's metadata service (see below). Outbound requests carry only what your code puts in them.

The full mechanism is documented in internals: networking.

Hard blocks

Three classes of traffic are dropped at the top of the host firewall chain, before any accept rule:

1. VM-to-VM traffic. A guest cannot reach another tenant's VM — not its SSH port, not its app port, not a managed database's port 5432. Cross-tenant reachability is blocked by an explicit top-of-chain drop whose ordering is pinned by unit tests.
2. Cloud metadata (link-local). The entire link-local range is dropped, so a guest cannot query the cloud metadata endpoint for host credentials. This closes the standard SSRF-to-cloud-token path by construction rather than by application-level filtering.
3. Mining-protocol egress. Outbound connections to the standard control ports used by cryptocurrency-mining pool protocols (Stratum) are blocked by default. This is an abuse control, not a billing feature: it stops the default configuration of off-the-shelf miners, which is the abuse that actually shows up on platforms that execute untrusted code. On self-hosted deployments the blocked-port list is operator-configurable.

Beyond these, egress is open: there is no outbound allowlist, and guests can reach arbitrary hosts and ports. That is a deliberate product decision — agents install packages, call APIs, and clone repositories — paired with the attribution above and active abuse monitoring.

Published egress policy

Network egress is metered but not billed on any plan, inbound or outbound, within fair use. If a workspace's traffic is wildly out of line with normal use of the product, we will contact you before doing anything about it. See billing.

Abuse response

The platform monitors per-tenant resource and traffic patterns and applies additional controls when workloads cross from "unusual" into "abusive" — for example, mining behavior that evades the default port blocks, or deploy sources associated with prior abuse. We intentionally do not publish the full detection and blocklist details; the guarantees above (tenant separation, metadata isolation, per-VM attribution) are the parts you can build on.

If you believe a control is misfiring on legitimate traffic, contact support. To report abuse originating from PandaStack infrastructure, use the contact in our security.txt.