What Runs on Atlassian means
When someone asks to install a Marketplace app in Confluence or Jira, the first security question is usually the simplest: where does our data go? For a long time the honest answer was "it depends on the vendor", and finding out meant reading a privacy policy, a questionnaire and sometimes an architecture diagram. Runs on Atlassian is Atlassian's attempt to answer that question with a badge.
Runs on Atlassian is a program for apps built on Forge, Atlassian's cloud app platform. Atlassian describes it around three promises:
- the app uses only Atlassian-hosted compute and storage;
- the app supports data residency that matches the data residency of the Atlassian product it is installed in;
- customers can control any external data egress the app does (such as analytics and logs) through admin controls.
Vendors don't apply for the badge or fill in a form to get it. Atlassian checks each app against the program's rules and applies the badge automatically to apps that qualify. You see it on the app's Marketplace listing, you can filter Marketplace search by it, and admins can see whether an installed app is eligible in the app management pages of Atlassian Administration.
That automatic check is what makes the badge useful in a review. It is not a vendor's claim about itself. It reflects what the app declares in its manifest, the file in which a Forge app lists everything it is allowed to do.
The Runs on Atlassian requirements
Atlassian's developer documentation spells out what an eligible app may and may not contain. At the time of writing, the rules come down to this:
| Requirement | What it means in practice |
|---|---|
| No external resource domains, except for analytics | The app can't declare outside servers it talks to. Calls to an analytics service are the one allowed exception. |
| No remotes | The app has no back end of its own outside Atlassian. Its code runs on Forge. |
| No Connect modules | The app doesn't mix in parts built on Atlassian's older Connect framework, which are hosted by the vendor. |
| No providers | The app doesn't sign in to external services on a user's behalf. |
| Only static web triggers | Dynamic web triggers (URLs created at runtime that outside systems can call) disqualify an app. |
| Residency-ready storage | Data lives in Forge hosted storage that supports data residency, or in entity properties stored inside the Atlassian product itself. |
| No customer data in analytics | If the app sends analytics, it must not include in-scope End-User Data, and the admin can turn analytics access off. |
Atlassian adjusts programs like this over time, so treat the table as a summary rather than the rulebook. The principle is stable: no app code running outside Atlassian, no customer data stored outside Atlassian, and nothing leaving Atlassian except analytics that carry no customer content and that an admin can switch off.
Tip: Eligibility follows what the app declares, and it can change. If a vendor later adds an external domain or a remote back end, the app loses eligibility. On Forge, changes like these usually create a new major version, and by default a new major version isn't applied to your site until a site admin consents to the upgrade. Read the permissions on any upgrade prompt before you accept it.
Forge apps and Connect apps: where code runs and data lives
The badge only makes sense once you know the two ways Marketplace cloud apps have been built.
Connect apps are hosted by the vendor. The app runs on servers the vendor operates (typically a public cloud account), and Confluence or Jira talks to those servers. Any data the app keeps lives in the vendor's own database. Reviewing a Connect app means reviewing the vendor's infrastructure: their hosting provider, their access controls, their backups, their regions.
Forge apps are hosted by Atlassian. The app's functions run on Atlassian's infrastructure, and the app can store data in Forge hosted storage (a key-value store, custom entities, a SQL database and an object store). Forge scopes that storage to each installation, so one customer's app data is kept apart from another's. Atlassian runs the platform, including outbound egress controls, encryption in transit and other parts of the security baseline.
Being on Forge is not the same as running on Atlassian. A Forge app can still declare external domains or call a vendor-hosted back end through Forge Remote, and then your data may leave Atlassian. Runs on Atlassian is the label for Forge apps that do neither. Atlassian has also been moving the Marketplace away from Connect and toward Forge, so you will see more Forge apps over time, but you still need to check which kind you are looking at.
| Connect app | Forge app | Forge app with Runs on Atlassian | |
|---|---|---|---|
| Where the code runs | Vendor's servers | Atlassian, plus any back end the vendor declares | Atlassian only |
| Where app data is stored | Vendor's database | Forge storage, the vendor's systems, or both | Forge hosted storage or the Atlassian product |
| Data leaving Atlassian | Yes, by design | Possible, if declared | Only analytics without customer data, under admin control |
| Data residency | Depends on the vendor | Depends on how the app stores data | Matches the host product |
What the badge doesn't cover
Runs on Atlassian narrows the review. It doesn't end it. Atlassian says so itself: the egress controls don't prevent misuse of the access an app is granted when it is installed, or abuse of the app runtime. Security for Forge apps works on a shared responsibility model, and several things stay with the vendor.
The vendor still writes the code
Atlassian hosts the app, but the vendor decides what it does. Whether the app checks a user's permissions before showing or changing something (apps that act as themselves rather than as the user must do this on their own), whether it keeps one customer's data from leaking into another's, and whether it handles input safely are all down to the vendor's engineering. A badge says nothing about bugs.
Scopes still matter
Every Forge app requests scopes: permissions to read or write content in your site, manage spaces, read user details and so on. An app with broad write access can change a lot of content without sending a byte outside Atlassian. Check that what the app requests matches what it claims to do, and ask the vendor to justify anything that looks wide.
Vendor practices
Marketplace vendors must meet Atlassian's security requirements, including naming a security contact, fixing reported vulnerabilities within set timeframes and reporting security incidents to Atlassian. How well a vendor does this, how they respond to issues and how long they support the app are still part of your review. Their own SOC 2 report, if they have one, is a separate question from the badge.
What to check when you evaluate a Marketplace app
Use this as a checklist for a Confluence or Jira app. It fits inside your normal vendor process (see vendor risk management for SOC 2), and the badge lets you skip or shorten several steps.
- Forge or Connect. On the Marketplace listing, look for a descriptor link under Resources. A descriptor link usually means a Connect app; Forge apps don't have one.
- The badge. Check for Runs on Atlassian on the listing. After installation, the app's details in Atlassian Administration show whether it is eligible.
- The Privacy & Security tab. The listing's tab is where the vendor answers standard questions: whether End-User Data is stored or processed outside Atlassian, data residency support, logging, retention after uninstall, sharing with subprocessors, a DPA and a security contact. The vendor is responsible for these answers, so compare them with the badge. A Runs on Atlassian app that says it stores data elsewhere deserves a question.
- Scopes. Read the permissions the app asks for when you install it, and again on any major version upgrade. Match each one to a feature.
- Egress and analytics. If the app declares analytics egress, decide whether you want it on. Admins can switch an app's analytics access and logs access on or off from the app's details page.
- Data residency. If your organization pins Confluence or Jira to a region, confirm that the app's data moves with it. Data residency for Confluence is available on Standard, Premium and Enterprise plans.
- Vendor security. Find the vendor's security contact and privacy policy, ask how they handle vulnerabilities, and keep their answers with your review.
- Uninstall. Know what happens to the app's data when you remove it, and what stays in your site.
Write down what you checked and when. If your company is working toward a SOC 2 report, that record is evidence that you assess new tools before you adopt them, and it saves time the next time a customer sends a security questionnaire asking which third parties can see their data.
Note: Whether an app that runs entirely on Atlassian needs its own row in your vendor inventory is your call, guided by your vendor policy and your auditor. Most teams still list the app vendor, because the vendor writes code that runs against your data, and note that the data stays with Atlassian.
A compliance app that runs on Atlassian
A tool that holds your compliance records should be easy to put through this checklist. Compliance in a Box turns a Confluence space into a SOC 2 program: policies with version-bound approvals, employee acknowledgements, and recurring activities that open their own evidence pages on schedule. Here is how it answers the questions above.
- Runs on Atlassian. The app is built on Forge and carries the Runs on Atlassian designation. Its code runs on Atlassian's infrastructure.
- No external services. It has no connections to external domains, no remote back end and no subprocessors other than Atlassian. Auralite Solutions, the vendor, has no access to the data it stores.
- Forge hosted storage. The app's records (policy versions, approvals, acknowledgements, activity periods, settings and the audit log) are kept in Forge hosted storage that belongs to your site's installation of the app. Your policies, evidence pages and reports are ordinary Confluence pages in your own compliance space.
- Data residency. App data follows the data residency location of your Confluence site.
- Minimal personal data. People are stored only as Atlassian account IDs, never names or email addresses.
- Logs. The Forge logs Atlassian makes available to the vendor for troubleshooting contain identifiers and error codes only, never page content, names or email addresses.
- Uninstalling. Your Confluence pages, including the generated Evidence & Reports pages, stay in your space. The app's own records are deleted by Atlassian after its retention period.
The Data and privacy section of the user guide covers this in more detail, and running a SOC 2 program in Confluence explains the bigger picture. Before you roll the app out, read Before you start: the app asks each person once to allow access on their behalf, so tell your employees to expect the prompt.
FAQ
Does the badge mean an app passed a security review?
No. It is a platform-level check that an app runs and stores data only on Atlassian, supports matching data residency and keeps any analytics egress under admin control. It doesn't assess the vendor's code, scopes or security practices, so you still review those.
Do all Forge apps run on Atlassian?
No. Forge apps can declare external domains or call a vendor-hosted back end. Only apps that avoid these, among the other requirements, qualify for the badge.
Can a Runs on Atlassian app send any data outside Atlassian?
Only for analytics, and only without in-scope End-User Data. Admins can turn an app's analytics access off. Anything beyond that makes the app ineligible.
Can an app lose the badge?
Yes. Eligibility follows what the app declares. Adding a remote back end, Connect modules or non-analytics egress removes it. On Forge, changes like these usually arrive as a major version, which by default isn't applied to your site until a site admin accepts it.