overview
This announcement is for partners building apps on the Atlassian Marketplace. If you are an Atlassian customer, stay tuned for an official announcement next year.
Today, Atlassian is sharing plans for a new Marketplace badge designed to help customers identify apps that a) do not transmit data outside of the Atlassian Cloud and b) provide data residency. Controls will be added to the installation consent screen so customers can enable or disable sharing of diagnostic logs and analytics.
We expect this badge, called Runs on Atlassian, to launch to customers in early to mid 2025.
Forge launched in 2021 with a watershed new capability: the option to host and run cloud apps entirely on Atlassian infrastructure. This resonated strongly with enterprise customers, who faced challenges installing apps built by third-party partners hosted on servers located around the world. Customers began to ask how they could identify apps built on Forge, even in those early days.
But the answer wasn’t so simple. While Forge is the only way to run an app in Atlassian’s secure environment, it’s also a flexible platform. Developers can build Forge apps in many configurations, including integration with backend servers running off-Atlassian. So we went deeper with our customers to get to the root of their needs. It turned out that customers were concerned with three things:
- Whether an app could transmit data outside of the Atlassian environment, known as data egress
- Support for data residency that matches data residency provided by the host product
- A programmatic way for Atlassian to verify 1 and 2
Forge can help solve for all three. First, Forge blocks data egress by default and gives customers controls to manage the risk of egress through logs. Both egress domains and Forge storage, which supports data residency automatically, are declared in the manifest, allowing Atlassian to programmatically verify which Forge apps keep data stored inside Atlassian infrastructure and offer data residency.
Introducing Runs on Atlassian
Today, 345 apps already meet the definition outlined above, meaning there is a substantial population of apps that meet this customer need. Partners like Seibert Media are making investments in no-egress apps, based on evidence that apps fitting this profile have an easier path to winning enterprise customers.
In fact, Templating.app won one enterprise customer with over 5,000 users in the first months because the company loved that we do not involve external servers.
Julien Wolf, Seibert Media
To increase transparency to customers and boost discovery of apps meeting these technical requirements, we are introducing a new badge called Runs on Atlassian that identifies Forge apps with no data egress and data residency-enabled storage. This will give partners who have made investments in Forge a new way to communicate the benefits, streamlining the process of acquiring enterprise customers —particularly those in regulated industries or regions with strict data privacy requirements.
We expect the Runs on Atlassian badge to roll out to Marketplace customers in Q2 CY2025, giving partners runway to make apps eligible. The Runs on Atlassian badge will be automatically detected and applied when an app meets the qualifications. Partners do not need to apply or opt in to receive the badge.
Leading up to the customer launch, partners can expect enablement and guidance from Atlassian, including tooling, to assess whether apps meet the qualifications for Runs on Atlassian and close any gaps needed to achieve the badge.
Educating customers on the nuances of app trust
Runs on Atlassian is designed to enhance transparency and trust within the Atlassian Marketplace, but it is not the sole indicator of an app’s security posture. Many of our partners already integrate strong security and data protection measures into their app infrastructure. We’ll continue communicating this to customers, so they understand that a diverse range of protections exist for all apps.
Some apps may not aim for the Runs on Atlassian badge because of the use cases they serve—and that’s okay. We’ll provide documentation and resources to help customers see that a missing badge doesn’t mean a lack of security, but often reflects varied functionalities and needs across apps.
Ultimately, we’re committed to building a platform that’s secure, transparent, and trusted for our customers. As we go forward, we’ll expand the Runs on Atlassian eligibility criteria in a way which preserves the integrity and value proposition of the program, while also investing in programs like Cloud Fortified and access to Vanta, which strengthen trust regardless of hosting choices.
Differentiating between Runs on Atlassian and Cloud Fortified
The investment partners have made in Cloud Fortified badging isn’t going away, and Runs on Atlassian will be positioned in harmony. Cloud Fortified will remain an important signal that a Partner has invested in advanced trust practices across their business, especially for apps that are partner-hosted.
Runs on Atlassian indicates apps are Atlassian hosted with no egress – a simple technical fact that can be programmatically verified. Cloud Fortified is a broader set of signals that includes organizational behaviors and practices, like support, reliability, and bug bounty participation. The two badges are not mutually exclusive, meaning an app might have one or the other, or both.
What can partners start doing today?
To determine whether your Forge apps meet the requirements for Runs on Atlassian, start by checking your manifest file for egress permissions. Apps that qualify for Runs on Atlassian will NOT list any of the following in the manifest:
- External resource domains (Custom UI resources, fetch.backend, fetch.frontend, etc.)
- Remotes
- Connect modules
Apps must either use data residency-enabled Forge storage or store data in-product using entity properties. Note that as new Forge storage capabilities are introduced in EAP or Preview stages, they may not support data residency until they reach general availability.
As shown in the examples below, remotes and anything defined in the egress object will count towards data egress:
👍 Runs on Atlassian
permissions:
scopes:
- read:content-details:confluence
- read:content.property:confluence
- write:content.property:confluence
NOT Runs on Atlassian
permissions:
external:
fetch:
backend:
- '*.example-dev.com'
fonts:
- 'https://www.example-dev.com/fonts.css'
scripts:
- 'https://www.example-dev.com/script.js'
NOT Runs on Atlassian
remotes:
- key: remote-backend
baseUrl: "https://backend.example.com"
operations:
- compute
- fetch
- other
Check for opportunities to eliminate egress
Remove *.atlassian.net for loading media links
Loading media links, such as uploaded files, images, and other media hosted on the product domain (e.g.https://hello.atlassian.com/path-to-user-avatar.png) is a common cause of egress in Custom UI apps. This had been necessary because the product domain is different from the domain where Custom UI is hosted, which meant many developers needed to declare *.atlassian.net in the app’s permissions. We’ve since shipped a small but impactful update to our CDN that supports loading media links hosted on the product domain in Custom UI apps without declaring any egress. All Custom UI apps now allow-list the host of the product by default.
Remove api.media.atlassian.com for Atlassian product API redirects
Similarly, we’ve also shipped a change that allows Atlassian product API redirects to be treated as internal traffic by the Forge Node.js runtime. As a result, these backend egress declarations are no longer required in your app’s manifest and can be removed. However it may still needed to be included in other egress sections for Custom UI apps (e.g. media, images, etc.).
Check out community resources
Partners, like Seibert Media, are at the forefront of developing no-egress apps. Seibert Technical Coordinator Julien Wolf recently wrote a blog post for the Atlassian Developer blog outlining how Seibert prioritizes data containment in the apps they build, with tips for closing gaps to create enterprise-ready apps.
Watch the public roadmap and change log
We’ve recently updated the Forge public roadmap, making it easier to track in progress and upcoming improvements to Forge. If you haven’t already, we recommend bookmarking the roadmap and changelog so you can stay across new Forge features that let you do more natively.
Next steps
In the coming months, we plan to roll out new tools and enablement for Partners who want to qualify for Runs on Atlassian. At the same time, we will be preparing a customer-facing launch in the first half of 2025.
To build a stronger story for customers at launch, we are seeking partners who wish to be featured in Runs on Atlassian marketing materials. Candidates will be prioritized based on the number of app installs and enterprise product-market fit, and must commit to qualifying for Runs on Atlassian by March 2025. Indicate your interest in inclusion in marketing campaigns by filling out the application. Note: application is not required to receive the Runs on Atlassian badge – only to participate in launch-related marketing activities.
Questions and feedback
The introduction of Runs on Atlassian represents a new opportunity for partners and a big next step for trust and transparency in the Atlassian Marketplace. However, we recognize that there can be tension between functionality and the tight data containment Runs on Atlassian represents. Not all apps can be Runs on Atlassian (like integrations, which communicate with external services by nature). Others need certain capabilities to be delivered in Forge before they can qualify. And of course, some partners have robust security and data protection controls built into their own app infrastructure, who may decide Runs on Atlassian doesn’t enhance the way they position themselves to customers.
We are committed to building platform improvements that will expand eligibility for Runs on Atlassian, and we need collaboration from Partners to identify and prioritize the roadmap items that will have the greatest impact. If you have a feature request that will help you qualify for Runs on Atlassian, please open a FRGE ticket and apply the runs-on-atlassian tag.
FAQ
❓ Will apps that use external analytics platforms be excluded from Runs on Atlassian?
Sending logs or analytics data to services like Sentry is considered data egress. Our research shows that customers favor a strict definition of egress, which includes analytics data, and this data can sometimes contain potentially sensitive information. However, analytics are an important tool for monitoring customer experience and improving app quality. As we get closer to the launch of Runs on Atlassian, we will be introducing controls that will allow app admins to enable or disable access to analytics and log sharing during the installation flow. This will allow apps using analytics to still qualify for Runs on Atlassian while putting customers in full control of their data.
❓Will there be any changes to the Privacy and Security tab?
Customers tell us they value the transparency of the Privacy and Security tab but observe inconsistencies in partner-attested data. Over time, we may shift to programmatically verifying certain fields based on the Forge manifest to standardize the information displayed to customers.
❓How will Runs on Atlassian show up to customers?
Runs on Atlassian apps will be marked with a badge on the Marketplace listing and customers will be able to filter by Runs on Atlassian. Runs on Atlassian will also appear in the admin app management experiences, where customers will be able to verify that apps already installed are Runs on Atlassian.
Please note, the designs and experience will change as we learn from both customers and partners in the lead-up to launch.
❓If an app receives an update that invalidates Runs on Atlassian eligibility, will customers know?
Yes. Updates that add new permissions to the manifest are considered major updates, which require app admins to manually approve. If a major update will result in no longer qualifying for Runs on Atlassian, this information will be surfaced to the admin at the time of update.
❓Will removing egress from my app require a major version update?
No, removing egress is considered a minor update. A major update is triggered when a new URL is added or an an existing URL is assigned to a new egress category, but not when egress URLs are removed.
❓Can I create an app edition that qualifies for Runs on Atlassian alongside one that does not?
At the moment, we do not support making only one app edition Runs on Atlassian. All editions must be Runs on Atlassian or not. This is due to the fact that scopes and permissions must be the same across all editions of an app. We are considering adding support, and we encourage partners to get in touch if this is something you need.