Last updated Nov 28, 2023

Platform quotas and limits

We’re excited to kickstart the Forge journey by extending free use of the Forge platform through 2024. 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.

If your app consistently exceeds the quotas or limits, we will contact you. You can also contact us if you think your app needs higher quotas or limits. Learn more about exceeding Forge limits and quotas.

These guidelines apply until the end of December 2024.

Usage-based quotas

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.

As you estimate your app's usage relative to the quotas and limits below, remember that the number of active users at any given point in time will likely be lower than the number of licensed seats for an installation, which would give your app some headroom.

Jira issue panel app example

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 invocations20,200 minutes99 GB
Storage
Storage capacity (seats)Reads (weekly)Writes (weekly)
40,400 MB80,800 MB20,200 MB
Resource updates
File upload (weekly)File uploads (weekly)
150 MB500 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.

Calculate FaaS usage

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
 (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
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)

Calculate resources usage

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
2
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.

Installation quotas

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:

  • Paid apps - Apps listed on the Atlassian Marketplace with a paid license.
  • Free apps - Apps listed on the Atlassian Marketplace with a free license.
  • Distributed apps - Apps distributed via the developer console.

Function as a Service quotas

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. These quotas are refreshed weekly.

 Paid appsFree appsDistributed apps
 First 100 seats, totalPer seat thereafterUp to 100 seats, totalPer seat thereafterUp to 100 seats, totalPer seat thereafter
Invocations (weekly)100,000 invocations1,000 invocations50,000 invocations500 invocations50,000 invocations500 invocations
Runtime (weekly)400 minutes4 minutes200 minutes2 minutes200 minutes2 minutes
Data returned (weekly)2,000 MB20 MB1,000 MB10 MB1,000 MB10 MB

Resource update quotas

These quotas apply to the static resources packaged with your app that are used by custom UI functions. Note that Forge JavaScript functions and dependencies are not counted towards the app’s quota. Resource quotas are consumed per deployment to your production environment; deployments to development and staging environments are unmetered. These quotas are refreshed weekly.

 Paid appsFree appsDistributed apps
 Per appPer appPer app
File capacity (weekly)150 MB75 MB75 MB
Files uploaded (weekly)500 files250 files250 files

Storage quotas

In 2024, Forge hosted storage will automatically include data residency. This means that all app data in Forge hosted storage will inherit data residency, in all current and future Atlassian-supported regions.

This implementation will provide your customers with greater control over their app data’s location. For more information, read this announcement.

These quotas apply to usage of the Forge Storage API in any environment, and scale with the number of seats in your app's install base.

If an installation decreases its seat count, quotas will currently not decrease accordingly. This may change in the future, at which point we will provide guidance on how to react to these events. Meanwhile, follow your GDPR responsibilities with respect to storing, reporting and erasing user data.

As with all quotas and limits, if you suspect the Storage API quotas will prevent you from implementing your Forge app, contact us to discuss your use case.

Total storage capacity quota

Storage capacity (MB) is the total amount of storage provisioned per seat for each installation of your app. These quotas are tracked in terms of raw format size.

The Storage API provides a way to store sensitive credentials (secrets), which is subject to a separate total storage quota from general storage.

 Paid appsFree appsDistributed apps
 First 100 seats, totalPer seat thereafterUp to 100 seats, totalPer seat thereafterUp to 100 seats, totalPer seat thereafter
Storage capacity1200 MB12 MB600 MB6 MB600 MB6 MB
Secret storage capacity200 MB2 MB100 MB1 MB100 MB1 MB

Weekly storage transfer capacity quotas

Read and write capacity quotas are the amount of data that can be transferred in or out of the Storage API each week, per seat. These quotas are refreshed weekly, and are tracked in terms of raw format size.

 Paid appsFree appsDistributed apps
 First 100 seats, totalPer seat thereafterUp to 100 seats, totalPer seat thereafterUp to 100 seats, totalPer seat thereafter
Read capacity per week2400 MB24 MB1200 MB12 MB1200 MB12 MB
Write capacity per week600 MB6 MB300 MB3 MB300 MB3 MB

