Leading up to the launch of the Runs on Atlassian program, the Forge CLI experience of the program is now in preview.
The app you're building may be eligible for Runs on Atlassian. To know more about the program, go to the Marketplace documentation. To check if your app is eligible for Runs on Atlassian, go to the Forge CLI documentation.
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.
For more information about how the Atlassian cloud addresses the data residency needs of organizations, see Manage data residency
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:
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.
A Forge app is eligible for PINNED
status under any of the following conditions:
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.
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.
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
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.
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:
Questions | Correct 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.
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:
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.
In-scope product data refers to all data stored by an Atlassian product that can be pinned. See Understand data residency for more information.
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:
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.
Admins can pin their product data and hosted Forge app data to a number of supported locations, namely:
Data residency for KVS and Custom Entity Store will automatically include any new location that the Atlassian cloud infrastructure supports.
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.
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: