You’d be hard-pressed to find a modern-day enterprise that doesn’t employ distributed teams across the globe. And as you scale Atlassian tools, more and more of your distributed teams are working from your primary instance, and the physical distance between these users and the instance server can have a negative impact on performance. One customer even admitted that simple Jira actions take four times as long for employees in their Tokyo office.

The distributed team’s guide to Git mirrors

You can’t have half your users pinging you at all hours of the night because Jira isn’t as fast as they want it to be, just as it’s unfair for those same users to wait eight seconds for a Jira issue to load. This is the reason we first introduced support for distributed teams in Bitbucket with smart mirrors.

Now, we’ve added support for CDNs (content delivery networks) to our Data Center products. With a CDN, you’ll not only accelerate the experience of your geographically distributed users, but reduce the peak load on your primary application instances, boosting performance all around. CDN support is available for our Data Center editions of Jira Software 8.3, Jira Service Desk 4.3, and Confluence 7.0, and Bitbucket 6.8. Let’s take a look under the hood to see how it all works.

What do CDNs do?

CDN stands for content delivery network, a globally distributed network of edge servers that cache static resources locally, such as CSS, JavaScript, or fonts. When distributed teams work from a location that’s geographically distant from their server location, it typically means they have to wait longer for a page to be fetched, an issue to open, or a board to load. The purpose of a CDN is to speed up that response time as much as possible by distributing the static assets of these actions spatially, relative to end-users.

visual of a content delivery network showing distribution across a world map

Let’s take Jira, for example. If you look at the client-to-server requests made to load and view a Jira issue, you’ll see that roughly 80% of those requests come from static resources that can be cached and delivered by a CDN. That means the bulk of the actions that cause slow response time are delivered by a nearby edge server, improving response time and reducing the load of the primary instance.

How a CDN can improve performance

We’ve seen customers with as many as 100 and as few as three remote locations working from the same instance, and both scenarios have resulted in a drag on performance. By enabling a CDN, the first request for each static asset returns to the Jira instance and the CDN picks up the remaining static asset requests and delivers them from a nearby cache, rendering your instance faster for remote users and reducing your Jira request load.


It’s highly recommended that your load balancer, firewall, or proxy allow HTTP/2 traffic. Using HTTP/2 will allow for the best performance while using a CDN.

After initial testing for Jira, we’ve already seen encouraging results, with up to 50% improvements in response time for distributed teams. That means those users in Tokyo are loading issues twice as fast, and that makes a big difference.

bar graph showing response time with and without a CDN

We tested the performance of Jira’s “view issue” action with and without a CDN on a 350ms link, from Europe to New York over an AWS infrastructure. The results – as shown above – were eye-opening. Without a CDN, we saw average response times of 9,285ms. With the CDN enabled, we saw that average drop to 4,439ms.

Obviously, results will vary based on factors like network latency, request load, and browser cache, but integrating with a CDN could mean a huge jump in performance for your teams.

Enabling your CDN


Learn more about how to configure your CDN for Jira here.

Getting started with CDN support for your Data Center products is easy. As an admin, you’ll see “Content delivery network” in the left-hand navigation bar. Once you’ve clicked through, you’ll see the status, network statistics, and health checks under the Performance tab. To enable CDN, simply head into Settings, validate your CDN URL, and turn it on.

You’ll see that the information under the Performance tab has updated to reflect the statuses of HTTP/2 and CDN connectivity, as well as app compatibility. These health checks give you a sense of whether everything is running smoothly, and which apps rely on deprecated code that could lead to problems when caching assets.

content delivery network administration page

For those who use AWS, we’ve provided CloudFormationTemplates for AWS CloudFront, available as a single-line configuration in our updated templates. You can find all of our AWS deployment resources in this repository. Regardless, you can use any CDN, public or private, including reverse-proxy caches for those that run completely behind the firewall and cannot leverage from the Public CDN providers.


For all these use cases, you will find dedicated documentation describing how to configure your application firewall to allow CDN traffic into your cluster, supported with an example configuration for AWS Application Firewall, OR how to set up a reverse proxy caching within your bare metal infrastructure.

What’s next?

Optimizing performance at scale has always been a core tenet of our Data Center products, and CDN support goes a long way in helping achieve that. But that’s not all we’re doing to improve performance; we’ll be rolling out smart mirror farms in the coming months.


If you’re interested in learning more about Data Center, or think the time is right to make the move, start the conversation here.

CDN support is currently available with the Data Center editions of Jira Software 8.3, Jira Service Desk 4.3, and Confluence 7.0, and Bitbucket 6.8. If you’d like to learn more about how we’re building better performance for distributed teams in both CDN support and smart mirror farms, register for our upcoming webinar below.

Register for the webinar

Improve geo-performance for your distributed teams...