Introducing Data Residency for Connect Apps

We are happy to announce that you can now start your journey to supporting data residency on Connect. Apps can now install into a preferred region when supported, the first step of supporting data residency. Documentation can be found here.

With Atlassian data residency, Atlassian organization administrators can specify that subsets of their primary data at rest are hosted in our EU or US realms. We use the term ‘realm’ to indicate that their in-scope data is hosted within a geographical boundary.

Our current available realms are:

  • Global: In-scope data is hosted within regions determined by Atlassian. We may move data between regions as needed.
  • EU: In-scope data is hosted within the Frankfurt and Dublin AWS regions.
  • US: In-scope data is hosted within the US East and US West AWS regions.

You can find out more about Atlassian’s data residency policy here.

Customers now have the option to have their in-scope data stored in specific realms and apps can declare which regions they support by setting region-specific base URLs in their app descriptors. Atlassian will use these details when the app is installed, to route the installation request to the specified regions. Partners are free to structure their European or US realm as they need, but they will need to communicate that structure to end users.

In the future, Atlassian will be adding more guidance on requirements for partners to support data residency such as mandatory data residency policy documents, and the ability to support realm to realm migrations. The work being done for the Connect framework is happening alongside work to help Forge support data residency by utilising hosted storage. Much of the complexity from an architectural standpoint will be managed by Atlassian for Forge apps. The introduction of a new region, for example, would not require additional engineering on Forge.

For some apps remaining on the Connect platform, we are currently designing this migration process and have set out a possible plan below here. Please check it out and provide your input to shape how this will be implemented.


What is with connect apps without any “custom” data in the database and only the table from the connect framework - should this be migrated then too? or can we use then the same database?


Where is entity property data stored in Jira? I can’t really seem to tell from the Atlassian data residency policy document? Looking at User, Issue, Board and Project entity properties.

If they’re assigned to their owning object does this mean that User properties are global?


Can you use the same domain for both US and EU? The requirement is where the data is stored at rest, not where the application is served from.

It would be useful to be able to indicate data residency is supported without the need for additional domains to the existing one.

@dbenson mentions a problem of the data residency w.r.t. GDPR. GDPR is about the transfer of data, not about the storage location per se. If we, as a vendor store the data e.g. in the EU, do we also need to guard against transfer out of the EU?

@valente This might be a stupid question, but what happens if:

  1. we have an existing customer whose Jira instance is currently hosted in the EU region (because their users are there)
  2. our app doesn’t currently list hosting regions, meaning that we only offer one region (the US)
  3. therefore, our customer’s app is currently hosted in the US
  4. now we add support for the EU and US regions in our app descriptor. That naturally doesn’t change our customer’s app instance location
  5. then at some point the customer uninstalls and then reinstalls our app. Will the re-installation cause the app to be provisioned in the EU region (since that’s where Jira is provisioned), or will the Jira instance “remember” that our app was previously provisioned in the US region and thus be re-provisioned in that region, even though the Jira instance itself is in the EU region?

You can see where I’m getting: while Jira Cloud currently doesn’t support realm to realm migrations, it would be a disaster if uninstalling and then reinstalling an app resulted in the equivalent of a realm to realm migration…



Hello dbenson,

Good question.

Yes, you can. We understand that some applications store no data and that the installation for any realm would be the same domain, this functionality is available. This should still be communicated in some data residency policy.


Is this for Enterprise customers only? Or can regular Cloud customers use this as well?

Hey ademoss,

The current behaviour of Connect is as follows: If an instance is in a given realm, say the EU, and an application supports the EU and the US, it will install into the EU regardless of whether the instance is an Enterprise instance that has data residency enabled. This means that supporting multiple regions may provide a performance improve to some users. This is outlined in the docs

This may seem like customers who are not ‘paying’ for data residency support are also receiving the benefit. Our reasoning is as follows:
Data residency is both the installation of the data into the given region and the policy that accompanies it. In the future when a vendor sells data residency they will be selling the policy not just the installation. When a user goes to buy data residency in the future for your app, they will be purchasing the obligations set out in your data residency policy. A user who has installed into the EU region who had not purchased data residency would not be held to the obligations set out in your data residency policy.

This design provides additional value to vendors who support data residency by providing performance improvements to their non data resident customers as well allowing vendors to offer a new element to their product. Our team will be making more updates in the future as to the specifics of how you could market and sell data residency.

1 Like

Hey Oliver,

Thanks for your question.

What you wish to migrate is determined by what data you wish to cover with your data residency policy. If all data is maintained in the instance, and nothing is stored in the app apart from install information - make sure you communicate that in a data residency policy document. You can read Atlassian’s data residency document linked above.

Aside from the URL, is there any way to determine which region the user is in? We want to provide additional compliance, above data at rest, based on the location choice.

If not, is it possible to add an API call that gives us that location?

1 Like

Hey Daniel,

Interesting question. Entity property data is stored in the Jira database and is migrated along with the product data.

User data is not covered by the Atlassian data residency policy and is therefore not migrated. You can read about why in the “Why we don’t pin user account information data” at the link above

Just so that I understand correctly. ALL entity properties are stored in the Jira db and thus included in the data residency? Or are user entity properties on the global level?

Either way - can it be clearly documented (ie I would love to point to the atlassian document from my policy)?


Hey Marc

This will be up to your data residency policy. I would point you to the data residency policy of Atlassian to see how we deal with the movement of data and when we judge data to be “at rest” or residing in a place.

Hi @valente,
Will there be any way for a customer to know before installation that an app offers data residency, apart from a vendor saying so in their documentation?

Hey Daniel,

The user properties are the same as other entity properties i.e. stored in the Jira instance and subject to the same data residency rules as other entity properties. We will endeavour to document this.


Hello osiebenmarck,

Yes, in the future there will be a way for vendors to signal that an app offers data residency on marketplace. Currently we do not have concrete plans, but when we do will will be sure to share them in the data residency section on the developer portal.


How about @david2 's question, do we have an answer for that?

Hey Vitor and David,

We agree with @david2 that this factual scenario presents an issue, and that it will likely happen. We believe that this is within scope for Atlassian to solve, and we are currently exploring solutions.

1 Like