Last updated Jan 13, 2025

Data residency

To help partners more easily meet customer data residency needs, we have enabled data residency support for apps that use Key-Value Store (KVS) and Custom Entity Store , as well as allowing realm pinning for apps for apps that use Forge remotes.

For apps that use KVS and Custom Entity Store, Forge will take care of the hosting, pinning, and migration of hosted data between supported locations, so partners can focus on building a high quality app for their customers.

This solution is designed to work harmoniously with product data residency and consequently is based on similar concepts and terminology.

How it works

Jira and Confluence users on the Atlassian cloud can move their data to any supported location. When this occurs, the Atlassian cloud infrastructure will migrate the customer’s product data to that location.

In line with this, we have enabled data residency support for apps that choose to use KVS or Custom Entity Store. Since Forge uses a similar cloud infrastructure for its hosted storage, partners that choose to store their app’s data on KVS or Custom Entity Store will enable Forge to move that data to an admin’s chosen location.

This means that the data from both product and all Forge apps using KVS or Custom Entity Store will be hosted in the admin’s chosen location. As a result:

  • If an admin installs an Forge app using KVS or Custom Entity Store on a product that’s pinned to a location, the app will automatically be located there too.
  • If an admin migrates the data of a pinned product to a different location, then all installed, Forge apps using KVS or Custom Entity Store will also be migrated there as well.

In addition, Forge supports remote data residency. This allows you to pin remote endpoints to specific geographic regions, ensuring compliance with data residency requirements for data processed or stored outside of KVS or Custom Entity Store. By defining region-specific baseUrl values, you can align your apps with customer data residency needs.

Apps that are eligible will be shown with a PINNED status to the admin.

Forge will aim to execute its invocations from the same location as the host product. See Multi-region compute for more details.

Eligibility

A Forge app is eligible for PINNED status under any of the following conditions:

  1. All in-scope End-User Data is stored exclusively in KVS and Custom Entity Store: If your app uses only KVS or Custom Entity Store for all in-scope End-User Data, it qualifies for PINNED status without additional configuration.

  2. The app stores in-scope End-User Data remotely but uses Forge remote data residency with region-specific URLs: Apps can maintain eligibility for PINNED status if they store in-scope End-User Data in a remote backend configured with region-pinned URLs. This requires setting up the manifest file with region-specific baseUrl values and marking them with inScopeEUD: true to meet data residency requirements. For information on how to do this, see ​Remotes.

  3. The app uses a remote backend but does not store in-scope End-User Data there: f your app interacts with remote backends solely for operations that do not involve storing in-scope End-User Data, it can be eligible for PINNED status. To ensure compliance, you must configure your manifest file appropriately. For information on how to do this, see ​Remotes.

By default, Forge assumes an app stores in-scope End-User Data remotely if its manifest file includes:

In addition, when an admin initiates moving their Jira or Confluence instance to a location, they’ll see which apps can move at the same time. These may include Forge apps that are eligible for PINNED status which may move at the same time as the product

Eligible apps moving with the product

In-scope End-User Data

Forge developers will be responsible for defining, documenting, and communicating with their customers what data is in-scope and out-of-scope for data residency for their Forge app (see Atlassian’s in-scope data as an example). Admins use this list of information to understand an app’s suitability and compliance with relevant data residency regulations.

You’ll need to publish what data your app considers in-scope and out-of-scope for data residency in your own documentation.

Marketplace listing

You can leverage the Atlassian Marketplace to advertise the app’s support for data residency (specifically, its eligibility for PINNED status).

You can do this through your app’s Atlassian Marketplace listing. Specifically, when providing your app’s Privacy and Security information, respond accordingly to the following questions:

QuestionsCorrect option
Does your app support data residency options? Yes. App supports data residency

(You must fill out the details based on your app)
Does your app support migration of in-scope End User Data between your data residency supported locations?Yes.

(If your app is not using Forge remotes for storing in-scope Und User Data)

Upon updating this information, it will be available on your app’s Privacy and Security tab. For more information, see Privacy and Security tab in your Marketplace listing.

PINNED product status

When an admin moves their Jira or Confluence data to a location, that product’s Product status will then appear as PINNED in the admin’s Data residency interface:

Product pinned to Europe

The PINNED product status lets admins verify that their product’s in-scope product data is hosted on the chosen location. You can learn more about how admins pin their product data in ​ Move product data to another location.

PINNED app status

After an admin verifies that their product data is pinned to a location, they also need to verify that all in-scope end-user data for an app is also pinned. Apps pinned to the same location as the product will be displayed as PINNED in the admin's Data residency interface:

App pinned to same location as product

The PINNED app status provides admins with the verification that an app’s data is hosted in the same location as the product.

When an admin installs an eligible Forge app on a product that is already PINNED, the app will automatically be displayed as PINNED as well.

Supported locations

Admins can pin their product data and hosted Forge app data to a number of supported locations, namely:

  • Global: In-scope data is hosted within realms determined by Atlassian: data may be moved between realms as needed.
  • EU: In-scope data is hosted within the Dublin AWS regions.
  • US: In-scope data is hosted within the US East and US West AWS regions.
  • AU: In-scope data is hosted within the Sydney AWS region.
  • DE: In-scope data is hosted within the Frankfurt AWS region.
  • SG: In-scope data is hosted within the Singapore AWS region
  • CA: In-scope data is hosted within the Canada AWS region
  • IN: In-scope data is hosted within the Mumbai AWS region
  • KR: In-scope data is hosted within the Seoul AWS region
  • JP: In-scope data is hosted within the Tokyo AWS region
  • GB: In-scope data is hosted within the London AWS region
  • CH: In-scope data is hosted within the Zurich AWS region

Data residency for KVS and Custom Entity Store will automatically include any new location that the Atlassian cloud infrastructure supports.

Multi-region compute

Forge will aim to execute its invocations from the same location as the host product. This helps Forge optimize for an app’s reliability and performance (as well as facilitate security and fraud prevention).

To support some Atlassian cloud capabilities and maintain overall reliability, Forge may sometimes execute an app’s invocation from a location other than the location where the host product is.

Observability

Tracking, logging, and auditing is an integral part of supporting data residency. The Developer Console provides audit log features that will allow you to do this; these features provide records for related events (such as when an admin pins their product and app to a location).

Rate this page: