IP Allowlisting

Use this page when your database, API, webhook receiver, or self-hosted tool is protected by a firewall, IP allowlist, private network rule, or reverse proxy policy.

Lamatic can connect to external systems through more than one network path depending on the feature you use. In practice, most teams should allowlist the Lamatic static IPs below and also include the published Cloudflare IP ranges when traffic originates from edge workers.

When you need to allowlist IPs

You may need to update your firewall or network policy when:

• Lamatic connects to your database such as PostgreSQL, MySQL, or Microsoft SQL Server
• Lamatic sends requests to your internal APIs or external applications
• Lamatic calls your webhook endpoints
• Your self-hosted tools such as n8n, Firecrawl, or similar services only accept traffic from approved source IPs
• Your cloud services use security groups, network ACLs, or IP-based access policies

Why there are multiple IP groups

Lamatic uses different infrastructure paths for different workloads:

• Global IPs cover core Lamatic platform traffic used for general external connectivity
• Data ETL IPs are dedicated static egress IPs for data sync and connector workloads
• Cloudflare worker IP ranges are relevant for Lamatic edge and worker-based traffic because Lamatic runs on Cloudflare-backed infrastructure

If you are unsure which path applies to your setup, allowlist all IPs on this page first, verify connectivity, and then narrow the policy if needed.

Lamatic IPs to allowlist

Global

Allowlist these IPs for general Lamatic outbound connectivity:

• 68.183.131.192
• 167.99.227.79

Data ETL

Allowlist these IPs for database sync, ETL, and connector workloads:

Cloudflare worker IP ranges

Lamatic edge traffic can also originate from Cloudflare worker infrastructure. If your target system uses strict IP-based rules, include the current Cloudflare IP ranges in addition to the Lamatic static IPs above.

IPv4 ranges

• 103.21.244.0/22
• 103.22.200.0/22
• 103.31.4.0/22
• 104.16.0.0/12
• 108.162.192.0/18
• 131.0.72.0/22
• 141.101.64.0/18
• 162.158.0.0/15
• 172.64.0.0/13
• 173.245.48.0/20
• 188.114.96.0/20
• 190.93.240.0/20
• 197.234.240.0/22
• 198.41.128.0/17

IPv6 ranges

• 2400:cb00::/32
• 2405:8100::/32
• 2405:b500::/32
• 2606:4700::/32
• 2803:f800::/32
• 2c0f:f248::/32
• 2a06:98c0::/29

Which IPs to use by scenario

Recommended setup steps

1. Identify every Lamatic feature that will reach your system, such as a database sync, webhook trigger, API node call, or self-hosted integration.
2. Add the required IPs and ranges from this page to your firewall, reverse proxy, security group, or network ACL.
3. Confirm the target port is open for the required protocol, such as 443, 5432, 3306, or 1433.
4. Keep TLS or SSL enabled where supported. IP allowlisting should complement transport security, not replace it.
5. Test the connection from Lamatic again.
6. Review logs on both sides to confirm the request is reaching your service.

Additional guidance

For databases

• Prefer a dedicated read-only user where possible
• Restrict access to the minimum set of schemas, tables, and ports required
• If your database is behind a bastion or SSH tunnel, update those network rules as well

For webhooks and APIs

• Make sure your WAF, API gateway, or reverse proxy trusts the same IPs
• If you use rate limiting or bot protection, create an allow rule for Lamatic traffic
• Verify that your endpoint accepts HTTPS requests and returns the expected status codes

For self-hosted services

• Apply allowlist rules at every layer that can block traffic, including load balancers, ingress controllers, host firewalls, and cloud security groups
• Re-test after infrastructure changes, certificate rotations, or firewall updates

Troubleshooting checklist

• Confirm the host, port, and DNS record are correct
• Check whether the block is happening at the firewall, proxy, VPN, or database level
• Verify SSL or TLS settings independently from the IP allowlist
• If connectivity still fails, temporarily allow all IPs from this page together to rule out a missing source range

Related docs

• API Keys
• Flow Integration
• Webhooks
• API Node
• PostgreSQL
• MySQL
• Microsoft SQL Server