> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Outbound traffic and isolation

> Understand what your services can reach, and what can reach them.

Each project runs in its own network with strict policies. Other tenants cannot reach your
services, and yours cannot reach theirs.

Traffic **between your own services inside a project** is unrestricted: any port, any
protocol. The rules on this page apply to the public internet.

## Outbound TCP

TCP works normally except for a short blocklist.

| Blocked | Why |
| - | - |
| 25, 465, 587 (SMTP) | Direct mail from shared infrastructure gets the platform's IPs blacklisted. Send through a provider's HTTPS API such as Resend, SendGrid, Postmark or SES. |
| 22, 23 (SSH, telnet) | The ports credential-stuffing traffic targets. To reach a git host, use HTTPS rather than `git+ssh`. |
| 135, 139, 445, 3389 (RPC, NetBIOS, SMB, RDP) | Worm and lateral-movement ports with no outbound use from a container. |
| 3333, 4444, 5555, 7777, 14433, 14444, 45560, 45700 | Cryptomining pool ports. |

Everything else is open, including HTTP and HTTPS, every common database port, and IMAP and
POP. Reading mail is not sending it.

## Outbound UDP

UDP is closed except for **53 (DNS)** and **443 (QUIC and HTTP/3)**.

The asymmetry with TCP is deliberate. UDP is connectionless and spoofable, so open UDP
egress would let any container be used as an amplification reflector in an attack on
someone else. NTP on 123 is included in that closure, because containers take their time
from the node.

If a workload legitimately needs something on either list, [get in touch](/organization/help)
rather than working around it.

## Inbound traffic

A service is reachable from the internet only if it declares a port marked `public: true`.
Everything else is reachable by its siblings and nothing more. See
[Service to service](/networking/service-to-service).

## Edge rate limits

Plans can carry a per-client-IP request rate, with a burst allowance, and a per-client-IP
concurrent-request cap. Both are enforced at the edge for every public service, on platform
subdomains and custom domains alike.

| | Free | Hobby | Pro | Enterprise |
| - | - | - | - | - |
| Price | \$0 | \$5 / month | \$20 / seat / month | Negotiated |
| Included usage | \$5 one time | \$10 / month | \$20 / month, per workspace | Negotiated |
| Seats | 1 | 1 | Unlimited | Unlimited |
| CPU per service | 1 vCPU | 8 vCPU | 32 vCPU | Unlimited |
| Memory per service | 1 GiB | 8 GiB | 32 GiB | Unlimited |
| Build machine | 4 vCPU / 8 GiB | 8 vCPU / 16 GiB | 16 vCPU / 32 GiB | Unlimited |
| Pods per project | 6 | 12 | 24 | Unlimited |
| Running pods per org | 12 | 40 | 120 | Unlimited |
| Disk size per volume | 10 GB | 50 GB | 200 GB | 500 GB |
| Included egress | 100 GB | 500 GB | 2 TB | 10 TB |
| Logs and metrics history | 3 days | 7 days | 30 days | 30 days |
| Backup retention | Not available | 7 days | 14 days | Unlimited |
| Requests per second per IP | 25 | 100 | 250 | Unlimited |

| Capability | Free | Hobby | Pro | Enterprise |
| - | - | - | - | - |
| PR previews | Yes | Yes | Yes | Yes |
| Always-on services | No | Yes | Yes | Yes |
| Shell access | No | Yes | Yes | Yes |
| Manual scaling and autoscaling | No | Yes | Yes | Yes |
| Persistent disks | No | Yes | Yes | Yes |
| Object storage | No | Yes | Yes | Yes |
| Scheduled backups | No | Yes | Yes | Yes |
| Access controls | No | No | Yes | Yes |
| Bring your own cluster | No | No | Yes | Yes |
| Forced sleep after 5 idle minutes | Yes | No | No | No |

A client that exceeds them receives `429 Too Many Requests`. Other clients of the same
service are unaffected.

These are abuse guards against a single hot client, not a cap on how much total traffic a
service may serve. Unlimited means no edge throttle is applied.

There is no upstream response timeout at the edge, so long-lived SSE and WebSocket
connections are not cut off.

## Request size

The edge rejects a request body above 10 MB with `413`. For larger uploads, send them to
[object storage](/data/object-storage) with a presigned URL rather than through your
service.

## Resource quotas

Each project is bounded by a resource quota sized from your plan's pods-per-project cap.
The quota is a containment ceiling rather than a reservation: what you pay for is the
allocation each service actually runs at. Changing plans re-derives the quota on the next
deploy.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.