Allow Pie Traffic Safely

WAF rules, bot protection, CAPTCHAs, and rate limits do their job on Pie too. A run that never reaches the changed feature because the edge answered with a challenge, a 403, or a 429 tells you nothing about your product. Create a narrow, auditable exception for Pie’s egress addresses on the preview environment, prove it works, and production keeps every control it has today.

What you’ll need:

The egress addresses Pie provides for your environment
The preview hostnames and paths Pie must reach
The WAF, CDN, API gateway, and application-level limits on those paths
Access to request and security logs
An owner who can roll back the exception

Pie provides the egress addresses your environment needs to allow and verifies them with you during pilot setup. The applicable addresses depend on the execution path, because browser and mobile runs can egress differently, so never copy a range from another environment or an older document. Send one real request, find it in the rejecting component’s logs, and confirm the observed source IP against the addresses Pie verified with you.

Step 1: Create the Edge Exception

Inventory 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 observability. Continue logging matched requests. Add a label or rule name such as pie-pr-testing so the traffic is easy to audit.

ℹ️

Use an IP exception only when the application receives the real client IP at that rule. If a proxy sits in front of the rule, confirm whether the platform evaluates the socket IP or a trusted forwarded-IP header.

Step 2: Raise the Application Limits

Edge allowlisting does not change per-user, per-token, database, or third-party quotas. Raise those limits for the dedicated test tenant or identity.

Size a bounded application login budget from the planned work:

required authentication starts = concurrent tests x starts per test x maximum retries

Set the per-identity login limit above that number, with limited headroom for setup and recovery. Return Retry-After with any 429 you do send, and stop retrying after a deterministic limit failure.

Prove the Exception Works

Run one reachability test, then inspect logs at every enforcement layer.

Success means:

Requests match the named Pie rule.
No request receives a challenge, 403, or 429 from infrastructure.
Authentication and application authorization still run normally.
Three repeated runs stay below 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 possible. To roll it back, disable the named rule or remove the Pie IP list from the rule. Do not delete unrelated security policies.

Troubleshooting

A challenge still appears: Another product or rule phase is active. Cloudflare Bot Fight Mode, for example, cannot be skipped by the WAF Skip action.
The WAF allows traffic but the API returns 429: Check API-gateway, user, tenant, database, and third-party limits.
The source IP does not match: Confirm proxy topology and trusted forwarded-IP settings.
Only login fails: Check identity-provider bot controls and login-specific credential-stuffing rules. Confirm the stored credential is still valid while you are there.

Turn the rule into concrete configuration with the Cloudflare, AWS, Google Cloud, and Azure steps.

Need Help?

Support: support@pie.inc

Make the Changed Feature Visible Configure Your Edge Platform