Remote realm pinning: what happens when a tenant's realm is not declared in a remote's baseUrl?

We have a Forge app for Jira that calls a remote backend declared with region-pinned baseUrls, following Remote realm pinning. The remote computes and stores nothing, hence operations: [compute].

The manifest, abridged:

remotes:

- key: calculator

baseUrl:

default: https://<service>-uc.a.run.app # us-central1

US: https://<service>-uc.a.run.app # us-central1

EU: https://<service>-ey.a.run.app # europe-west3, Frankfurt

GB: https://<service>-nw.a.run.app # europe-west2, London

operations:

- compute

The question

At install time, what happens when the installing site’s data residency realm is one that this baseUrl object does not declare — a tenant pinned to Germany, Switzerland or Australia, say, given the manifest above?

Concretely, does the installation:

  • (a) fail, or otherwise be prevented, or
  • (b) succeed, and route that tenant’s calls to default?

We have not found this documented either way. The realm pinning page says the baseUrl defined for a region “is still used during installation if the app supports the region where the Atlassian app is provisioned”, which tells us the behaviour when the realm is supported; the manifest reference for remotes shows only US and EU in its example.

Why it matters to us

default above is a US region. If the answer is (b), a customer pinned to Germany would have their data processed in the United States without anybody having chosen that — which we would much rather refuse than do silently. If the answer is (a), an undeclared realm is a commercial decision for us (add the region when a customer needs one) rather than a correctness problem, and we would plan accordingly.

Two follow-ups

  1. If the answer is (b) — is there any supported way for an app to decline installation on a realm it does not declare, rather than falling back to default?

  2. Is there a published list of the valid realm keys for a remote’s baseUrl? We established that GB is one empirically: forge lint accepts GB and rejects an invalid key with MANIFEST_INVALID_RULE and a schema error naming regionalBaseUrl. We would rather not infer the remaining keys from the data residency location names.

Context

The app is deployed to development only, with no external installations yet. We are deciding which regions to declare before the first install, because adding a region afterwards is a major version change and a reinstall for every customer — so the cost of guessing wrong here is not recoverable later.

Hi @JoshBruen thanks for pointing out that the documentation is unclear here.

  • So for your first question, yes the answer is b. The app will be installed in the default location if its doesn’t support the site’s DaRe realm. There is no way to manually decline installation based on realm. We are planning to build a self service DaRe capability in the future in developer console where the partner could see where the installation is pinned and manually move the installation to a different region by co-ordinating directly with the customer.

  • This is a miss from our end that the realm keys are not in developer docs, we will update this soon. This is the mapping for reference

  1. EU: In-scope data is hosted within the Frankfurt and Dublin AWS regions
  2. US: In-scope data is hosted within the US East and US West AWS regions
  3. AU: In-scope data is hosted within the Sydney AWS region
  4. DE: In-scope data is hosted within the Frankfurt AWS region
  5. SG: In-scope data is hosted within the Singapore AWS region
  6. CA: In-scope data is hosted within the Canada AWS region
  7. IN: In-scope data is hosted within the Mumbai AWS region
  8. KR: In-scope data is hosted within the Seoul AWS region
  9. JP: In-scope data is hosted within the Tokyo AWS region
  10. GB: In-scope data is hosted within the London AWS region
  11. CH: In-scope data is hosted within the Zurich AWS region