IP Policies

Introduction

IP policies are named sets of caller IP ranges (office, VPN, CI provider, abusive network). Each policy either allows or blocks its ranges. You create a policy once and attach it to one or more sources by reference. Edit the policy and every attached source picks up the new ranges within a few seconds.

Manage policies under IP Policies in the dashboard. Some tiers are plan-gated; see Billing.

Allow and block

Action Effect on an attached source
Allow Only addresses in the source's allow policies can call.
Block Addresses in the source's block policies are rejected. Everyone else is unaffected unless an allow policy is also attached.

A source checks block policies first. A blocked address is rejected even when an allow policy on the same source covers it, so you can allow 10.0.0.0/8 and block 10.66.0.0/16 inside it.

A source can hold at most 64 allowed and 64 blocked entries, counted across all of its attached policies.

Create a policy

  1. Open IP Policies → Add policy.
  2. Name it and choose Allow or Block.
  3. Add one or more IPs, CIDR ranges, or ASN entries (see below).
  4. Optionally add a description for your organization.

ASN entries for dynamic IPs

Some callers have no fixed address: serverless functions, hosted CI runners, agents on a cloud provider. For those, add an entry that names the network's autonomous system number (ASN) and the country the traffic must come from:

AS16509 US
AS15169 DE

A caller matches only when both its ASN and its country match. The country is required, so one entry never covers a whole network worldwide. Use one entry per country. ASN entries mix freely with IPs and CIDRs in the same policy and count toward the same 64-entry limit.

Each source reads both values from the caller's connection. Your source's access logs show each caller's ASN, AS organization and country, so you can copy them from real traffic.

An ASN on a large cloud provider (AWS is AS16509, Google AS15169, Microsoft AS8075) covers every tenant on that cloud in that country, not just you. Treat an allow entry like this as a narrowing layer on top of access keys or caller identity, not as the only check.

Attach to a source

On the source's Access tab, turn on Restrict caller IPs and attach a policy. Rejected callers receive 403 before other auth checks and before a concurrency slot is taken.

Next steps