If your Pega Platform runs inside a corporate network protected by a firewall or outbound proxy, you need to open specific egress rules before your team can build mobile apps or deliver push notifications to end users.
There are two distinct outbound connection flows to configure — and they’re often confused with each other:
| Flow | From | To | When it happens |
|---|---|---|---|
| App build | Pega Platform server | Mobile Build Service (Pega-managed, AWS) | When a developer triggers a build in App Studio / Mobile Channel |
| Push notifications | Pega Platform server | Apple APNs / Google FCM | At runtime, every time a push notification is sent to a user’s device |
Both server-side flows originate from your Pega Platform server. Separately, end-user devices must still be able to reach your Pega Platform URL and the relevant Apple or Google push notification infrastructure. In most environments, device-side internet access is already available, but highly restricted corporate or managed-device networks may need their own APNs/FCM allowlist rules.
Part 1: Mobile Build Service (MBS)
What happens during a build
When a developer triggers a mobile app build, your Pega Platform:
- Sends the build request (app configuration, certificates, customization code) to MBS over HTTPS
- Polls MBS every few seconds for build progress
- Receives a link to the compiled binary in the final poll response (at 100%)
- Downloads the binary from AWS S3
MBS never initiates a connection back to your Pega Platform. All traffic is outbound from your server.
Endpoints to whitelist
| Endpoint | Port | Protocol | Purpose |
|---|---|---|---|
mobilebuildserver.pega.com |
443 | HTTPS | Build requests and status polling |
s3.eu-north-1.amazonaws.com |
443 | HTTPS | Binary download after build completes |
*.amazonaws.com (S3) |
443 | HTTPS | Broader S3 wildcard fallback if precise S3 allowlisting is not possible |
Use hostname-based rules, not IP-based. MBS and AWS IP addresses can change without notice. If your firewall requires IPs, use the commands below to resolve current values and plan for periodic updates.
Resolving current IPs (subject to change)
# Resolve current MBS IP addresses
dig +short mobilebuildserver.pega.com | grep -e "^[0-9]"
# Resolve current AWS S3 eu-north-1 IP ranges
curl https://ip-ranges.amazonaws.com/ip-ranges.json \
| jq -r '.prefixes[] | select(.region=="eu-north-1") | select(.service=="S3") | .ip_prefix'
Authentication mechanism
Pega Platform authenticates to MBS using username + API key (HTTP Basic Auth over HTTPS). Standard one-way TLS applies.
This means standard SSL/TLS inspection is compatible, with one caveat (see below).
SSL/TLS inspection (proxy) considerations
If your corporate proxy performs SSL inspection (MITM / traffic decryption):
- The proxy’s CA certificate must be added to the JVM truststore on your Pega Platform server. Otherwise, Pega’s JVM will reject the proxy’s certificate and throw a
PKIX path building failederror. - Alternatively, configure a proxy bypass / SSL inspection exemption for
mobilebuildserver.pega.comands3.*.amazonaws.com.
Recommended: Proxy bypass for MBS and S3 endpoints is simpler and avoids certificate chain management.
Verification commands
Run these from the machine where Pega Platform is deployed:
# Verify MBS is reachable
curl -i https://mobilebuildserver.pega.com
# Expected: "Health OK" in response body
# Verify S3 is reachable
curl -i https://s3.eu-north-1.amazonaws.com
# Expected: HTTP 403 or 200 (no error = connection works)
# Verify full TLS chain
openssl s_client -verify_return_error -connect mobilebuildserver.pega.com:443
openssl s_client -verify_return_error -connect s3.eu-north-1.amazonaws.com:443
Part 2: Push Notifications
Push notifications work differently from the build flow. When Pega Platform sends a push notification to a user’s mobile device, it does not contact the device directly. Instead, it forwards the notification to Apple’s or Google’s gateway, which then delivers it to the device.
Pega Platform server
│
├── iOS users ──► Apple APNs (api.push.apple.com)
│ │
│ ▼
│ User's iPhone
│
└── Android users ──► Google FCM (fcm.googleapis.com)
│
▼
User's Android device
The server-side push request originates from your Pega Platform server — so these endpoints must be open on your server-side firewall. Device-side APNs/FCM connectivity is a separate network path and may also need to be considered in highly restricted corporate or managed-device environments.
2a. Apple Push Notification service (APNs)
Pega Mobile Client uses the HTTP/2 API connection method.
| Endpoint | Port | Protocol | Notes |
|---|---|---|---|
api.push.apple.com |
443 | HTTPS / HTTP/2 | Production |
*.push.apple.com |
2197 | HTTPS | Alternative port (if 443 is blocked by proxy) |
Apple documentation for reference: https://support.apple.com/en-sa/101555#apns
APNs certificate requirements:
- Your Pega Platform server’s JVM must trust the APNs TLS certificate chain. This is normally covered by the default JVM truststore.
- Your APNs push certificate (uploaded in Pega Mobile Channel configuration) must be valid and not expired
- Push certificates must match the App ID / Bundle ID of your built app
2b. Google Firebase Cloud Messaging (FCM)
FCM uses OAuth 2.0 service account tokens.
| Endpoint | Port | Protocol | Notes |
|---|---|---|---|
fcm.googleapis.com |
443 | HTTPS | Main FCM endpoint (HTTP v1 API) |
accounts.google.com |
443 | HTTPS | OAuth 2.0 token endpoint (FCM uses service account auth) |
Google documentation for reference: Google FCM network configuration
Summary: Full Egress Rule Set
| Destination | Port | Direction | Required for |
|---|---|---|---|
mobilebuildserver.pega.com |
443 | Outbound | App builds |
s3.eu-north-1.amazonaws.com |
443 | Outbound | Binary downloads post-build |
api.push.apple.com |
443 | Outbound | iOS push notifications (production) |
*.push.apple.com |
2197 | Outbound | iOS push notifications (alt port) |
fcm.googleapis.com |
443 | Outbound | Android push notifications |
accounts.google.com |
443 | Outbound | FCM token refresh (OAuth 2.0) |
All rules apply to outbound TCP from Pega Platform server. No inbound rules required for any of these services.
Common Pitfalls
1. SSL inspection breaking MBS connectivity
Symptom: PKIX path building failed or BuildServerConnectionException: Can't connect to build server because of i/o error
Fix: Add proxy CA cert to JVM truststore, or create SSL inspection bypass for MBS/S3 endpoints.
2. Using HTTP instead of HTTPS for MBS
Symptom: Silent connection drop — no error, no response
Fix: Verify pega/mobilebuild/baseurl DSS is set to https://mobilebuildserver.pega.com/buildserver (not http://).
3. IP-based firewall rules becoming stale
Symptom: Builds suddenly stop working after working fine for months
Fix: Switch to hostname-based rules. If IP-based rules are mandatory, schedule quarterly reviews using the dig and curl commands above.
4. FCM token refresh blocked
Symptom: Android push notifications fail silently or with auth errors
Fix: Ensure accounts.google.com:443 is open — FCM service account tokens expire and must be refreshed periodically.
5. Expired APNs certificate
Symptom: iOS push notifications stop working, no firewall change
Fix: APNs certificates expire annually. Rotate via your Apple Developer account and re-upload in Pega Mobile Channel configuration.