IP allowlist
If your database (or any SemiLayer-facing endpoint) is behind a firewall, allowlist the addresses below. Every outbound connection from SemiLayer — ingest workers reading your rows, webhook deliveries, cross-source joins, the managed SaaS query path — exits through one of these IPs.
When you need this
- Customer database behind a firewall. If your Postgres, MySQL, Mongo, or anything else has inbound rules keyed on source IP, add the addresses above.
- Webhook receivers with an allowlist. SemiLayer's event delivery leaves from the same IPs.
- Corporate proxy / zero-trust policies that enforce explicit egress destinations on third-party SaaS traffic.
When you don't need this
If you'd rather not open any inbound rule at all — not even for our IPs — run a self-hosted runner instead. The runner dials out to SemiLayer, so your database never accepts an inbound connection from us, and in the runner-local credentials mode we never even see the DB URL.
Allowlist is for firewall rules, not authentication. These addresses are public. Anyone can connect from them. Your existing auth (DB users, IP peering, VPC rules) is still the trust boundary — adding our IPs just tells the firewall to consider our connections.
Programmatic access
The live manifest is published as JSON at semilayer.dev/ips.json. Point your firewall-automation tooling at it directly instead of scraping this page.
The manifest schema is versioned ("version": 1). Breaking changes bump
the version number; additive changes do not.
Rotation policy
We commit to 60 days' written notice before changing these addresses.
Notice goes out by email to every organization owner on file and appears
as a banner on the Console for the full window. Planned rotation dates
also populate the nextScheduledRotation field on the manifest so your
automation can see it coming.
The lastRotatedAt field on each region is when that region's IPs were
last changed. If rotation is ever forced on us (provider action, address
reclaim, etc.), we still go through the 60-day window — the timeline
shortens only if the cause is active abuse of an IP by a third party,
in which case the banner will say so.
Questions
- Can I get a single static IP instead of two? No. Running two gives us a graceful-degradation path if one is ever impacted by provider routing issues; dropping to one would be a regression for everyone.
- Do these IPs send email? No. Email leaves through a separate transactional email provider — don't add these to your SPF.
- Do you offer per-region egress pools? Not yet. Today all SaaS
egress leaves
us-east1. If we add regions we'll add them to the manifest, not replace the existing entries.