This changelog is the source of truth for all changes to the Forge platform that affect people developing Forge apps.
See what's next for Forge on our platform roadmap.
We're excited to share that Forge, our app development platform for Atlassian cloud products, is now generally available. You can rely on Forge's hosted infrastructure, storage, and FaaS functions to support apps in production; all of which are backed by Atlassian's operational readiness. Learn more about building the next Marketplace hit with Forge.
Note that some functionality in Forge remains in beta while we're still making changes that may break your apps. Learn more about the current functionality in beta.
We’ve added additional project information to the extension context for Forge custom fields on Jira Service Management portal requests. This allows accessing project.id
directly from the extension data to avoid unnecessary REST API calls.
Making an egress fetch call to an invalid URL now throws an Invalid URL
error instead of a 400
response. This updated logic is consistent with how the native Node.js fetch handles invalid URLs
We have increased the outbound request timeout for Forge apps using long-running functions from 55 seconds to 180 seconds. Outbound requests refer to fetch requests, including both product REST API and external API requests.
Forge developers can use long-running functions when processing async events, allowing functions to run for up to 15 minutes. Currently, a single outbound request will timeout after 55 seconds. This change increases the timeout of a single outbound request from 55 seconds to 180 seconds, and is now documented in https://developer.atlassian.com/platform/forge/platform-quotas-and-limits/#invocation-limits.
This prevents premature timeouts and allows Forge apps to accommodate more complex operations, such as handling large data processing tasks. This change applies to all outbound requests made from Forge functions.
We’ve added new Confluence product events for labels:
avi:confluence:created:label
avi:confluence:added:label
avi:confluence:removed:label
avi:confluence:deleted:label
You can use these events to invoke your Forge app function when label is created, added to an entity, removed from an entity, or deleted. For more details see https://developer.atlassian.com/platform/forge/events-reference/confluence/#labels.
The URL of the page on which a module is being rendered has been added to its extension context. extension.location
will be returned in the context object from view.getContext().
Following its Preview release, we’re excited to announce that the Runs on Atlassian program is now generally available.
This means that customers can now see the Runs on Atlassian
badge for eligible apps on the Atlassian Marketplace. Similarly, customers can also filter for eligible apps.
Check out Runs on Atlassian documentation to know more about the program, as well as the eligibility requirements and the next steps you can take.
With the Forge CLI 11.5.0 release, we've enhanced the Forge platform to let you specify the memory available to functions at runtime by setting the memoryMB
property in the Manifest (https://developer.atlassian.com/platform/forge/manifest-reference/#runtimev2) . Increasing the function memory also increases its CPU allocation. The memory value can now be set between 128 MB and 1,024 MB, doubling the previous limit of 512 MB. If you do not configure the function memory, the default memory allocation of 512MB applies to your function. This change helps address out-of-memory (OOM) issues by allowing higher memory allocation.
For more information on configuring Forge function memory, see https://developer.atlassian.com/platform/forge/manifest-reference/#runtimev2.
For details on the relationship between memory and CPU allocation, refer to the https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html.
Following the initial release of the forge version
command in Forge CLI, we’re introducing more improvements to amplify the usage of the command.
You can now compare versions across two different environments, which lets you, for example, compare your major app version between development
and production
environments:
1
forge version compare --version1=10 --environment1=development --version2=3 --environment2=production
The output then includes the following details:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
forge version compare --version1=10 --environment1=development --version2=3 --environment2=production
✔ Comparing app versions...
ℹ Comparison between app versions [10 in development] and [3 in production] is shown below:
┌─────────────────┬──────────────────────────────────────────────────┬──────────────────────────────────────────────────┐
│ Property │ Version 10.x [development] │ Version 3.x [production] │
├─────────────────┼──────────────────────────────────────────────────┼──────────────────────────────────────────────────┤
│ deployment date │ "2024-11-05T06:18:03.129Z" │ "2024-12-17T04:38:54.678Z" │
├─────────────────┼──────────────────────────────────────────────────┼──────────────────────────────────────────────────┤
│ egress │ [] │ [ │
│ │ │ { │
│ │ │ "addresses": [ │
│ │ │ "https://google.com" │
│ │ │ ], │
│ │ │ "type": "fetch.backend" │
│ │ │ } │
│ │ │ ] │
├─────────────────┼──────────────────────────────────────────────────┼──────────────────────────────────────────────────┤
Run npm install -g @forge/cli@latest
on the command line to install the latest version of @forge/cli
and receive these changes.
We’ve released a new module, Confluence page banner, which enables apps to add a banner to Confluence pages. This module is generally available.
This feature provides equivalent Forge functionality to the Connect Confluence atl.general web panel.
We've released support for all Forge custom field types on Jira Service Management portal requests. To use Custom UI or UI Kit for app rendering, specify the portal-request
experience in the edit
entry point. This change aims to enhance the flexibility and functionality of custom fields in the Jira Service Management portal.
Developers should follow the https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field/#portal-request--preview- to implement this feature. Please note that anonymous access and Jira Service Management portal view support are coming soon.
We’ve started the customer rollout for the Runs on Atlassian program. This means that some customers can now see the Runs on Atlassian
badge for eligible apps on the Atlassian Marketplace and on the Connected apps page of Atlassian Administration.
To ensure a smooth transition, we’re progressively rolling this out to customers over the next few days. We’ll provide another update upon completion.
Check out Runs on Atlassian documentation to know more about the program.
We've introduced a new Forge CLI command, forge version bulk-upgrade
, to streamline the process of upgrading multiple versions. This command includes subcommands for starting, listing, and canceling upgrades.
This new CLI command will allow you to upgrade all installations of the app on an eligible older major version to a newer one. A version is eligible for upgrade to any new version of the app that does not require an elevation of privileges. The benefit of these upgrades is that customers can access new functionality in the app, and teams developing apps can reduce maintenance and support requirements by moving customers off older versions of the app.
You can use the Forge CLI to start, cancel and list these bulk major version updates, without site admin approval.
forge version bulk-upgrade start
: Initiates the bulk upgrade rollout process.
forge version bulk-upgrade list
: Displays all ongoing and completed rollout upgrades.
forge version bulk-upgrade cancel
: Allows you to cancel an ongoing rollout.
As part of Runs on Atlassian, customers can choose to enable or disable access to analytics from admin.atlassian.com. This feature ensures that apps utilizing analytics by egressing to analytic tools can still qualify for Runs on Atlassian while putting customers in full control of their data.
The status for whether analytics access is enabled or disabled is now displayed for each installation on the Installations page.
With the recent updates to our content delivery network (CDN), all apps now allow-list the Atlassian media API URL by default in client.fetch
. This means you no longer need to declare egress to load objects coming from the media API in forge apps.
These recent updates can effectively help you reduce egress from your apps.
These updates can help if you’re looking to make your app eligible for the Runs on Atlassian badge. To know more about Runs on Atlassian, see this developer blog post.
Note, the removal of egress does not require a major version update of apps.
Look for opportunities to remove the following external permissions from your manifest:
1
2
3
4
5
permissions:
external:
fetch:
client:
- api.media.atlassian.com
We've fixed an issue where Forge async events were not delivered if the app version linked to the pushed async event was upgraded before event processing began. It is important to note that event processing begins after the delayInSeconds
duration specified in the Push API.
With this fix, when an async event processing starts, the event will no longer be checked against the app’s version.
Starting from Nov 21, 2025. this fix will be implemented for all apps.
If you want to adopt this fix before the general rollout, you can enable it by adding the temporary property, crossVersion: true
in your app’s https://developer.atlassian.com/platform/forge/manifest-reference/modules/consumer/ module configuration. For example:
1
2
3
4
consumer:
- key: test-consumer-key
queue: test-queue-name
crossVersion: true
Note: After Nov 21, 2025, the crossVersion: true
property will be removed, and by default, the event will no longer be checked against the app’s version.
To maintain backwards compatibility when handling events from earlier versions, we advise embedding a schema version within the payload of an Async Event. This version can then be accessed upon delivery.
It is important to note that currently Async Events originating from previous app versions are successfully processed once they are accepted and processing started, even if the app version is upgraded during this time. This update addresses situations where the processing of Async Events cannot start due to a mismatch in app versions.
Rate this page: