Skip to content
All posts

Atlassian6 min readYamuno Team

Forge vs Externally Hosted Apps: Security Checklist

A Practical Security Checklist for Atlassian Marketplace Apps

When teams evaluate Marketplace apps, the conversation usually starts with features. Approval usually depends on a different question: where does this app process and store our data?

If you're a Jira or Confluence admin, or on an IT or security team, this checklist helps you answer that quickly, using facts you can verify on the Marketplace listing and in Atlassian's developer documentation.

The three hosting models, in plain language

Forge apps with no external egress. The app's code runs on Atlassian-hosted compute and stores data in Atlassian-hosted storage. Forge apps must declare in their manifest every external domain they call, so if nothing external is declared, data stays on Atlassian's platform.

Forge apps that call out. Forge apps can still send data elsewhere, either by declaring external domains (egress permissions) or by using Forge Remote, which connects a Forge app to services the vendor hosts. That's a legitimate design, but your review then needs to cover the vendor's infrastructure too. Atlassian notes that using Forge Remote may make an app ineligible for Runs on Atlassian.

Connect apps. Connect apps run on the vendor's own servers, and Jira or Confluence sends data to them. Atlassian has announced that Connect stops accepting app updates after March 31, 2026 and reaches end of support at the end of 2026, after which it gets no security patches. If an app you rely on is still on Connect, ask the vendor for their Forge migration plan.

Start with the Runs on Atlassian badge

Runs on Atlassian is a Marketplace badge for Forge apps that meet strict data requirements. Atlassian detects eligibility and applies it automatically, so the vendor can't simply claim it. An eligible app must:

  • use only Atlassian-hosted compute and storage
  • support data residency in line with the host product
  • let customers control any external data egress (for example analytics and logs) through admin controls, and never send in-scope end-user data outside Atlassian

If an app has the badge, a large part of your data-flow review is already answered. If it doesn't, that's not automatically a problem, but it tells you to look closer.

One caveat from Atlassian's own documentation: the badge doesn't stop an app from misusing access it has been granted inside your site. Scopes and vendor trust still matter.

The checklist

Work through these for each app. Most answers are on the Marketplace listing's privacy and security details, or in the vendor's documentation.

Hosting and data flow

  1. Platform: Is the app built on Forge or Connect? If Connect, what's the vendor's migration timeline?
  2. Runs on Atlassian: Does the listing show the badge?
  3. Declared egress: Which external domains does the app contact, and why? Forge apps declare these in their manifest, so the vendor should be able to list them exactly.
  4. Forge Remote: Does the app use vendor-hosted services? If so, where are they hosted and what data do they receive?
  5. Data residency: Does the app support data residency for the regions you need?

Access and permissions

  1. Scopes: Do the requested scopes match what the app does? An attachment cleanup tool needs attachment access; a chart gadget doesn't need write access to your issues.
  2. Change control: On Forge, adding scopes or new egress categories creates a major version that a site admin must approve before it applies. Decide who reviews those upgrade prompts.
  3. In-app permissions: Can admins limit who uses the app or edits its content (for example, who can edit an HTML macro or run bulk deletes)?

Data handling

  1. Storage and retention: What does the app store, where, and for how long? How is it deleted when you uninstall?
  2. Third parties: Are any sub-processors involved, including analytics?

Operations

  1. Audit trail: Can you trace sensitive actions, such as bulk deletes or permission changes?
  2. Incident response: Is there a documented security contact and disclosure process? Does the vendor take part in the Marketplace security programs?
  3. Support: Are support channels and response expectations clear?

A rollout model that doesn't stall adoption

  1. Shortlist by architecture fit, not just features.
  2. Run the checklist, starting with the badge and declared egress. Apps with the badge usually clear the hosting questions quickly.
  3. Pilot with one team or project and watch performance, support responsiveness and admin effort.
  4. Approve with a documented record of scopes, egress and the reviewer, so later major-version upgrades can be checked against it.
  5. Review on upgrade. When an app asks for new scopes or egress, compare against your record before approving.

This keeps diligence intact without turning every app request into a multi-week project.

How Yamuno's apps fit

Every Yamuno app is built on Atlassian Forge and processes your content inside Atlassian's infrastructure, with no external servers of our own:

Check each listing for its current Runs on Atlassian status and privacy details, or browse the full product list. For a broader look at which apps suit documentation teams, read the best Atlassian apps for technical documentation.


Reviewing our apps for your organization? Reach out via our support portal and we'll answer your security questions.

Charts - Reports and Graphs for Jira Dashboard

Visualize Jira issues with interactive, customizable charts and tables

Related articles

All posts