Allow Pie traffic safely
Create a narrow, auditable exception for Pie’s egress addresses on your preview environment, so WAF rules, bot checks, CAPTCHAs and rate limits don’t block test runs. Production keeps every control it has today. A run stopped at the edge by a challenge, a 403 or a 429 never reaches your change, so it tells you nothing about your app.
Before you start
- Get the egress addresses Pie provides for your environment
- List the preview hostnames and paths Pie must reach
- Find the WAF, CDN, API gateway, and application-level limits on those paths
- Get access to request and security logs
- Name an owner who can roll back the exception
Pie gives you the egress addresses to allow for your environment and checks them with you. Browser and mobile runs can leave from different addresses, so never copy a range from another environment or an older document. To confirm, send one real request, find it in the logs of the component that rejected it, and match its source IP to the addresses Pie gave you.
Create the edge exception
- Find every enforcement layer. Check the CDN, WAF, load balancer, API gateway, identity provider and application middleware.
- Match Pie’s source ranges. Store the ranges in the platform’s reusable IP-set or IP-list feature.
- Limit the scope. Match the preview hostname and, where practical, only the paths needed for testing.
- Skip the blocking controls. Exempt matching requests from bot challenges, managed WAF rules that produce false positives, and edge rate limits.
- Keep logging. Log matched requests, and add a label or rule name such as
pie-pr-testingso the traffic is easy to audit.
Raise the application limits
An edge allowlist doesn’t change per-user, per-token, database or third-party quotas. Raise those limits for the test tenant or identity.
Work out how many logins the planned tests need:
required authentication starts = concurrent tests x starts per test x maximum retriesCount Pie’s automatic retry too: by default, Pie reruns a failed test once to rule out a fluke. It doesn’t rerun automatically when you rerun a single test yourself or while you build a test in Pie Canvas.
Set the per-identity login limit higher than that number, with a little headroom for setup and recovery. Return Retry-After with any 429 you do send, and stop retrying after a deterministic limit failure.
What you’ll see
Run one reachability test, then check the logs at every enforcement layer.
You’re set when:
- Requests match the named Pie rule.
- No request receives a challenge,
403, or429from infrastructure. - Authentication and application authorization still run normally.
- Three repeated runs stay under backend and third-party quotas.
- A request from outside the Pie rule still receives the normal protection.
Roll back safely
Keep the exception as code where you can. To roll it back, disable the named rule or remove the Pie IP list from the rule. Don’t delete unrelated security policies.
Troubleshooting
- If a challenge still appears, another product or rule phase is active. Cloudflare Bot Fight Mode, for example, can’t be skipped by the WAF Skip action.
- If the WAF allows traffic but the API returns
429, check API-gateway, user, tenant, database, and third-party limits. - If the source IP doesn’t match, confirm proxy topology and trusted forwarded-IP settings.
- If only login fails, check identity-provider bot controls and login-specific credential-stuffing rules. Also check that the stored credential is still valid.
Still blocked? Contact support@pie.inc, or return to Test PRs for the full setup.