Bitbucket Pipelines using IPs not listed in official IP whitelist documentation

Question

My Bitbucket Pipelines are connecting from IP addresses that are not included in the official IP whitelist documentation, causing deployment failures to servers with IP-based firewall rules. Details I'm attempting to deploy to a cPanel server that requires SSH connections to come from whitelisted IP addresses. According to the official documentation: https://support.atlassian.com/bitbucket-cloud/docs/what-are-the-bitbucket-cloud-ip-addresses-i-should-use-to-configure-my-corporate-firewall/ I should whitelist the provided IP ranges for Bitbucket Pipelines to work. The Problem Over multiple pipeline runs, I've observed the following IPs being used: * 13.220.249.XXX (observed today) * 98.81.68.XXX (observed yesterday - multiple runs) Neither of these IPs are contained in any of the published ranges, including: * 104.192.136.0/21 * 185.166.140.0/22 * 34.199.54.113/32 * 34.232.25.90/32 * 34.232.119.183/32 * 34.236.25.177/32 * (and all other ranges in the documentation) How I Verified I used this pipeline step to capture the outgoing IP: yaml- step: name: "Check Outgoing IP" script: - apt-get update && apt-get install -y curl - echo "Pipeline IP:" - curl -s ifconfig.me Questions * Why are Bitbucket Pipelines using IPs not listed in the official documentation? * Is the documentation outdated or incomplete? * Are there additional IP ranges that should be whitelisted but aren't documented? * How can I reliably whitelist Bitbucket Pipelines when the IPs used don't match the published ranges?

Jason Stewart_ag3i34 · Accepted Answer

This is the responce I got back from Claud - using deep research - just incase someone comes across the same issue

# Bitbucket Pipelines Now Uses AWS-Wide IP Ranges by Design

**The IP addresses you're seeing (13.220.249.XXX, 98.81.68.XXX) are legitimate Bitbucket Pipeline IPs**—this isn't a bug or documentation error. On September 17, 2024, Atlassian migrated all 1x/2x Pipeline step sizes to a new runtime infrastructure that uses the **entire AWS EC2 IP pool** for us-east-1 and us-west-2 regions. The limited IP ranges listed in documentation now **only work with 4x/8x steps** using a specific opt-in configuration.

This change effectively makes predictable IP whitelisting a paid feature. Your options are to upgrade to larger step sizes with the `atlassian-ip-ranges` flag, deploy self-hosted runners with static IPs, or implement alternative authentication methods.

## The September 2024 runtime migration fundamentally changed IP behavior

Before September 17, 2024, Bitbucket Pipelines 1x/2x steps used a limited, documented set of roughly **25 IP addresses** that could be reasonably whitelisted. After the migration, these same step sizes now pull from any IP within AWS's massive EC2 pool across two regions—representing **over 4,000 CIDR blocks**. Atlassian explicitly states in their updated documentation: "We do not recommend using these IP ranges as a security control."

The specific IPs you observed (**13.220.249.XXX** and **98.81.68.XXX**) fall within valid AWS us-east-1 EC2 allocations. Running `curl ifconfig.me` in your pipeline would confirm the outbound IP varies between builds because containers are now provisioned dynamically across AWS infrastructure.

Atlassian's official documentation was updated to reflect this reality, but many users missed the critical detail: the familiar IP list (34.199.54.113/32, 34.232.25.90/32, etc.) now requires **both** a 4x/8x step size **and** explicit opt-in via configuration. An Atlassian team member confirmed in November 2024 community posts: "We have recently updated our 1x/2x size option builds to operate from new, broader IP ranges. If you need your pipeline builds to operate from a more limited set of IP addresses, consider using the `atlassian-ip-ranges` configuration available with our 4x/8x steps."

## Using restricted IP ranges requires 4x/8x steps with opt-in configuration

To deploy from predictable, whitelistable IP addresses, you must upgrade to larger step sizes and enable the `atlassian-ip-ranges` runtime option:

```yaml
pipelines:
default:
- step:
size: 4x
runtime:
cloud:
atlassian-ip-ranges: true
script:
- scp -o StrictHostKeyChecking=no ./build/* deploy@your-server:/path
```

When this configuration is enabled, outbound traffic originates from approximately **27 specific IPs** listed in Atlassian's documentation, including 34.233.65.54, 34.196.8.197, 44.194.7.14, and the ranges like 34.199.54.113/32 through 52.72.137.240/32.

