Outbound requests

Notification webhooks, SMTP, Gotify/ntfy/Mattermost, self-hosted Gitea and GitLab, S3 destinations, uptime probes, git clone URLs and template sources are all targets a tenant chooses. They all go through one guard, so a tenant cannot point the panel at the cloud metadata endpoint or at another tenant's container and read the answer.

What is reachable

• Public addresses — always
• Cloud metadata (169.254/16), multicast, reserved, benchmarking, TEST-NET and IPv6 link-local or documentation ranges — never, on any setting
• The Swarm overlay as a bare IP literal — never; a service is reached by the name your organization deployed, not by address
• nixploy, nixploy-postgres, nixploy-traefik, traefik and postgres by name — never
• Other private, LAN or loopback addresses — only with Allow private network targets

The toggle

Settings → Platform → Outbound requests → Allow private network targets is instance admin only and off by default. Turning it on lets organization admins — not just you — point notification, SMTP, registry and S3 targets at hosts on the panel machine's LAN, so it is worth the extra click only for a self-hosted MinIO, Gotify, Gitea or SMTP server. Everything in the first four bullets above stays blocked either way.

Why DNS rebinding does not help

The address that passed the check is the address the socket dials, so a zero-TTL name cannot be re-pointed between the check and the connect. Transports that resolve on their own — SMTP, git, the AWS SDK — re-resolve and compare instead, and refuse when the answer moved.

Two limits outside the guard

• Uptime probes need the domains.manage capability and are capped per organization (50 by default)
• An image whose registry host is private is refused at pull time unless the application's registry row is self-hosted and its host matches — the Docker daemon does that pull from its own network position, which the panel's guard cannot cover