Last updatedFeb 17, 2021

Rate this page:

Cloud app hosting

We’re making changes to our server and Data Center offerings, and have announced that we’ll be ending server sales and support in the future. To learn more about our plan and how it affects you, read the Journey to cloud blog post.

This page explains how Atlassian cloud apps are hosted and how they’re different from server apps.

How server and cloud apps differ

Atlassian server apps sit in a container within the product install directory. The server app’s 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.

In 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 what product API’s you can use to extend the app UI and interact with the Atlassian cloud product(s).

There are three main types of cloud apps you can build:

  • Atlassian Connect app
  • Forge(beta) app
  • External app or integration.

Hosting a Connect app

Atlassian Connect is a framework that enables developers to 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 Forge (beta)

Forge is a platform that enables developers to build apps and integrations on top of Jira and Confluence 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.

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: