The Pie Documentation
Pie Loop
Prepare Your App for PR Testing
Configure Your Edge Platform

Configure Your Edge Platform

Cloudflare, AWS WAF, Google Cloud Armor, Azure Front Door, and Azure Application Gateway each spell the same exception differently. Find your platform below and apply the smallest rule that covers the preview host and its test paths. Start from the egress addresses Pie provides and verifies with you during pilot setup, never a range copied from another environment, because the applicable addresses depend on the execution path.

Cloudflare

  1. Create an IP list named pie_pr_testing and add the Pie egress IP ranges.

  2. Create a custom rule that matches the IP list and preview hostname:

    (ip.src in $pie_pr_testing and http.host eq "pr.example.com")

  3. Select Skip. Skip the relevant managed WAF, Super Bot Fight Mode, and rate-limiting phases.

  4. Keep Log matching requests enabled.

  5. Place the rule before rules that block or challenge the traffic.

For Turnstile in a non-production preview, use Cloudflare’s documented test sitekey and secret. Do not automate or weaken the production challenge.

Cloudflare recommends custom Skip rules for trusted clients. The Skip action cannot bypass the basic Bot Fight Mode product. See Cloudflare’s Skip action guide and available skip options.

AWS WAF

  1. Create one IPv4 IP set and, if needed, one IPv6 IP set with the Pie egress IP ranges.
  2. Use Global scope for CloudFront. Use the matching regional scope for Application Load Balancer or API Gateway.
  3. Add an Allow rule that references the IP set and scopes the match to the preview host or paths.
  4. Give the rule a higher priority than managed-rule and rate-based blocks.
  5. Enable WAF logging and verify that Pie requests terminate on the allow rule.

For a regional resource, create the initial IP set with:

aws wafv2 create-ip-set \
  --name pie-test-runners \
  --scope REGIONAL \
  --ip-address-version IPV4 \
  --addresses <PIE_EGRESS_CIDR>

Use --scope CLOUDFRONT --region us-east-1 for CloudFront. Put the allow rule in Count mode first, confirm the observed source IP, and then change it to Allow.

Review AWS’s IP set guide and rate-based rule behavior. Check API Gateway usage plans and application throttles separately.

Google Cloud Armor

  1. Open the security policy attached to the preview backend service.
  2. Add a high-priority Allow rule in basic mode with the Pie source ranges.
  3. If the policy serves more than the preview, use advanced mode to include the preview hostname or path in the expression.
  4. Put the allow rule before deny, WAF, and rate-limiting rules.
  5. Confirm the matched rule and outcome in Cloud Armor request logs.

Create the rule in preview mode before enforcing it:

gcloud compute security-policies rules create 100 \
  --security-policy=<SECURITY_POLICY> \
  --src-ip-ranges=<PIE_EGRESS_CIDR> \
  --action=allow \
  --description="Allow Pie PR test runners" \
  --preview

Remove preview mode only after Cloud Armor logs show the expected match.

Google Cloud Armor accepts IP ranges in basic rules and supports advanced match expressions. See Create and manage security policies and configure rate limiting.

Azure Front Door

  1. Open the WAF policy attached to the preview Front Door domain.
  2. Add a custom Match rule using the source IP match variable and the Pie ranges.
  3. Add a hostname or request-path condition when the policy also protects production.
  4. Set the action to Allow and assign a lower priority number than block and rate-limit rules.
  5. Verify the allow decision in Front Door WAF logs.

Use SocketAddr for the connection address Front Door observes. Use RemoteAddr only when the logs prove that it contains the trusted original client IP.

Azure stops rule evaluation after an Allow action. See the Front Door custom-rule guide and rate-limit guide.

Azure Application Gateway

  1. Open the WAF policy attached to the preview Application Gateway.
  2. Add a custom rule with RemoteAddr, the IPMatch operator, and the Pie ranges.
  3. Add hostname or path conditions if the gateway is shared.
  4. Set the action to Allow and place the rule before blocking rules.
  5. Verify the rule in Application Gateway WAF logs.

See Microsoft’s Application Gateway custom-rule overview.

Verify on Your Platform

Whichever platform you used:

  1. Run three Pie reachability tests against the preview.
  2. Save the matched rule ID and request IDs.
  3. Confirm that no downstream layer returns 403, 429, CAPTCHA, or challenge responses.
  4. Record the rule owner, scope, and rollback procedure in your pilot readiness evidence.

With three clean runs on record, the pull request is ready for Pie Loop and its results will land in Coverage Stories.

Need Help?

Allow Pie Traffic SafelyCoverage Stories