Outbound connections

Your service can open outbound connections to the internet freely — APIs, webhooks, package registries, your own infrastructure. Two limits apply to every service, so that one compromised dependency in one app cannot get the platform’s addresses blocklisted for everyone.

Port 25 is closed

Containers cannot connect to TCP port 25 anywhere. Port 25 is the unauthenticated server-to-server mail path, and it is the one thing hosting providers suspend accounts over.

Send mail through an authenticated provider instead — this is what almost every app already does:

• An API (Resend, Postmark, SendGrid, SES): HTTPS, nothing to configure.
• SMTP submission on port 587 (STARTTLS) or 465 (implicit TLS), with your provider’s username and password. Both ports are open.

If your app is configured for port 25, change the port to 587 in its mail settings. Nothing else needs to change.

A ceiling on new connections

Each service may open up to 200 new outbound TCP connections per minute to public addresses. Connections to other services in your project, to your databases and to anything on the platform’s private network are not counted.

A normal web app never sees this: a connection to an API is reused for many requests, and a worker calling a service a few hundred times a minute does so over a handful of connections. The pattern it stops is one new connection per target — mail spam, port scanning, and cryptocurrency mining pools.

Connections over the ceiling are delayed, not refused: the first attempt is dropped and the operating system retries it a second later, so a brief burst above 200 simply slows down rather than failing. Sustained bulk traffic is throttled to roughly three new connections per second.

If you have a legitimate workload that opens connections faster than this (a crawler, say), contact support and we will raise the ceiling for that service.

If you see HTTP 451 on your service

A 451 from one of your hostnames means the Helicarrier team has suspended that service, and the response body says why — most often an abuse report about the content, or the service having written more than its container-filesystem limit (use a volume for data). Your code, data and volumes are untouched. You will have received an email; reply to it or open a support ticket, and once the cause is resolved we bring the service back with a fresh deploy.