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?
and Atlassian deems any external fetch request (even a GET request) as “egress”.
Just to provide some context here - this is because get requests can trivially egress data via query parameters and headers.
After all, isn’t that the whole point of CME? To give customer admins the ability to decide which external connections are trusted?
Yes, you’re right.
There’s inherent friction here because the RoA badge is a black and white trust signal overlaid on a problem space that has shades of grey. Just because an app doesn’t have the RoA badge, doesn’t necessarily mean that an app hasn’t made significant investments in minimising data egress in the name of customer trust. There’s still value in presenting a slim list of egress domains on the installation screen & privacy/security tab, even without the badge.
I do understand the frustration. The criteria for the badge and where we draw the line on what is/isn’t eligible is subjective and there are a number of competing constraints across legal/privacy, technical feasibility and customer perception that we are trying to balance.
The feedback is still welcome and can inform future decision, so please don’t stop continuing to share your thoughts on this.
From the very beginning, we have been asking Atlassian to make Customer-managed egress RoA compliant. We haven’t received any convencing response why you refuse to take our feedback.
It’s a choice: absolute safety with limited usefulness, or balanced security that enables powerful apps. Atlassian’s current position is first, what vendors and customers want is second.
Wanted to jump into this with the perspectives of Customer Managed Egress and why we are not permitting Runs on Atlassian at this stage.
Customer Expectations - When we explored the customer desire to have increased control over how and where apps can egress data, we learnt two things:
Larger enterprise or security-conscious customers want to increasingly be aware or have a say in how and where their data it utilised and CME provides an avenue to apply a principle of least privilege (i.e. where apps declare * today), or to better limit app access in ways which are still required for them to function.
The perception of Runs on Atlassian was that the app does not egress any data at all. In fact, they preferred that we either had a different badge or no badge at all, rather than mixing these in with RoA.
We are seeing CME being accepted as an acceptable pathway by some of our largest customers who previously preferred apps to be RoA. Even without the badge, this is supporting some partners in their sales and security conversations.
Flexible Implementation vs Abuse - CME has been developed in a way which enables apps to control egress is exposed and managed within their app. This was a conscious decision, as we understood that the use cases were diverse and having to defer to Connected Apps to manage egress would be a disruptive and sub-optimal customer experience. This came with a trade-off, which is that any incentive to adopt CME to attain a badge could be abused - an app could immediately ask for egress and not function without it.
While we understand that the overwhelming majority of partners want to and will do the right thing, the challenge emerges when one doesn’t. The customer perception of the badge and CME would be impacted and unfortunately, that impact flows on to every app which has implemented it with the correct intentions.
Diversity of badges - Atlassian is working on additional trust signals in the marketplace (such as A4A) which help level the perception playing field. Being able to present to customers that your app has a strong trust and security posture helps counter-set a reliance on RoA being the primary trust signal.
Partners have been voicing that for a long time. Customers expect that it means zero egress but there are many, many, scenarios where egress occurs and Atlassian considers it RoA-compliant because it simply means “runs through Atlassian infra (AWS)” and not “zero egress”.
I think there is a lesson here for Atlassian, and it comes with some hard introspection. Because Atlassian has not been consistent with regard to RoA messaging.
I don’t see why this is an issue. Atlassian should start treating both the customer and the marketplace partners as adults who have agency. If an app does this, the customer can still uninstall the app and not use it. Asking for CME does not automatically mean granting CME. This is not an example of abuse, and even if it is, Atlassian does not need to be the gatekeeper here. Customers have ample ways to show Marketplace Partners that they are not happy with app implementations.
This is also a prime example of why the “Runs on Atlassian” badge is poorly named. We have multiple apps that run completely on Atlassian. They are 100% client-side forge apps. But they integrate with 3rd parties, so they need access to the 3rd party service.
Every normal person understands that “Airtable for Confluence” requires access to Airtable. But at this point, this completely benign 100% client-side app is not RoA because it needs access to airtable.com. It fact, it is requesting '*' wildcard egress because otherwise we cannot support native Airtable embedder features that require opening a popup window.
Customers and Marketplace Partners have agency, and Atlassian should stop being condescending and belittling to the both of us.
It is unfortunate that Atlassian is taking the most pessimistic, lowest common denominator approach here, and conflating “does not egress” with “can not egress”.
Again citing our example from earlier in the thread, our app only reads data from an external customer supplied URL. There is no egress.
Yes I understand that we could theoretically leak customer data in url parameters of a GET request, but the fact is we don’t do this. (And if the URL is customer supplied & allowed via CME, any data in url parameters would be leaked…only to that very URL?)
Putting aside the poor naming of RoA, which based on the strict rules should more appropriately be called “Airgapped on Atlassian”, there is currently no suitable badge for apps like ours that do run purely on Atlassian and do not egress any data.
And with the premature deprecation of the CSP badge while the new trust signals are still being RFC’d, we have limited ways that we can provide customers assurance that our apps are safe for them to install and use.
It’s very dogmatic of Atlassian to take such a hardline approach to RoA eligibility.
@SeanBourke The problem with ROA is that it is very inconsistent how egress is allowed. You can do analytics egress, and customers can stop it.
Analytics egress is arguably a bigger issue than customer managed egress, where a customer can specify an egress endpoint. Analytics egress is there mainly for the vendor, not for the customer.
So why is analytics egress allowed under ROA, but customer managed egress not?
I appreciate your candour here. Similar to @marc’s comment, I believe that Atlassian figured out how to work around most of these perception problems of “the app does not egress data at all” when dealing with analytics, while still allowing those analytics-sending apps to receive the RoA badge.
Is there any similar sort of mitigation that could be figured out here?
For example, if I declare analytics egress, I can trivially send unlimited amounts of arbitrary data up to Sentry (or whatever), and then download it from outside the customer perimeter. I can also stop the app from working if the admin has disabled analytics egress.
I believe the current primary differentiator between the two features is the ability for admins to disable analytics egress at a site or organization level. Those who do not want any of this egress will clearly turn it off.
Could something similar be considered here, like adding an org-level flag to allow admins to prohibit CME egress unless the requested domain falls on a list of org-level or site-level approved CME domains, and users/apps can only request CME to a domain that an org admin has already previously allowlisted? (When creating this flag, you could look at all sites/orgs that already have analytics disabled and decide to default the CME egress flag to “allowlist only” as well.)
For the malicious behaviour aspect, I also wonder if CME abuse could be simply treated the same way that Atlassian does for RoA apps that abuse analytics (drastic action taken when uncovered by Atlassian). Given that the CME target domain always has to be manually approved by the customer in some form, it seems that the potential for abuse is actually far worse with analytics.
I agree that other security factors beyond RoA can come into play when making customer decisions. I also fear that when the Marketplace makes it really easy to prioritize searches for RoA, despite any potential nuances in a vendor listing, many customers will become RoA-or-nothing, and those who do not have the badge (regardless of why) will be left outside the fold.