From today, a Forge app no longer has to declare every external domain it talks to before you install it. It can ask your admin for a new destination at runtime, and the answer is a modal. That is better governance than the manifest ever gave you, and it is also a new place to make a mistake.
What changed on 12 October 2026
Atlassian’s developer changelog entry of 12 October makes three Forge capabilities generally available: dynamic modules, customer-managed egress and customer-managed remotes. The first is mostly a developer story. The other two are an admin story, and the Forge documentation says so in one sentence: they “let customers and admins control which external services your app can talk to, and when those connections are enabled.”
Until now, a Forge app listed every external destination in its manifest, you reviewed that list once at install, and that was the data-flow conversation. Now an app can ship with permissions.external.configurable.enabled: true and request destinations per installation, which means the conversation moves from install time to run time, and from the Marketplace listing to your own console.
Egress and remotes are two different asks
- Egress is a list of external domains the app’s front end or back end may call. An app can hold up to 10 egress groups per installation, 10 domains per group, and the combined total of static plus customer-managed egress entries is capped at 40 (backend fetch egress excluded).
- A remote is the app’s own backend endpoint. Customer-managed remotes let your admin set the endpoint URL, which is the “bring your own endpoint” case: the vendor’s hosted backend, or one in your own region or tenancy.
Read the modal with that distinction in mind. Approving a domain is approving an outbound data flow; approving a remote is deciding whose server runs the app’s logic.
Where the admin sees it
Two places, per the Forge page:
- In the app. When an app calls the set operation, “an admin will see a modal asking them to confirm the addition or change”; the description, domains and remotes are shown in it, approve saves the configuration and reject fails the call. Non-admins cannot approve, and the page states these operations “cannot be performed on behalf of an admin via Forge User Impersonation.”
- In Atlassian Administration. Connected apps, select the app, Data management tab. On my own organisation today the tab is live: under External data sharing each Forge app shows a card, “Data sharing with external domains, this app has permission to communicate with N URLs”, with a View button that lists them. Per the Forge page, this is also where an admin can view and set a customer-managed remote, reset it to the manifest default, and delete individual domains or whole egress groups that an app has requested. One tab for both the destinations the vendor declared at install and the ones your admins approved later, which the page calls “a centralized place to review data flows across multiple apps in their organization”.
Both kinds of change are recorded in Atlassian Guard audit logs. If you run access reviews, that is a new event type to add.
Three things the GA notice does not say loudly
- Not eligible for Runs on Atlassian. Any app using customer-managed egress or remotes loses that badge, because by definition data leaves Atlassian’s boundary to somewhere your admin chose. If your procurement checklist says “Runs on Atlassian only”, this feature and that rule cannot both be true for the same app.
- Irreversible for the vendor in production. Once an app enables the flag in its production environment, it cannot remove it in a later version. An app that uses this today will keep asking your admins questions for the rest of its life.
- The modal remembers. If a domain is already approved for one egress type and the app reuses it for another, the modal is not shown again for that domain. Review the Data management tab, not just your memory of what you clicked.
The admin checklist
- Open Connected apps today, pick each Forge app, and read the Data management tab: the “communicate with N URLs” card is the current egress list. The dialog has two tabs: Required (the vendor’s declared egress, fixed) and Configured (the customer-managed list). A Runs on Atlassian app may legitimately show pre-approved analytics domains on the Required tab (analytics tool policy; Sentry’s ingest domains are on the list); anything else beyond Atlassian’s own domains is a question for the vendor (thanks to Nicolás De León for the vendor-side rule).
- Decide who may approve. The modal appears for admins; agree with your team which admins answer it and how the decision is recorded.
- For every remote, ask the vendor where that endpoint runs and under whose contract. “Customer-managed” means you can change it; it does not mean you must.
- Add the egress and dynamic module events to your Guard audit log review.
- Update the app intake form: “Does the app use customer-managed egress or remotes?” sits next to “Runs on Atlassian?”, and they are mutually exclusive.
Verified against the Atlassian developer changelog (12 October 2026 entry) and the Forge page “Customer-managed egress and remotes” (last updated 12 October 2026) on 12 October 2026. The Data management tab was checked on my own organisation the same day.