Platform limits

The Forge platform has additional limits that cannot be scaled with your app's usage. To prevent your app from exceeding these limits, you may need to tune your app or remove some resources. Learn more about exceeding Forge limits and quotas.

Invocation limits

An app can be invoked by users, webtriggers, or scheduled triggers. The following limits apply to all three:

ResourceLimitDescription
Invocation rate limit500Maximum number of invocations per 25-second sliding window. That is, an app reaches this limit when it is invoked 500 times within the last 25 seconds.
Runtime seconds
(also includes UI modules invoked by Forge remote)
25Maximum runtime permitted before the app is stopped.
Runtime seconds (async events)55Maximum runtime permitted before the app is stopped. This applies to `function` modules that are only referenced by `consumer` modules.
Runtime seconds
(events invoked by Forge remote)
5Maximum runtime permitted before the app is stopped. This applies to remote back ends receiving events from the Atlassian platform.
Log lines per invocation100Maximum number of log entries per invocation.
Log size per invocation200KBMaximum size of all log line data generated per invocation.
Log file size per download100MBMaximum file size of filtered logs per download.
Log lines per download96,000Maximum number of log entries per download.
Network requests100Number of network requests per invocation, excluding those made using requestJira or requestConfluence.
Memory128MB (for the current runtime)Available memory per invocation.

The new native Node.js runtime has 512MB of memory available per invocation. For a complete list of updates and benefits of provided by this new runtime, see New native Node.js runtime (Preview)

Resource limits

The limits listed below apply to resources bundled with an app.

ResourceLimitDescription
Bundle files10,000Maximum number of files declared in a single custom UI resource bundle
Bundle size50Maximum bundle size in megabytes (MB) for a custom UI resource

Storage limits

In 2024, Forge hosted storage will automatically include data residency. This means that all app data in Forge hosted storage will inherit data residency, in all current and future Atlassian-supported regions.

This implementation will provide your customers with greater control over their app data’s location. For more information, read this announcement.

When using the app storage API, we strongly recommend that you:

  • only use encrypted environment variables and storage.setSecret to store secrets or credentials in your app.
  • avoid using the app Storage API for storing files.
  • avoid employing data models with entities that grow in an unbounded manner (in terms of depth and/or size), as this may lead to exceeding storage limits.

The Atlassian Cloud backs up the entire hosted storage for disaster recovery. This includes content stored from the Forge storage API.

Storage API operation limits per installation

If an installation of your app exceeds these limits due to bulk processing (for example, triggered by a bulk issue update in Jira), consider using the Async events API to queue your app's interactions with the Storage API. See Queue app interactions with storage API for guidance.

The limits listed below apply to the Storage API for each installation of your app.

ResourceLimitDescription
Delete operations400Maximum number of delete operations per 20 seconds
Query operations200Maximum number of query operations per 20 seconds
Read operations1000Maximum number of read operations per 20 seconds
Update operations1000Maximum number of update operations per 20 seconds

Storage API key and object size limits

The Storage API has the following limits on keys and values.

You don't need to include any identifiers for apps or installations in your key.

Internally, Forge automatically prepends an identifier to every key, mapping it to the right app and installation. This lets you use the full key length without risking conflicts across apps or installations.

