It’s been almost a year since we announced the customer launch of Runs on Atlassian. Thanks to the hard work of our partner community, we now have over 1,000 RoA compatible listings on the Marketplace.
As we plan our 2026 roadmap, we’d like to better understand what would help partners build and operate Runs on Atlassian apps. Your feedback will directly shape where we invest next.
I know that many of you are currently focused on the Connect → Forge transition and working through blockers. I know that this a busy and tense time.
Atlassian’s annual planning cycle means that this is the window where feedback can most directly influence our roadmap for next year. Planning and analysis of this feedback will not be pulling any engineering resources away from supporting the Connect transition.
Thanks in advance for any input you are willing to provide.
It will be good when Atlassian starts supporting api.atlassian.com as an internal API call rather than an external one. This automatically disqualify RoA even-though every other thing runs within Atlassian. I wonder how that would be addressed?
The main reason why we don’t have a blanket approval for api.atlassian.com is that our API gateway exposes a number of endpoints that allow traversal of requests into other Atlassian sites/workspaces (eg. by supplying a Cloud ID or Site ID parameter as part of the URL path), which means it would break our tenant isolation responsibility in the Forge Shared Responsibility Model.
That doesn’t sound ideal. In a multi-tenant environment, each workspace should be isolated and requests should be scoped to the tenant making them. From an authentication and authorization perspective, when Forge makes requests via api.atlassian.com, the platform should validate the identity behind the request and ensure access is restricted to the appropriate workspace.
I understand this is easier said than done, but if this limitation exists at the platform level, it may not be something that can be resolved quickly and we should not expect a solution anytime soon in regards to RoA. Probably Atlassian should make a sub-program within RoA which supports or acknowledges apps that are completely on Forge but use that endpoint?
We’re a Forge app partner and we’d like to raise a few concerns around the current “Runs on Atlassian” constraints that are blocking us.
No ability to integrate with external tools under RoA
Our app needs to send messages via the Slack API. Under RoA, any form of external egress is prohibited, which makes it impossible for us to support this functionality.
▎ “Forge apps that use customer‑managed egress or customer‑managed remotes are not eligible for Runs on Atlassian.”
This is confusing. Customer-managed egress was designed to give admins visibility and control over external connections — proper audit logging, per-installation consent,
admin-managed domain allowlists. These are exactly the kind of safeguards that should make external access acceptable under RoA, not disqualifying. Why can’t customer-managed
egress serve as the trusted mechanism that enables controlled external access within the RoA program?
Inter-app communication between Forge apps is insufficient
The RoA limitation also creates problems for collaboration between two Forge apps on the same Atlassian site. If one app is RoA-compliant and needs to exchange data with another
Forge app, there’s no viable path.
https://developer.atlassian.com/platform/forge/events-reference/app-events/ exists and allows cross-app event publishing — but publishing apps can’t add any custom
payload to the event. You can signal that something happened, but you can’t say what happened. For any meaningful integration between two Forge apps — sharing context, syncing
state, triggering actions with parameters — this is a critical gap.
Summary
As it stands, achieving RoA compliance means cutting off both external integrations (like Slack messaging) and meaningful inter-app data exchange. We’d love to understand:
Is there a roadmap for making customer-managed egress compatible with RoA?
Are there plans to support custom payloads in Forge App Events?
What is the recommended path for Forge partners who need controlled external access and still want to be RoA-eligible?
Thanks all for the feedback! We hear the ask to assess compatibility between Customer Managed Egress (“CME”) and Runs on Atlassian. This is not part of our current plans but your feedback is valuable.
With regards to allow-listing api.atlassian.com - while we aren’t able to make a blanket approval here, we are working with individual teams within Atlassian that own resources on this gateway and making them compatible with the Forge tenant isolation requirements, which then allows us to allow-list those specified endpoints for RoA (as we have done for requestJira/requestConfluence/etc.).
Another vote for Customer Managed Egress being eligible for RoA.
We just had a customer asking about our plans for Forge / RoA as part of a routine security assessment (which in itself was interesting - questions specifically about Forge are, in our experience at least, exceedingly rare, despite what sometimes Atlassian would have us believe).
Our upcoming Forge version runs entirely on the Atlassian Forge platform for both compute & storage. We do however allow our customers to specify a URL that our app fetches at runtime from the browser client; and since we cannot know ahead of time the possible URLs to include in our manifest, we currently require external.client.fetch.address = “*”.
We advised the customer that our app would otherwise be eligible for RoA, but for the fact that our browser code can read content from a customer supplied URL, and Atlassian deems any external fetch request (even a GET request) as “egress”.
They were surprised to say the least, as in their mind (and ours) an app whose compute & storage is fully within the Atlassian environment and does not send data outside of the Atlassian environment is, at least in spirit, the very definition of “Runs on Atlassian”.
We pointed to the Customer-managed egress and remotes (EAP) and said that our hope is that in future this could be RoA-compliant, and they were again surprised that it wasn’t already. After all, isn’t that the whole point of CME? To give customer admins the ability to decide which external connections are trusted?