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.
Some functionality in Forge remains in Early Access Program (EAP) while we're still making changes that may break your apps. Learn more about the current functionality in EAP.
Forge TypeScript bundler, previously available as an EAP, has been removed. Use manual packaging, now available in preview, instead, running your own tsc (or a different compiler).
Manual packaging is a more flexible replacement for the TypeScript bundler. It lets developers choose an arbitrary build tool, and supports UI Kit modules in addition to the runtime bundling.
Manual packaging for Forge functions and UI Kit modules has progressed from the Early Access Program (EAP) to Preview. Manual packaging lets you bypass the fixed version of Webpack bundled within the Forge CLI and upload your code directly from specified directories without modification.
What's changing
Manual packaging is now suitable for production environments, and you no longer need to sign up for the EAP to use it. With manual packaging, you can:
Use a different compiler or TypeScript version.
Use alternative bundlers (such as Vite or Esbuild) or no bundler at all.
Include and call WebAssembly in your application.
Require data files or depend on packages that do.
Reduce application size by sharing dependencies across multiple functions.
What you need to do
If you were already using manual packaging during the EAP, no changes are required.
To get started, set bundler: manual@2026 and a path in the app.package section of your manifest for functions, or on individual UI Kit resources.
For details and examples, see Packaging and the Packaging standard.
The rovo:agentConnector module is now Generally Available (GA). This module lets you connect an AI agent hosted outside of Forge to Rovo using the Agent2Agent (A2A) protocol, so your agent can be used alongside native Rovo agents. Only A2A 1.0 is supported.
🛠️ Scheduled maintenance window from September 25 @ 5PM PST to Monday, September 28 @ 10AM, AEST
Our support portal is moving to a new home. New ticket submissions and ticket access including comments via email will be unavailable during this window. Starting September 28, submit all requests at Atlassian Support and update your bookmarks. Learn what's changing.
What’s changing?
In preparation for the upcoming Developer Preview release of Forge Static Macros, access to the early access program (EAP) for this capability is now closed.
We want to thank everyone who participated in the EAP and provided valuable feedback. Your insights have been instrumental in shaping the next phase of Forge Static Macros.
What you need to do
If you are currently participating in the EAP, you can continue to use the feature.
If you missed the EAP, stay tuned to this changelog for the Developer Preview release announcement to start building with Forge Static Macros.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-148-local-forge-storage-prototype-for-kvs-and-sql/102858
We’re upgrading Jira dashboards to a more modern and flexible experience. As part of this transition, we’re deprecating the legacy Forge modules for dashboards in favor of these new dashboard modules.
What’s changing
The following Forge modules are now deprecated and will be removed on May 17, 2027:
jira:dashboardGadget
jira:dashboardBackgroundScript
These modules are replaced by the new dashboards:widget and dashboards:backgroundScript modules, which are now General Availability (GA). The new modules are designed for the upgraded Jira dashboard surface (also referred to as AVP dashboards).
What you need to do
To ensure your dashboard extensions continue to work on the new Jira dashboard experience, you must migrate your existing modules:
Update your app manifest to use the new dashboards:widget and dashboards:backgroundScript modules.
Complete your migration before the deprecation date of May 17, 2027 to avoid service disruption for your users.
What’s changing
The new Forge dashboard modules are now generally available (GA). These modules allow you to build extensions for the upgraded Jira dashboard experience, which offers a more modern and flexible interface for users:
dashboards:widget: Used to create custom content blocks (widgets) on the new dashboard surface.
dashboards:backgroundScript: Used to run background logic for your dashboard extensions.
The new Jira dashboard experience, which utilizes these modules, is rolling out to customers starting September 23rd, 2026.
What you need to do
You can now start building and deploying apps using these modules for the new Jira dashboard experience:
Review the dashboards:widget manifest reference for configuration details and schema.
If you have existing dashboard extensions using the legacy jira:dashboardGadget or jira:dashboardBackgroundScript modules, you should begin planning your migration to these new modules.
Note that the new dashboard experience coexists with classic Jira dashboards during the rollout period.
What's changing
We are updating how Forge permission checks are implemented in Jira for asApp requests. This internal change simplifies the evaluation process and removes the requirement for permissions to be synced to Jira at installation time.
This update improves the app installation process by reducing the overhead associated with permission synchronization.
What you need to do
No action is required from you. This is an internal implementation change that does not affect how you declare permissions or use asApp in your Forge apps.
The update is being rolled out progressively on a tenant-by-tenant basis.
What's changing
The installations page in the developer console has been redesigned to scale with large app install bases. Following the EAP release, we have added two key improvements to help you manage your data:
Additional filters: You can now use new granular filtering options to find specific installations faster.
Sorting capabilities: We have enabled sorting for key columns to improve data discoverability.
These updates build on the core redesign, which includes optimized page performance for large datasets and the ability to customize your view by resizing, reordering, or pinning columns.
What you need to do
No action is required to enable these features; the updated installations page is now live for all Forge apps.
For more details, see View app installations. You can also share your feedback by selecting the Give feedback button in the Get help section of the developer console.
What's changing
We are removing support for the forge webtrigger root command to create URLs, as the deprecation window has passed. This change follows the initial deprecation announcement earlier last year.
The forge webtrigger command now requires a specific sub-command. Using the root command to generate a web trigger URL will no longer work.
What you need to do
To create a web trigger URL via the CLI, you must now use the officially supported create sub-command:
Run the following command in your app's top-level directory:
1
forge webtrigger createFollow the prompts to select your installation context and the web trigger function.
Alternatively, you can specify the function key directly:
1
forge webtrigger create --functionKey <your-function-key>For more information, see the forge webtrigger create CLI reference.
We’ve updated the Forge CLI to improve support for automation and machine-parsable workflows. Errors and warnings are now directed to stderr, ensuring that stdout remains clean for parsing structured data.
Additionally, we’ve added --json support to the following commands:
forge environments list
forge repositories list
forge repositories images list
forge webtrigger list
forge storage entities indexes list
Update to the latest version of the Forge CLI by running: npm install -g @forge/cli@latest.
If you use these commands in scripts or automation, you can now append the --json flag to recieve structured output. Ensure your scripts are configured to capture errors from stderr.
When using Jira’s List or Global Search views, you could toggle between the List and detail view. The new defaults for opening work items will be in a resizable preview (side) panel, or in a modal.
What you need to do
Review your apps: If you own apps related to the Detail view, ensure they'll work with the new work item view modalities.
Test and report issues: If you encounter any behavior issues with the new preview panel or modal, please raise a support ticket.
For more details, refer to the community announcement.
What's changing
Apps adopting Forge from Connect can now use the migratedFrom property in a Forge macro module to map one or more existing Connect macro keys to a single target Forge macro. This allows you to consolidate multiple legacy macros into a new Forge implementation.
Key details of this feature:
Resolution: Existing Confluence content that uses any of the listed Connect macro keys will automatically resolve to the target Forge macro.
Scope: The listed keys must belong to the Connect app declared in the app.connect.key field of your manifest.
Responsibility: The target Forge macro is responsible for handling the configuration and parameters stored by the previous Connect macros. Note that migratedFrom does not transform parameter schemas.
Exclusivity: A legacy macro key can be claimed by only one Forge macro on a given tenant.
Current limitation: Forge-to-Forge macro consolidation is not currently supported; this property only supports mapping Connect macro keys to Forge macros.
What you need to do
To consolidate your Connect macros, update your manifest.yml file to include the migratedFrom property under the target macro module:
1
2
3
4
5
6
modules:
confluence:macro:
- key: consolidated-macro
migratedFrom:
- old-connect-macro-a
- old-connect-macro-bFor more information on migrating macros and handling legacy data, refer to the Adopting Forge from Connect: Migrate macros documentation.
By mapping legacy Connect macro keys to a Forge macro, migratedFrom helps existing Confluence content continue to resolve correctly during the app-user migration to Forge. For background, see CONFCLOUD-84508.
Bitbucket pull request (PR) update events for Forge apps now feature an additional changes field in their payloads. This field is present when a PR is updated due to a new commit being pushed to the source branch.
This update allows Forge apps to distinguish between code-level updates (new commits) and metadata updates (such as changes to the title or description). This is a backward-compatible change; no existing fields have been removed or renamed.
What you need to do
For most apps, no action is required. If your app is already listening to Bitbucket PR update events, the additional field will automatically be available in the event payload.
However, if you validate event payloads with a strict schema, ensure your validator is updated to allow the new changes property. You can review the updated payload structures in the Bitbucket pull request updated event reference documentation.
Rate this page: