IP addresses and domains for Atlassian cloud apps
If you or your organization use restrictive firewall or proxy server settings, you or your network administrator may need to allowlist certain domains and IP address ranges to ensure Atlassian cloud apps and other services work as expected.
Domain names
Atlassian apps 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 apps to operate, allow these first-party Atlassian domains and their levels of subdomains. These domains are directly operated and managed by Atlassian.
Domain | Purpose |
|---|---|
| All Atlassian apps and services use this |
| All Atlassian apps and services use this |
| All Atlassian apps and services use this |
| Jira and Confluence use this |
| Jira and Confluence use this |
| Bitbucket uses this |
| Forge apps use this |
Atlassian Government Cloud domains
For Atlassian Government Cloud apps to operate, allow these first-party Atlassian domains and their levels of subdomains. These domains are directly operated and managed by Atlassian.
Domain | Purpose |
|---|---|
| For Jira and Confluence in Atlassian Government Cloud |
| For Jira and Confluence in Atlassian Government Cloud |
| For Jira and Confluence apps in Atlassian Government Cloud |
| For Jira and Confluence apps in Atlassian Government Cloud |
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 apps 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 apps and services may work without access to these domains, however some experiences may be degraded or stop functioning altogether.
Domain | Description | Purpose |
|---|---|---|
| Amazon Web Services Content Delivery Network | Used by almost all Atlassian apps to accelerate content delivery to browsers. |
| AWS WAF intelligent threat mitigation
| Used to verify browser authenticity. Required for login and usage of Atlassian cloud products. At least 3 levels of subdomain wildcarding is required. |
| CookieLaw Consent Solution | Used for Cookie Consent requests as mandated by Privacy and Data Protection laws. |
| Google Hosted Libraries Content Delivery Network | Google Hosted Libraries content distribution network for open-source JavaScript libraries used by some Atlassian apps. |
Global: If in China: | Google ReCAPTCHA Enterprise | Used to combat spam. |
| Google Social Account Login | Used if logging in using a Google account. |
| LaunchDarkly Digital Experience delivery | Used to test, evaluate and control the delivery of new app experiences. |
| Optimizely Digital Experience delivery | Used to test, evaluate and control the delivery of new app experiences. |
| Orange Logic Content Delivery Network See: https://www.orangelogic.com/features/content-generation-distribution-dam-platform | Used for public static asset delivery (for example, Atlassian logos). |
| Pendo in-app messaging service | Used by marketing to enable targeted messaging in Jira, Jira Service Management, Jira Align, Jira Product Discovery, and Confluence. |
| Pubnub Messaging Platform | Used by almost all Atlassian apps to deliver real-time events, such as live updates to ticket statues, pages and notifications. |
| Sentry.io Content Delivery Network See: https://docs.sentry.io/platforms/javascript/install/loader/ | Used to track errors and failures in app experiences. |
| Slack Integration See: https://slack.com/ | Used for integration with the Slack ecosystem. |
| Statsig See: https://docs.statsig.com/infrastructure/statsig_domains | Used to test, evaluate and control the delivery of new app experiences. |
| Twilio Segment See: https://segment.com/ | Used for analytical data collection. |
| Unsplash image library | Used by Confluence and Trello to provide visuals (e.g. head images on Confluence pages and backgrounds on Trello boards) |
| Wordpress/Gravatar Content Delivery Network | Used by some Atlassian apps to display generic or public avatars. |
IP address ranges
We 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 apps work as intended.
These addresses were last updated on April 3, 2025.
Atlassian apps and sites
Atlassian apps and sites don't have fixed individual IP addresses. Instead, they use defined ranges of IP addresses. You should allowlist these IP ranges to maintain access to Atlassian cloud apps and sites.
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-premise servers).
You’ll save time regularly checking updates to the IP ranges if you programmatically update your allowlist. See the section How do I know when the IP ranges change? for instructions on further automating system by subscribing to an AWS SNS topic.
In practice, most admins operating allowlisting systems (such as firewalls, access control lists, and security groups) are only interested in the IP ranges Atlassian apps use to make outgoing connections to other networks. For this much shorter list, see the Outgoing connections section.
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 app or service. The Atlassian app or service replies on the same connection.
An egress or outgoing connection is one made by an Atlassian app or service to a server on the internet on your behalf. For example, application links between cloud apps and on-premise servers, webhooks, and connections you request from our cloud apps to remote servers and third-party integrators, repository cloning, and checking for new emails on an email server.
Even though region information is provided, we don't recommend that customers allowlist ingress or egress networks associated with specific regions. Instead, include all networks relevant to an app and direction. This is because we’re always working to optimise our network, bringing our cloud closer to all customers by deploying additional edge regions. Due to the underlying technology of the internet, in particular unicast routing and latency-based DNS routing, these improvements can and do result in customer clients and servers seeing new Atlassian IP addresses (from published ranges tagged with region “global” in the document) over time.
This behaviour is not unique to Atlassian. For example, AWS also adds expands and adds additional IP ranges to their apps over time, including to the popular services EC2 and Cloudfront in https://ip-ranges.amazonaws.com/ip-ranges.json .
Outgoing connections
The IP address ranges for Atlassian apps and sites 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.
Atlassian apps may connect using either IPv4 or IPv6. This depends on the resolution time for the A and AAAA DNS record by our proxies. Atlassian apps and services will originate connections to the internet, remote servers, and third parties only.
Use the following lists if you are configuring any IP allowlist, server, firewall, access control list, security group, or third-party service to receive outgoing connections from Atlassian.
Outgoing connections for Atlassian apps
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 the following lists.
IPv4
Atlassian summary IPv4 ranges (preferred) | Individual IPv4 ranges used for outgoing connections |
|---|---|
13.52.5.96/28
13.200.41.128/25
13.236.8.224/28
16.63.53.128/25
18.136.214.96/28
18.184.99.224/28
18.234.32.224/28
18.246.31.224/28
43.202.69.0/25
52.215.192.224/28
104.192.136.0/21
185.166.140.0/22 | 13.52.5.96/28
13.200.41.224/28
13.236.8.224/28
16.63.53.224/28
18.136.214.96/28
18.184.99.224/28
18.234.32.224/28
18.246.31.224/28
43.202.69.96/28
52.215.192.224/28
104.192.136.240/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.140.112/28
185.166.141.112/28
185.166.142.240/28
185.166.143.240/28 |
IPv6
For IPv6, you can choose to use summary ranges or the individual Atlassian IPv6 ranges used for outgoing connections. The summary option can help if you have limited space available in your access-list or security-group and is less likely to change over time. The individual ranges option are useful if your policy or software prevents the use of a summary range.
Atlassian summary IPv6 ranges (preferred) | Individual IPv6 ranges used for outgoing connections |
|---|---|
2401:1d80:3000::/36
2406:da18:809:e04::/63
2406:da18:809:e06::/64
2406:da1c:1e0:a204::/63
2406:da1c:1e0:a206::/64
2600:1f14:824:304::/63
2600:1f14:824:306::/64
2600:1f18:2146:e304::/63
2600:1f18:2146:e306::/64
2600:1f1c:cc5:2304::/63
2a05:d014:f99:dd04::/63
2a05:d014:f99:dd06::/64
2a05:d018:34d:5804::/63
2a05:d018:34d:5806::/64 | 2401:1d80:3200::/48
2401:1d80:3204::/48
2401:1d80:3208::/48
2401:1d80:320c::/48
2401:1d80:3210::/48
2401:1d80:3214::/48
2401:1d80:3218::/48
2401:1d80:321c::/48
2401:1d80:3220::/48
2401:1d80:3224::/48
2401:1d80:3228::/48
2401:1d80:322c::/48
2401:1d80:3230::/48
2406:da18:809:e04::/63
2406:da18:809:e06::/64
2406:da1c:1e0:a204::/63
2406:da1c:1e0:a206::/64
2600:1f14:824:304::/63
2600:1f14:824:306::/64
2600:1f18:2146:e304::/63
2600:1f18:2146:e306::/64
2600:1f1c:cc5:2304::/63
2a05:d014:f99:dd04::/63
2a05:d014:f99:dd06::/64
2a05:d018:34d:5804::/63
2a05:d018:34d:5806::/64 |
Outgoing connections for Atlassian Government Cloud
Jira for Atlassian Government Cloud supports development integrations with Github, not other development tools. If your situation requires a list of IP ranges used by Atlassian only for the purpose of making outgoing connections, you can use this list:
44.220.40.160/28
18.246.188.32/28Amazon 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 allowlist IP ranges with the tags "AMAZON" or "CLOUDFRONT" from this IP ranges list to ensure Atlassian apps 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 these IPs to send notifications. You should allow the following IP ranges:
167.89.0.0/17
168.245.0.0/17
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.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
76.223.176.0/20
76.223.144.220/31
76.223.147.128/25
52.82.172.0/22
216.221.175.128/25Bitbucket and Trello
Some Atlassian apps aren’t hosted on the same atlassian.net domain as Confluence and Jira. Check these articles to find out which domains, IP address ranges, and ports you need to allow for certain apps:
Bitbucket Cloud Premium customers
If you’re a Bitbucket Cloud Premium customer and have set a custom IP allowlist, make sure you also include the IP of your Bitbucket Data Center. Control access to your private content
Confluence whiteboards
If you’re not able to allowlist *.atlassian.com, you can make http://canvas-workers.atlassian.com an allowed domain to avoid issues with Confluence whiteboards. To check your compatibility with the whiteboards editor, use our compatibility check tool.
Integrate with Data Center 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 made this feature so you don’t have to open your network for any incoming connections. Connect to Data Center instances with 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 Outgoing connections section on this page.
Instead of allowlisting these IP ranges, you can also use application tunnels to integrate with Atlassian cloud apps in your network. Application tunnels use network tunneling to forward the traffic to your network without requiring any incoming connections. See the Integrate with Data Center products section on this page.
Who has control over the IP ranges described above?
Atlassian has full control over those IP ranges. These 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 these 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 will release control over these 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 app data will most likely have a large hosting presence within the region closest to the majority the users accessing your apps. 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 in to data residency, which is currently available with the Enterprise Cloud plan and new apps 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. 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’ll 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’ll use new ranges that will be part of the Atlassian-registered netblocks (104.192.136.0/21 and 185.166.140.0/22). We’ll publish a blog post a few weeks before that change is made. All ranges, old and new, are covered by these IP ranges.
How do I know when the IP ranges change?
Whenever there is a change to the Atlassian IP ranges, we send notifications to subscribers of the atlassian-public-ip-changes SNS topic. The payload contains information in the following format and is intended for consumption by machines:
{
"creationDate":"yyyy-mm-ddThh:mm:ss.mmmmmm",
"syncToken":"1659489769",
"md5":"6a45316e8bc9463c9e926d5d37836d33",
"url":"https://ip-ranges.atlassian.com/"
}creationDate- The date and time that the IP ranges were updated at UTC in standard ISO format.syncToken- The publication time in Unix epoch time format.md5- The cryptographic hash value of the IP ranges file. You can use this value to check whether the downloaded file is corrupted.url- The location of the IP ranges file.
If you want to be notified whenever there's a change to the Atlassian IP ranges, subscribe to receive notifications using Amazon SNS.
Subscribe to notifications for Atlassian IP ranges
Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
In the navigation bar, change the Region to US East (N. Virginia) if necessary. You need to select this region because the SNS notifications that you're subscribing to were created in this region.
In the navigation pane, select Subscriptions.
Select Create subscription.
In the Create subscription dialog box:
For Topic ARN, copy the following Amazon Resource Name (ARN):
arn:aws:sns:us-east-1:745490931007:atlassian-public-ip-changesFor Protocol, choose one of the following supported protocols:
http https sqs lambda firehoseIn Endpoint, type the endpoint to receive the notification.
Select Create subscription.
You’ll be contacted on the endpoint that you specified and asked to confirm your subscription.
Notifications are subject to the availability of the endpoint. You may want to check the JSON file periodically to ensure that you have the latest ranges.
If you no longer want to receive these notifications, you can unsubscribe.
Unsubscribe from notifications for Atlassian IP ranges
Open the Amazon SNS console at https://console.aws.amazon.com/sns/v3/home.
In the navigation pane, select Subscriptions.
Select the checkbox for the subscription.
Select Actions, then Delete subscriptions.
When prompted for confirmation, select Delete.
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?
Submit a support ticket to let us know about this issue. Possible reasons for this may be:
As Atlassian combines apps, some functionalities may have different infrastructure deployment footprint, which may mean some traffic will originate from new regions.
Third-party app 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 https://ip-ranges.atlassian.com is created for machine consumption and covers all Atlassian apps for traffic from Atlassian cloud to self-hosted products and services, as well as connections from users to Atlassian cloud.
We plan to add tagging to the ranges so they can be filtered to only show the relevant ranges for each situation based on app, direction of connection, IP family, region etc.
The current IP range to enable for the migration assistants to work as expected is too wide. What are the exact Atlassian API addresses (URLs) to allow for the plugin to work?
You must allow the URLs below for the migration assistants to work. The URLs listed are subject to change and new URLs may be added. We encourage you to monitor this page for the latest changes.
If any of the listed hosts send client-side redirects to other domains (now or in the future), then we’ll remove them from the list.
For Confluence Cloud Migration Assistant communication
Address | Purpose |
|---|---|
| Upload attachments |
| Communicate with Atlassian Migration Platform |
| Check plugin version |
| Communicate with Atlassian App Migration Platform |
| Communicate with Atlassian Migration Platform |
| Communicate with Atlassian Migration Platform |
| Upload migration data |
| Upload app migration data |
| Optional: Upload app migration data - accelerated |
| Enable access to the latest UI components in the Migration Assistant |
| Enable communication to support migrations in the FedRAMP environment |
| Enable communication with your destination cloud site |
For Jira Cloud Migration Assistant communication
Address | Purpose |
|---|---|
| Upload attachments |
| Communicate with Atlassian Migration Platform |
| Check plugin version |
| Communicate with Atlassian App Migration Platform |
| Communicate with Atlassian Migration Platform |
| Communicate with Atlassian Migration Platform |
| Upload migration data |
| Upload app migration data |
| Optional: Upload app migration data - accelerated |
| Enable access to the latest UI components in the Migration Assistant |
| Enable communication with your destination cloud site |
If wildcard is not allowed, make sure to add the following URLs:
| Download migration error logs |
For Bitbucket Cloud Migration Assistant communication
Address | Purpose |
|---|---|
| Communicate with Atlassian Migration Platform |
| Check plugin version |
| Communicate with Atlassian App Migration Platform |
| Communicate with Atlassian Migration Platform |
| Communicate with Atlassian Migration Platform |
| Upload migration data |
| Upload app migration data |
| Enable communication with your destination cloud workspace |
Was this helpful?