**The trade-off is significant**: 4x steps consume four times your build minutes per second of execution, and require a paid Bitbucket Cloud plan (Standard or Premium). For organizations running frequent deployments, this cost can add up quickly.

## Self-hosted runners provide the best IP control without per-minute charges

Deploying your own runner gives you **complete control over outbound IPs** with no build minute consumption. You provision a server (EC2 instance, VPS, or on-premises machine) with a known static IP, whitelist that single IP on your cPanel server, and configure pipelines to use the runner.

**Setting up a Linux Docker runner:**

1. Navigate to Repository settings → Pipelines → Runners
2. Click "Add runner" and select Linux
3. Copy the provided Docker command containing your authentication credentials
4. Run the command on your server to register the runner

```yaml
pipelines:
default:
- step:
runs-on:
- 'self.hosted'
- 'linux'
script:
- ssh deploy@your-cpanel-server 'cd /home/deploy && ./update.sh'
```

Self-hosted runners require a 64-bit Linux system with minimum 8GB RAM and Docker installed. Atlassian allows up to **100 runners per workspace**, making this scalable for teams with multiple projects. The initial infrastructure investment pays off for organizations with strict security requirements or high pipeline volume.

## Alternative approaches when upgrading isn't feasible

**SSH tunneling through a bastion host** works when you control an intermediate server with a whitelisted IP. Your pipeline connects to the bastion, which then forwards traffic to your cPanel server:

```yaml
script:
- ssh -J user@bastion-host deploy@cpanel-server './deploy.sh'
```

**Cloudflare Tunnel eliminates inbound port exposure entirely**. Install `cloudflared` on your cPanel server, create a tunnel, and your server initiates outbound-only connections to Cloudflare's network. Pipelines then connect through Cloudflare's Zero Trust infrastructure without needing any IP whitelisting on your firewall.

**Webhook-triggered pull deployments invert the connection direction**. Instead of your pipeline pushing to the server, configure a webhook that triggers your server to pull the latest code:

```yaml
script:
- curl -X POST https://your-server/deploy-webhook -H "X-Secret: $WEBHOOK_SECRET"
```

**OIDC authentication** is Atlassian's explicitly recommended approach. Rather than relying on IP-based security, use OpenID Connect tokens that pipelines can present to your infrastructure. While this doesn't directly solve SSH access to cPanel, it works well for cloud resources like AWS, Azure, and GCP.

## Community reports confirm widespread impact since late 2024

Multiple threads on the Atlassian Community forums from November 2024 document identical symptoms. Users reported sudden deployment failures after years of working configurations, with observed IPs like 35.174.153.169 and 3.82.205.34 not matching any documented ranges. Atlassian staff consistently directed users to the runtime migration announcement and recommended either upgrading to 4x/8x steps or implementing self-hosted runners.

The confusion stems partly from documentation structure—the IP ranges table appears prominently without immediately clear context that it applies only to specific configurations. Users reasonably assumed the listed ranges covered all Pipeline traffic, when they now only cover the opt-in 4x/8x scenario.

## Practical recommendation for cPanel SSH deployments

For your specific use case—deploying to a cPanel server via SSH—the **most cost-effective solution is a self-hosted runner** on a small VPS or EC2 instance. A $5-10/month server with a static IP provides:

- Single IP to whitelist on cPanel's firewall
- Zero build minute consumption
- Full control over the deployment environment
- No dependency on Atlassian's infrastructure changes

If self-hosting isn't viable, enabling `atlassian-ip-ranges` on 4x steps works but multiplies your build costs. As a temporary workaround, some teams implement just-in-time whitelisting—detecting the pipeline's IP via `curl ifconfig.me`, adding it to the firewall via API, deploying, then removing it—though this adds complexity and potential race conditions.

## Conclusion

The IP discrepancy you encountered reflects an intentional architectural change by Atlassian, not incomplete documentation. Limited IP whitelisting now requires explicit opt-in with larger (and more expensive) step sizes. For organizations dependent on IP-based firewall rules, self-hosted runners offer the most sustainable path forward, providing both predictable IPs and elimination of per-minute charges. The shift signals Atlassian's broader move toward identity-based security (OIDC) over network-based controls—a direction worth considering for long-term infrastructure planning.