ResourceLimitDescription
Key length500Maximum length of a key
Key format/^(?!\s+$)[a-zA-Z0-9:._\s-#]+$/Keys must match the regex
Value size240 KBMaximum size of a single persisted value (in RAW)
Object depth31Maximum object depth permitted

Custom entities limits

Custom entities (used for complex queries) are subject to the following limits:

CategoryRequirementsLimits
Entity

Entity names:

  • Must only consist of the following characters a-z0-9:-_.
  • Must follow the regex pattern [_a-z0-9:-.]
  • Cannot start with - or _
  • Must not begin or end with a .
  • Must not contain the sequence ..

In addition, an app must not have duplicate entity names.

  • An app can have a maximum of 20 entities
  • Each entity can have a maximum of 7 indexes and 50 attributes
  • Objects that can be stored as custom entities have a maximum depth of 31 and a maximum size of 240KB (RAW) per object
Attribute Attribute names must follow the regex [_A-Za-z][_0-9A-Za-z]*. Attribute names have a maximum length of 64 characters.
Index

Index names must contain only the following characters a-zA-Z0-9:-_., and must adhere to the following requirements:

  • Must not begin or end with a .
  • Must not contain the sequence ..
  • Must not be empty

In addition, each index name within an entity must be unique.

  • Each entity can have a maximum of 7 indexes
  • The size of combined values for all range attributes on any defined index cannot exceed 900 bytes
  • The size of combined values for all partition attributes on any defined index cannot exceed 1700 bytes
  • Index names cannot be shorter than 3 characters or longer than 50 characters in length.
Keys

A key should:

  • Follow the regex pattern /^(?!\s+$)[a-zA-Z0-9:._\s-#]+$/
  • Contain at least 1 character
  • Not be empty
  • Not contain only blank space(s)
A key can contain a maximum of 100 characters.

In addition, each complex query can only have a maximum of 100 conditions (for example, beginsWith, contains, and isGreaterThan). This limit applies to conditions used in where, andFilter, and orFilter filters.

Async events limits

The limits listed below apply to the Async events API for each installation of your app.

ResourceLimitDescription
Event per request50Maximum number of events pushed in a single request
Event per minute500Maximum number of events pushed in one minute
Payload size200kbMaximum combined payload size of events in single request
Cyclic invocation limit1000An event resolver can push more events to the queue thus creating a cycle. This limit applies to the maximum cyclic depth up to which events resolver can push more events to the queue.

App limits

The limits listed below apply to an app.

ResourceLimitDescription
App description1,000Maximum number of characters that the app description can have.
App name1 to 60The app name must be between the character limits.
App size100Maximum app size in megabytes (MB).
Base URL2,048Maximum number of characters that the app baseUrl can have.
Modules per app100Maximum number of unique modules that can be declared in a single app manifest.
Resources per app10Maximum number of unique resources that can be declared in a single app manifest.
Environments per app25Maximum number of environments in a single app.

Developer limits

The limits listed below apply to a developer's account.

ResourceLimitDescription
Apps100Maximum number of apps that can be created or owned by a single developer.

Apps exceeding quotas or limits

If your app exceeds any quotas or limits, you can often fix the issue yourself:

  • Most app limits are enforced through Forge CLI validation, where you'll immediately receive an error. Most errors have trivial fixes, such as shortening your app's name.

  • For resource-bound limit errors (such as the total number of apps), you need to remove the relevant resources. You can uninstall an app with the forge uninstall command. Once you remove all installations of an app, delete it from the developer console.

We understand that some quotas can be hard to monitor; as such, we are working on better monitoring tools for future releases. Meanwhile, if we detect that your app consistently exceeds our quotas or limits, we'll first contact you to understand why. If your app needs higher storage capacity or a higher cyclic invocation limit, you can contact us through Developer and Marketplace support. If your app needs an increase in other quotas or limits, please let us know through the Forge Jira Project.

We aim to unblock reasonable use cases, and we will work with you to achieve this. However, repeated or prolonged failure to address requests to comply with quotas may result in further action being taken (such as app suspension).

Suspended apps

An app may be temporarily suspended if it negatively impacts the Forge platform, regardless of whether it’s in breach of any quotas or limits.

Suspended apps cannot be:

  • Invoked: Suspended apps cannot be invoked by any existing installations. Invoking a suspended app will return an App is currently unavailable, please try again later error.

  • Installed: Attempting to install a suspended app will return an App installation is not available while the app is suspended error.

  • Deployed: Running forge deploy command on a suspended app will return an App management is unavailable while the app is suspended error.

If your app is suspended, we'll submit a ticket through Developer and Marketplace support 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 have an issue with quotas or limits but haven't been contacted by our team, you can seek assistance from the Forge developer community.

See the Forge Terms for more information.

Rate this page: