Rate this page:
We’re excited to kickstart the Forge journey by extending free use of the Forge platform through 2023. We know the value that apps bring to our customers, and want to support our developer ecosystem in getting started with Forge, whether the app is for your organization, your customers, or for the Atlassian Marketplace.
Forge apps can consume resources up to the quotas or limits outlined below. The Function as a Service (FaaS) and storage quotas scale with your apps install base. The larger the install base (number of seats), the higher the FaaS and storage quotas are. Resource update quotas are applied on a per app basis.
We will reach out for an individual conversation if your app is at risk of consistently exceeding the quotas. Learn more about exceeding Forge limits and quotas.
These guidelines apply until the end of December 2023.
The FaaS and storage quotas are provided on a per app, per seat basis. For a private app, this is the number of Jira Software and/or Confluence seats that you have licensed. For a free or paid Marketplace app, this is the total number of seats that all your app’s customers have licensed, including evaluations.
Note that only resources used in custom UI have quotas applied. Forge JavaScript functions and dependencies are not counted towards the app’s quota. Only deployments to the production environment count towards the quota.
In this example, a paid Marketplace Forge app has 10 500-seat customers, and five 10-seat customers, which is a total of 5,050 seats. The Forge app's weekly quota is shown below.
FaaS | ||
---|---|---|
Invocations (seats) | Runtime (weekly) | Data returned (weekly) |
5,050,000 invocations | 20,200 minutes | 99 GB |
Storage | ||
Storage capacity (seats) | Reads (weekly) | Writes (weekly) |
19,800 MB | 39,600 MB | 9,900 MB |
Resource updates | ||
File upload (weekly) | File uploads (weekly) | |
150 MB | 500 uploads |
To estimate how much of the quota the app will use, assume that all of your users are on the standard edition of Jira Software.
The app has two modules that consume FaaS resources: a Jira issue activity panel using custom UI and a product trigger that's listening to the issue created event.
The Jira issue activity panel loads whenever an issue is viewed, and invokes its resolver function once. The resolver takes an average of 500 ms to run, and returns an average of 32 KB to the client. In other words, the app will consume one FaaS invocation, 500 ms of FaaS runtime, and 32 KB of FaaS data returned every time a user views an issue in Jira.
In this example, the view issue event has 70 issue views per seat, per week, for the app’s 10-seat licenses, and 25 issue views per seat for the 500-seat licenses. The app has an estimated 3,500 issue views across the app’s 10-seat licenses and 125,000 issue views across the 500-seat licenses, or 128,500 issue views per week in total.
1 2 3
(70 * 50) + (25 * 5000) = 128,500 weekly invocations
(128,500 * 500 ms)/1000/60 = 1,071 minutes
(128,500 * 32 KB)/1000/1000 = 3.9 GB
The product trigger fires whenever a Jira issue is created, and takes an average of 2000 ms to run. Note that triggers don't return data, and therefore don't consume the FaaS data quota.
In this example, the create issue event has three issues created per seat for the app’s 10-seat licenses, and one issue created per seat for the 500-seat licenses. The app has an estimated 150 issues created across the app’s 10-seat licenses and 5,000 issues created across the 500-seat licenses, or 5,150 issues created per week total.
1 2
(3 * 50) + (1 * 5000) = 5,150 weekly issues
(5,150 * 2000 ms)/1000/60 = 172 minutes
Add the totals from the Jira issue panel and product trigger together to get the total FaaS usage of for the app, and calculate the percentage of the quota that you’ll likely use:
1 2 3
128,500 + 5,150 = 133,650 invocations (2.6% of our quota of 5,050,000)
1,071 + 172 = 1,243 minutes (6.2% of our quota of 20,200)
4 GB data returned (4.1% of our quota of 99 GB)
The Jira issue activity panel app uses custom UI, and bundles some static resources that are served to users when they use the app. Note that only resources used in custom UI have quotas applied. Forge JavaScript functions and dependencies are not counted towards the app’s quota. Only deployments to the production environment count towards the quota. Deployments to the development and staging environments do not count towards the quota.
In this example, the static resources include an HTML file (1 MB), a JavaScript file (1 MB), a CSS file (1 MB), a PNG file (1 MB), and a GIF (1 MB); which is a total of 5 files and 5 MB.
Each time the app is deployed, the following quota is consumed:
1 2
5 * 1 MB = 5 MB uploaded (3% of the 150 MB quota)
5 files uploaded (1% of the 500 files quota)
This app consumes the weekly “File uploads (MB)” resource quota at a greater rate than our “File uploads (file count)” resource quota. Divide the total quota by the MB consumed per deploy to determine how many times the app can be deployed weekly before exceeding the quota.
1
150 MB quota per week / 5 MB deployment size = 30 production deployments per week
If the app consumes the “File uploads (file count)” quota faster than the “File uploads (MB)” quota, the number of files being deployed is the limiting factor in how many deployments can be performed in a given week.
The quotas listed below apply to an app installation; E.g. the example app, installed on example.atlassian.net in the production environment.
There are three tiers for quotas, depending on how your app is deployed:
The FaaS quotas are consumed when the function is invoked in any environment, and scale with the number of seats in your app’s install base. Runtime is metered by millisecond or part thereof. Data returned is metered by KB or part thereof.
Paid apps | Free apps | Distributed apps | ||||
---|---|---|---|---|---|---|
First 100 seats, total | Per seat thereafter | Up to 100 seats, total | Per seat thereafter | Up to 100 seats, total | Per seat thereafter | |
Invocations | 100,000 invocations | 1,000 invocations | 50,000 invocations | 500 invocations | 50,000 invocations | 500 invocations |
Runtime | 400 minutes | 4 minutes | 200 minutes | 2 minutes | 200 minutes | 2 minutes |
Data returned | 2,000 MB | 20 MB | 1,000 MB | 10 MB | 1,000 MB | 10 MB |
These quotas apply to the static resources packaged with your app that are used by custom UI functions. Resource quotas are consumed per deployment to your production environment; deployments to development and staging environments are unmetered.
Paid apps | Free apps | Distributed apps | |
---|---|---|---|
Per app | Per app | Per app | |
File capacity | 150 MB | 75 MB | 75 MB |
Files uploaded | 500 files | 250 files | 250 files |
These quotas apply to usage of the Forge Storage API in any environment, and scale with the number of seats in your apps install base. Storage capacity (MB) is the total amount of storage provisioned per seat; it is not incremental week-to-week. Read and write capacity quotas are refreshed each week.
Paid apps | Free apps | Distributed apps | ||||
---|---|---|---|---|---|---|
First 100 seats, total | Per seat thereafter | Up to 100 seats, total | Per seat thereafter | Up to 100 seats, total | Per seat thereafter | |
Storage capacity | 400 MB | 4 MB | 200 MB | 2 MB | 200 MB | 2 MB |
Read capacity | 800 MB | 8 MB | 400 MB | 4 MB | 400 MB | 4 MB |
Write capacity | 200 MB | 2 MB | 100 MB | 1 MB | 100 MB | 1 MB |
The Forge platform has additional limits that cannot be scaled with your app's usage. Rather than exceeding these limits, you may need to remove some existing resources. Learn more about exceeding Forge limits and quotas.
The limits listed below apply to an app when it's invoked.
Resource | Limit | Description |
---|---|---|
Runtime seconds | 10 | Total runtime permitted before the app is stopped. |
Log lines per invocation | 100 | Number of log entries per invocation. |
Network requests | 100 | Number of network requests per invocation, excluding those made using requestJira or requestConfluence . |
The limits listed below apply to resources bundled with an app.
Resource | Limit | Description |
---|---|---|
Bundle files | 10,000 | Maximum number of files declared in a single custom UI resource bundle |
Bundle size | 50 | Maximum bundle size in megabytes (MB) for a custom UI resource |
The limits listed below apply to the Storage API for each installation of your app.
Resource | Limit | Description |
---|---|---|
Delete operations | 10 | Maximum delete operations per second |
Query operations | 10 | Maximum query operations per second |
Read operations | 50 | Maximum read operations per second |
Update operations | 10 | Maximum update operations per second |
In addition to the operations quotas above, the Storage API has the following limits.
Resource | Limit | Description |
---|---|---|
Key length | 100 | Maximum length of a key |
Key format | /^[a-zA-Z0-9:._\s-#]+$/ | Keys must match the regex |
Value size | 32 KB | Maximum size of a single persisted value |
The limits listed below apply to an app.
Resource | Limit | Description |
---|---|---|
App description | 1,000 | Maximum number of characters that the app description can have. |
App name | 1 to 50 | The app name must be between the character limits. |
App size | 100 | Maximum app size in megabytes (MB). |
Base URL | 2,048 | Maximum number of characters that the app baseUrl can have. |
Modules per app | 100 | Maximum number of unique modules that can be declared in a single app manifest. |
Resources per app | 10 | Maximum number of unique resources that can be declared in a single app manifest. |
The limits listed below apply to a developer's account.
Resource | Limit | Description |
---|---|---|
Apps | 100 | Maximum number of apps that can be created or owned by a single developer. |
App limits on this page are generally enforced through validation in the Forge CLI, where you'll immediately receive an error. These errors often have trivial fixes, such as shortening your app's name.
For the resource-bound limit errors, such as the total number of apps, you need to
remove some apps. You can uninstall an app with the forge uninstall
command.
Once all installations of that app are removed, delete the app from the
developer console.
If an app is consistently exceeding the quotas, we will reach out for an individual conversation with you to understand the usage. Repeated or prolonged failure to address requests to comply with quotas may result in further action being taken such as suspending the app.
You can also reach out to us via the Developer support Jira project.
An app may be temporarily suspended if it's negatively impacting the Forge platform.
When an app is suspended, the following actions are not available:
Invoking the app: When an app is suspended, it will not be invoked by any existing installations.
Instead, it will return an App is currently unavailable, please try again later
error.
Installing the app on new sites: Users trying to install the app will receive an
App installation is not available while the app is suspended
error.
Deploying the app: The forge deploy
command returns an
App management is unavailable while the app is suspended
error.
If your app is suspended, we'll raise a ticket on the Developer support Jira project and mention you, so that you can help us fix the issue as soon as possible. If you're not a Jira user, we’ll email you a link to the issue.
If you've got an issue with quotas or limits and you've not been contacted, you can seek assistance from the Forge developer community.
See the Forge Terms for more information.
Rate this page: