Forge in one paragraph
Atlassian Forge is the platform Atlassian provides for building apps for its cloud products, such as Jira and Confluence. The key idea is that the app does not run on the developer's servers. It runs on Atlassian's infrastructure, next to the product it extends. The developer writes the code and describes it in a manifest, and Atlassian hosts, runs and isolates it.
How a Forge app is put together
A Forge app is small and declarative. It is made of a few parts:
- A manifest. A file that lists what the app adds to the product (the modules, for example a page in a Jira project), which functions run, and which permissions (scopes) the app asks for.
- Functions. Short pieces of JavaScript or TypeScript that run on Atlassian's side when something calls them: a user action, a schedule or a product event.
- A user interface. Forge provides UI components, so the app looks like part of the product instead of a separate website.
- Storage. Hosted storage kept for each site where the app is installed, so the app does not need its own database.
- Triggers and queues. Scheduled triggers run work every day or week, and queues split long jobs into smaller ones, because functions have time limits.
The developer works with a command line tool: create the app, lint it, deploy it to an environment and install it on a site. There is no server to provision or patch.
Where it runs, and why that matters
For the person installing an app, the hosting model is the most important part, for three reasons.
Less to trust. With an app hosted on Atlassian, the data it handles stays within Atlassian's platform instead of being sent to a third-party server. That removes a whole class of questions about where data goes and who operates the servers.
Permissions are explicit. The scopes in the manifest are shown when the app is installed. An app that only needs to read issues should not ask to write them, and you can read exactly what it asks for before you accept.
Outside calls are declared. If an app needs to contact an external service, that has to be stated, so you can see whether anything leaves the platform.
None of this makes an app safe by itself. A Forge app can still ask for too much, or handle data badly. But it makes the answers easier to find, and easier to check.
Forge and Connect
Before Forge, most cloud apps were built on a framework called Connect. A Connect app runs on the vendor's own servers and talks to the Atlassian product over the network, so the vendor runs the hosting, the database and the security around them. Forge replaces that with hosting by Atlassian. If you are choosing an app today, an app built on Forge generally has less infrastructure outside Atlassian to worry about.
A real example: Zombie Hunter
We built Zombie Hunter for Jira, an app that finds and closes stale tickets on Forge, so it is a good illustration of the parts above.
- The manifest adds one page in the Jira project sidebar, and asks for four scopes: read and write Jira work, read Jira users, and app storage.
- A function answers the page when you open it or click Close. Close acts as the person who clicked, with their own permissions.
- Scanning a large project can take minutes, so a queue splits the work, and a daily scheduled trigger rescans every project.
- Scan results and settings live in Forge storage for your Jira site. We keep no copy on our own servers, which is why the Zombie Hunter privacy policy is short.
- A weekly job reports the stored account IDs to Atlassian, so people whose accounts were closed are removed from the app's data.
Five questions before you install an app
Whether or not an app is built on Forge, these questions take a few minutes and tell you a lot:
- Which permissions does it ask for? Does each one match something the app visibly does?
- Where is the data stored? On Atlassian, or on the vendor's own servers?
- What does it store, and for how long? A good privacy policy lists the data and the retention.
- Does it send anything outside? Look for declared external calls.
- What happens when you uninstall it? Your data should be deleted, not kept.
If you are not sure how to judge the apps and permissions in your own Atlassian cloud, that is a question for a review. Our cloud security review covers identity, access and data protection across your cloud tools.