Last updated Dec 12, 2024

Cloud app hosting

This page outlines how apps for Atlassian cloud and server products differ, and how you can host a Forge app, Connect app, or external integration.

If you're looking to move your apps and business to cloud, visit our cloud-readiness hub in the Partner Portal. Learn about requesting access.

How server and cloud apps differ

Server apps

Atlassian server apps sit in a container within the product install directory. The server app classes are loaded into the class path when the application is started. This means server apps have access to the Atlassian database and libraries.

With the events library, a server app has access to application events directly. A server app only needs to use webhooks or REST API calls when integrating with external HTTP services. Server apps do however use webhooks and REST API calls when integrating with external HTTP services.

Cloud apps

Atlassian cloud apps are not hosted in the product container, and must be available on the web.

The framework you use to build your app will define whether you or Atlassian host the app and which product APIs you can use to extend the app UI and interact with the Atlassian cloud product(s).

Hosting a Forge app

Forge is a platform that lets you build apps and integrations on top of Jira, Confluence, and Compass Cloud products. When you build a Forge app, Atlassian takes care of the infrastructure, including security considerations. The Forge CLI is designed to make it easy to build apps quickly.

Atlassian Forge apps use a manifest to provide information to the Atlassian cloud instance about the app, including how it interacts with the product, the permissions required, and the resources used.

Because the Forge platform is managed by Atlassian, you don’t need to provide the infrastructure where your app runs. However there are some limitations which ensure the platform runs smoothly for all users.

Check out some Forge example apps.

Hosting a Connect app

Atlassian Connect is a framework that lets you build apps and integrations on top of Jira, Confluence, and Bitbucket Cloud products.

When you build a Connect app, you’re responsible for hosting your app, along with maintaining its database (if you need one). The cloud app itself must be available on the web, but the technology stack and hosting methods you use are up to you.

Connect apps use an app descriptor to provide information to the Atlassian cloud instance about where the application is hosted, the level of access it requires, and how it will interact with the Atlassian product.

While Connect allows you to write your app in any language, Atlassian provides frameworks for Node.js and Java to help you get started. You can self-host, or use an infrastructure provider such as AWS, Google Cloud, or Heroku.

Depending on your requirements, you can choose to build either a static or dynamic app.
Static apps can be quite inexpensive to run. You host your static resources with your provider, and the app itself is run within the browser. If you want to listen for events, process data or integrate with a third party service, then you’ll need to build a dynamic app, which can update its state based on user interactions.

The following blogs discuss some of the ways people have hosted a Connect app:

Hosting an external app

In some cases, you may want to build an app that can access and create data, without having any UI elements within the Atlassian product. For example, you might want to integrate an Atlassian product with an application specific to your organization, or create a personal bot or script.

External apps can be built in a variety of different ways, and may or may not need to be hosted. For example, you can run a script on your local machine to automate occasional tasks.

For these applications, the main requirement is that your app is able to send authorized requests to the appropriate REST APIs, and then receive and parse the responses. Remember that different REST endpoints require different permissions, and your app can only access data based on the permissions of the user who authorized it.

See also:

Rate this page: