403 (and still appear in your request logs), and blocked database
connections are refused at the external endpoint.
Rules are set per service, and the restriction follows the list: adding the first range
restricts the service to it, and deleting the last one (and saving) opens the service to
every IP again — there is no separate on/off switch. In slipway.yaml, an explicitly
empty ipRules: [] block remains the spelled-out lock-out: it blocks all inbound
traffic until the block is removed or ranges are added.
Inbound IP rules for web services and static sites are available on paid plans (see
Plans). Rules on a database’s external endpoint are available on every plan.
Where they apply
Traffic between services inside a project is never filtered — rules apply only to
inbound traffic from the internet. Workers and cron jobs receive no inbound traffic, so
they cannot carry rules.
Setting rules
- Console
- slipway.yaml
Open the service, then Networking, and add the ranges you want to allow. A rule
is an IPv4 address (
203.0.113.42) or CIDR range (203.0.113.0/24), with an
optional description. Changes apply to the running service immediately with no
redeploy — an edit is enforced on the very next request./32
range, and 0.0.0.0/0 allows everything (useful to keep a descriptive list around
while temporarily opening the service).
Interaction with other features
- Auth: IP rules run before the sign-in wall. A blocked IP gets a
403and never sees the sign-in page. - Previews: a PR preview of the service inherits its rules, like auth.
- Sleep: a blocked request cannot wake a sleeping service.
- Plan changes: downgrading locks the editor but never strips live rules — a restricted service stays restricted, and you can always loosen or remove rules.