Rate this page:
For more details on data residency and a glossary of terms see Manage data residency.
For information on data residency migrations, see Supporting data residency migrations
Atlassian data residency enables Atlassian organization administrators to specify where subsets of their product data at rest are hosted. Each realm contains geographical regions. Administrators can choose between the following realms:
To support data residency apps, declare realm-specific base URLs in their app descriptors. Atlassian uses these details when the app is installed, to route the installation request to the specified realms.
The change to the descriptor is not compulsory, you can choose to maintain your app as-is. However, if you choose not to support regional data storage customers with stringent realm requirements may not be able to install your app.
To enable an app to use data residency:
regionBaseUrls field to the app descriptor.The regionBaseUrls field follows the same standards as the app’s main baseUrl field. The supported region keys are “EU”, “US”, "AU", and "DE".
The URLs listed in the following example are the address of the app within the given realm, and the app will store all data at rest within that realm.
1 2{ ... "regionBaseUrls": { "US": "https://us.your.sample.app.com", "EU": "https://eu.your.sample.app.com", "AU": "https://au.your.sample.app.com", "DE": "https://de.your.sample.app.com" } }
Customers who chose a single realm require an app to list that realm in its list of supported realms. For example, a customer who chooses US data residency requires a URL that specifies the US:
1 2"regionBaseUrls": { "US": "https://us.your.sample.app.com" }
or a list of URLs that include the US:
1 2"regionBaseUrls": { "US": "https://us.your.sample.app.com", "EU": "https://eu.your.sample.app.com" }
Customers who don’t have a data residency requirement, but are provisioned in the EU, US, AU, or DE for performance reasons, install into the nearest supported realm - otherwise into the global realm. This may provide performance improvements for end users.
To support data resident customers, you may need to spin up stacks outside of your current infrastructure then create databases for EU, US, AU, or DE realms, depending on how your app is structured.
You will need to provide a data residency policy, similar to the Atlassian Data Residency policy, and update any of your other customer policies affected.
If you indicate support for a realm, it doesn't mean your app simply supports customers in that realm. It means your app only stores the relevant, in-scope data in that realm and any in-scope data that you store must be stored in that realm.
During installation time, if the product is pinned to a realm, Connect will route all traffic to that realm. If an app doesn't support that particular realm, the traffic will be routed to the global realm instead.
If the product isn't pinned to a realm, Connect will look at where the product is provisioned, known as the 'shard', and will route traffic to the corresponding realm of that shard. However, if the app doesn't support this realm, then Connect will route traffic to the global realm instead.
If an app is uninstalled, information about where the installation was, will be removed. This means a subsequent reinstallation may end up in a different realm depending on whether an app adds support for a new realm or the product is now pinned to a new or different realm.
When an app is upgraded, the app will also continue to be in the realm of when it was installed.
If an administrator pins their product to a realm after an app is installed, the app will remain in its old realm.
For example, if an app is installed into the US realm, then the product is later pinned to a realm, the traffic will still continue to be routed to the US server of the app.
Rate this page: