Learn about Atlassian organizations
New to administering Atlassian cloud products? Learn about Atlassian organizations and what it means to be an organization admin.
IP addresses and domains for Atlassian cloud products
If you or your organization use restrictive firewall or proxy server settings, you or your network administrator may need to allow-list certain domains and IP address ranges to ensure Atlassian cloud products and other services work as expected.
The information on this page covers all Atlassian products. However, there is some additional information specific to some products, for that see the section on Bitbucket and Trello.
Domain names
Atlassian products use domains with many levels of subdomains under all the listed top-level domains. When allowing a domain, make sure the action permits the top-level domain and multiple levels of subdomains, not just immediate subdomains.
For example, a permit entry for *.atl-paas.net should allow both avatar-management--avatars.us-west-2.prod.public.atl-paas.net AND jira-frontend-static.prod.public.atl-paas.net. Additionally, ensure that top-level domains themselves are also permitted, not just their subdomains. For example, *.atlassian.com should permit both id.atlassian.com AND atlassian.com.
Atlassian domains
For Atlassian cloud products to operate, allow these first-party Atlassian domains and their levels of subdomains. These domains are directly operated and managed by Atlassian.
Domain | Purpose |
|---|---|
*.atl-paas.net | All Atlassian products and services use this |
*.atlassian.com | All Atlassian products and services use this |
*.atlassian.net | Jira and Confluence use this |
*.jira.com | Jira and Confluence use this |
*.bitbucket.org | Bitbucket uses this |
Performance impact of TLS Interception/Inspection Proxies and Firewalls
In accordance with your security policies, strongly consider excluding the Atlassian first-party domains from TLS interception/inspection to ensure a performant experience.
Atlassian products heavily depend on features of the HTTP/2 protocol, particularly support for simultaneous transactions.
TLS interception/inspection proxies and firewalls often cause HTTP/2 to HTTP/1.1 protocol downgrades. Downgrades to HTTP/1.1 significantly degrade the performance of modern web applications by causing transactions to become serialised. Page load and experience wait times can incur noticeable delays as a result.
Partner domains
Atlassian uses third-party domains and their levels of subdomains for various purposes.
Atlassian products and services may work without access to these domains, however some in-product experiences may be degraded or stop functioning altogether.
We'll update this table when new domains are added.
Domain | Description | Purpose |
|---|---|---|
*.pndsn.com | Pubnub Messaging Platform See: | Used by almost all Atlassian products to deliver real-time events in-product, such as live updates to ticket statues, pages and notifications. |
*.cloudfront.net | Amazon Web Services Content Delivery Network | Used by almost all Atlassian products to accelerate content delivery to browsers. |
*.wp.com *.gravatar.com | Wordpress/Gravatar Content Delivery Network See: | Used by some Atlassian products to display generic or public avatars. |
*.googleapis.com | Google Hosted Libraries Content Delivery Network
| Google Hosted Libraries content distribution network for open-source JavaScript libraries used by some Atlassian products. |
*.cookielaw.org | CookieLaw Consent Solution
| Used for Cookie Consent requests as mandated by Privacy and Data Protection laws. |
*.optimizely.com | Optimizely Digital Experience delivery
| Used to test, evaluate and control the delivery of new product experiences. |
*.launchdarkly.com | LaunchDarkly Digital Experience delivery
| Used to test, evaluate and control the delivery of new product experiences. |
*.segment.io | Twilio Segment
| Analytical Data Collection |
*.sentry-cdn.com | Sentry.io Content Delivery Network
| Used to track errors and failures in product experiences. |
*.slack-edge.com | Slack Integration
| Used for in-product integration with the Slack ecosystem. |
IP address ranges
We currently use a mix of our own IP addresses and others provided by third parties (namely Amazon Web Services). You should review your network restrictions in the context of the following sections, and update them as necessary to ensure your Atlassian cloud products work as intended.
Atlassian cloud products and sites
Atlassian products and sites don't have fixed individual IP addresses, instead they use defined ranges of IP addresses. You should allow-list these IP ranges to maintain access to Atlassian cloud products and sites:
https://ip-ranges.atlassian.com
If you can update your allow list programmatically from the linked file, it'll save you from needing to check it regularly.
This list is sizable because it contains every IP range used globally by Atlassian. The IP ranges are used for both receiving and responding to requests from clients (e.g. browsers), as well as for making connections to the internet on your behalf (e.g. webhooks and application links to on-premises servers).
In practice most administrators operating allow-listing systems (such as firewalls, access control lists, and security groups) are only interested in the IP ranges Atlassian products use to make outgoing connections to other networks. For this much shorter list, see the section Outgoing Connections.
An ingress or incoming connection is one that originates from a client, such as a browser, script, app, or SSH client, for the purpose of making a request or uploading data to an Atlassian cloud product or service. The Atlassian cloud product or service replies on the same connection.
An egress or outgoing connection is one made by an Atlassian product or service to a server on the internet on your behalf. For example, application links between cloud products and on-premises servers, webhooks and connections you request from our cloud products to remote servers and third-party integrators, repository cloning, and checking for new emails on an email server.
Outgoing Connections
The IP address ranges for Atlassian cloud products and sites mentioned above include both the summary IP ranges used for ingress and egress, as well the more specific ranges used only for egress. We generally recommend using these IP address ranges when you allow our outgoing connections to contact remote networks and servers.
However, if your situation requires a simple list of the IP ranges used by Atlassian only for the purpose of making outgoing connections, you can use this list:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
13.52.5.96/28
13.236.8.224/28
18.136.214.96/28
18.184.99.224/28
18.234.32.224/28
18.246.31.224/28
52.215.192.224/28
104.192.137.240/28
104.192.138.240/28
104.192.140.240/28
104.192.142.240/28
104.192.143.240/28
185.166.143.240/28
185.166.142.240/28Atlassian products and services, with the exception of Confluence Cloud, will originate connections to the internet, remote servers, and third parties only from the above IP ranges.
Use this list if you are configuring any IP allow-list, server, firewall, access control list, security group, or third-party service to receive outgoing connections from Atlassian.
Outgoing connections from Confluence Cloud currently utilize dynamic IP addresses within the broad AWS EC2 address space listed here. Because these IP addresses change over time and come from a shared range, we don’t recommend allow-listing them permanently.
Instead, we recommend you connect to self-managed products with application tunnels.
Amazon web services and CloudFront
We use CloudFront Content Delivery Network (CDN) to deliver webpage assets to browsers as well as various Amazon Web Services. Customers employing strict network restrictions on destinations allowed for client browsers may find it necessary to allow-list IP ranges with the tags "AMAZON" or "CLOUDFRONT" from this IP ranges list to ensure Atlassian applications work properly.
You'll save time regularly checking updates to the IP ranges if you programmatically update the IP ranges you allow.
Outbound email
We use the below IPs to send notifications. You should allow the following IP ranges:
1
167.89.0.0/17, 192.174.80.0/20, 147.253.208.0/20, 168.245.0.0/17, 34.211.27.137, 34.211.27.236, 34.213.22.229, 34.249.70.175, 34.251.56.38, 34.252.236.245, 52.51.22.205, 54.187.228.111, 34.209.119.136, 34.211.27.82, 34.212.5.76, 34.253.110.0, 34.253.57.155, 35.167.157.209, 35.167.7.36, 52.19.227.102, 52.24.176.31, 54.72.208.111, 54.72.24.111, 54.77.2.231, 199.255.192.0/22, 199.127.232.0/22, 54.240.0.0/18, 69.169.224.0/20, 23.249.208.0/20, 23.251.224.0/19, 76.223.176.0/20, 54.240.64.0/19, 54.240.96.0/19, 52.82.172.0/22Bitbucket and Trello
Some of our products aren't hosted on the same atlassian.net domain as Confluence and Jira. Check the documentation for Bitbucket and Trello to find out which domains, IP address ranges, and ports you need to allow.
Integrating with Data Center or Server products
If you’re looking to integrate Atlassian cloud and self-managed products that live in your network, you can avoid allowlisting incoming connections and IP ranges by using application tunnels.
Application tunnels use network tunneling to create a secure pathway between Atlassian Cloud and the products in your network that can be used to integrate your products. We’ve made this feature specifically so you don’t have to open your network for any incoming connections.
Learn more about application tunnels
Atlassian public IP ranges FAQ
I'm integrating Jira/Confluence Cloud with self-hosted products and services. What are the IP ranges that Atlassian will use to open connections to my infrastructure?
Atlassian has a number of egress proxies which use IP ranges specifically dedicated to opening connections from Atlassian Cloud to customers and remote systems. The proxies are deployed in each AWS region where our Jira/Confluence infrastructure is deployed.
These IP ranges can be found in the section on this page titled Outgoing Connections.
Instead of allowlisting these IP ranges, you can also use application tunnels to integrate with Atlassian products in your network. Application tunnels use network tunneling to forward the traffic to your network without requiring any incoming connections. Learn more about application tunnels
Who has control over the IP ranges described above?
Atlassian has full control over those IP ranges.
The mentioned IP ranges are allocated out of the AWS-registered IP space. Those ranges have been dedicated by AWS to one of Atlassian’s AWS accounts. No other AWS customer can use those IP ranges.
The allocation/deallocation of such ranges is done using a manual process which involves a support request. It is very unlikely that Atlassian would release control over those ranges accidentally. We have monitoring in place to detect such unlikely occurrence as well.
How do I know in which region my Jira/Confluence Cloud instance resides?
Your product data will most likely have a large hosting presence within the region closest to the majority the users accessing your product. To optimize product performance, we don’t limit data movement in Cloud, and we may move data between regions as needed.
If you’re opted into data residency, which is currently available with the Enterprise Cloud plan and new products with no data for with Standard and Premium Cloud plans, you will be able to restrict the number of regions where connections from Atlassian Cloud to your infrastructure can be expected to the regions where your data is pinned to. For more information on data residency, go to Understand data residency.
Can the IP ranges change?
While we try to keep such changes to a minimum, the IP ranges may be modified. Here are situations where we may need to add or modify information about the IP ranges:
if we add AWS regions where we host Jira/Confluence Cloud, we will add a new subnet for the new region
if we deploy new instances of our egress proxies that use Atlassian-registered (provider-independent) IP space within AWS and Jira and Confluence switch over to those, we will use new ranges that will be part of the Atlassian-registered netblocks (104.192.136.0/21 and 185.166.140.0/22).
We will publish a blog post a few weeks before that change is made. Note that all ranges, old and new are covered within the already-long-documented ranges on http://ip-ranges.atlassian.com.
Do you support IPv6?
Yes, but our egress proxies will attempt to connect to the A record for the DNS name you provide before trying the AAAA record. In practice, we will use IPv6 only if your service is setup as IPv6 only. Full list of IPv6 ranges is available at https://ip-ranges.atlassian.com
I’m getting connection attempts from IP addresses outside the documented ranges. What should I do?
Please raise a support ticket with us at https://getsupport.atlassian.com to let us know about this issue. Possible reasons for this may be:
As products within the Atlassian offerings get combined, some functionalities may have different infrastructure deployment footprint which may mean some traffic would originate from new regions.
3rd-party vendor integrations may open connections from their own infrastructure, which is outside of Atlassian’s control; refer to the vendor’s documentation and support team for more information.
Why are there so many things listed on https://ip-ranges.atlassian.com/?
The list at ip-ranges.atlassian.com is aimed for machine consumption and it covers all Atlassian products for traffic from Atlassian Cloud to self-hosted as well as connections from users to Atlassian Cloud.
We have plans to add tagging to the ranges so they can be filtered to only show the relevant ranges for each situation based on product, direction of connection, IP family, region etc.
The current IP range to be enabled for the Jira / Confluence Migration Assistant to work as expected is too wide. What are the exact IP addresses to be allowed for the plugin to work?
See the following tables for the exact list of IP addresses you must allow for the plugin to work.
Listed IP addresses are subject to change. We encourage you to monitor this page for the latest changes. This page also contains the full list of domains Atlassian Cloud products require access to.
If any of the listed hosts send client-side redirects to other domains (now or in the future), then they will be removed from the list.
For CCMA communications:
Address | Function |
|---|---|
https://api.media.atlassian.com | Uploading of attachments |
https://api-private.atlassian.com | Communication with Atlassian Migration Platform |
https://marketplace.atlassian.com | Checking of plugin version |
https://api.atlassian.com | Communication with Atlassian App Migration Platform |
https://migration.atlassian.com | Communication with Atlassian Migration Platform |
https://rps--prod-east--app-migration-service--ams.s3.amazonaws.com | Uploading of app migration data |
For JCMA plugin host communication:
Address | Function |
|---|---|
https://api.media.atlassian.com | Uploading of attachments |
https://api-private.atlassian.com | Communication with Atlassian Migration Platform |
https://marketplace.atlassian.com | Checking of plugin version |
https://api.atlassian.com | Communication with Atlassian App Migration Platform |
https://migration.atlassian.com | Communication with Atlassian Migration Platform |
https://s3.us-west-2.amazonaws.com | Uploading of migration data |
https://*.s3.us-west-2.amazonaws.com | Uploading of migration data |
https://rps--prod-east--app-migration-service--ams.s3.amazonaws.com | Uploading of app migration data |
[DESTINATION_CLOUD_SITE] | Enables communication with your destination cloud site |
Was this helpful?