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.
We're introducing limits on the number and size of Forge environment variables and secrets to ensure the stability and reliability of the service for all apps.
What’s changing
The following limits now apply to each environment of your app, and are checked when you run forge variables set and forge deploy:
Plain variables: up to 50 per environment.
Encrypted variables (secrets): up to 10 per environment.
Variable value size: up to 3,072 bytes (3 KB) for both plain and encrypted variables. Size is measured before encryption.
Variable key length: up to 128 characters.
What you need to do
Check that your apps stay within these new limits.
If you store large values in environment variables, move them to Forge storage.
If your app currently exceeds these limits in any environment, update your variables by Tuesday, May 11, 2027.
If you require a higher limit for a specific use case, reach out via the developer support portal.
For more details, see the Environment variable limits documentation.
What’s changing
The requestTeamworkGraph() Forge bridge API has moved from the Early Access Program (EAP) to Preview.
You can query Teamwork Graph directly from UI Kit and Custom UI frontends using @forge/bridge, without routing requests through a Forge backend function.
Requests run on behalf of the current user and respect their permissions. Your app must also declare the scopes required by each query.
What you need to do
Update @forge/bridge in your app’s frontend directory:
1
npm install @forge/bridge@latestReview the permissions in your manifest.yml and declare the scopes required for the objects your queries access. See the Teamwork Graph scopes reference.
Use requestTeamworkGraph() to execute queries from your frontend.
For implementation details, see the requestTeamworkGraph reference and Teamwork Graph API guide.
What's changing
You can now customise the background of the platform-managed ADF renderer iframe in Forge Custom UI bodied macros. By using the new background option in view.createAdfRendererIframeProps(), you can ensure your rendered content blends seamlessly with your app's design and the Confluence theme.
Supported values for the background option include transparent, Atlassian Design System background tokens and hex colour codes.
What you need to do
To use this feature, update your @forge/bridge package to the latest version and update your macro's implementation:
Ensure your macro is configured as a bodied macro in manifest.yml with layout: bodied.
Update your call to view.createAdfRendererIframeProps() to include the background property
For more information, see documentation.
Forge Object Store is deprecating the allowed values in the checksumType field in the createUploadUrl and createPublicUploadUrl methods in @forge/object-store package and in GeneratedMetadata as part of objectStore API in the @forge/bridge package . All checksums are now required to use the SHA256 algorithm.
Starting December 10, 2026, any requests using other checksum types (such as SHA1, CRC32, or CRC32C) will be rejected with an HTTP 400 Unsupported Media Type status and the error code CHECKSUM_TYPE_UNSUPPORTED.
We will be releasing a new major version of the @forge/object-store package that removes all other types from the checksumType field except for SHA256.
What you need to do
Update your app code to ensure all objects are hashed using the SHA256 algorithm.
If you are manually passing checksumType to createUploadUrl or createPublicUploadUrl, update the value to 'SHA256'.
Upgrade to the latest major version of @forge/object-store once available to align with the new API signature.
For more details on how to implement SHA256 checksums, refer to the Forge Object Store API documentation.
If your app currently uses a different checksum type and you cannot migrate within the 1-month window, please reach out via an ECOHELP ticket.
Summary
Support inline-bodied layouts for Confluence Forge macros
Description
Confluence Forge macros now support layout: inline-bodied for macros with rich-text bodies that should render inline with surrounding text. This layout supports both UI Kit and Custom UI, including macros migrated from Connect.
What you need to do
Use Forge CLI 14.0.0 or later.
Set layout: inline-bodied on the relevant macro module in your manifest.yml.
If you are migrating a Connect macro with bodyType: rich-text and outputType: inline, apply this layout to the corresponding Forge macro.
Layout behavior
Macros appear as blocks while editing, this is the default behavior from Confluence Data Center and the Legacy Editor. Inline presentation in view mode requires a single paragraph of inline-compatible content. Multiple paragraphs or block elements, such as tables, lists, and headings, cause the macro to render as a block.
Export behavior depends on the export context and the content returned by your adfExport function. See the macro reference for supported behavior and requirements.
Documentation
Forge apps can now make online and offline calls on behalf of unverified user accounts using user impersonation including invocations from Forge functions and Forge Remote.
Online calls use the invoking user's context, while offline calls can act on behalf of a specified unverified user asUser(accountId) where supported.
Existing Forge app permissions, product permissions, and API-specific access controls continue to apply. This change does not enable anonymous-user access.
This includes support for unverified external customer accounts in Jira Service Management (such as email-created portal customers with qm: account IDs), as well as unverified Atlassian accounts
Forge storage data residency moves no longer cause host product downtime
Until now, moving an app's Forge-hosted storage to another region meant taking its host product offline. That happened even when the host product had already moved.
Now, only the app installation being moved goes offline. The host product, and any other Atlassian product the app is linked to, remains fully available throughout the move.
What's affected while the app installation is offline
Storage, functions, and UI are unavailable: Calls to Forge-hosted storage, backend function invocations, resolver-driven UI, and dynamic component updates are blocked.
Upgrades and uninstalls are paused: Major version upgrades and uninstalls can't run until the move is finished.
Product events are queued, not lost: Atlassian product events sent to the app during the move are held and delivered automatically once the move completes.
This change applies automatically to all apps that use Forge-hosted storage
Forge is enabling user-token support for unlicensed users in Forge function and Forge Remote invocations.
Apps can make online and offline calls on behalf of eligible unlicensed users, including calls from Forge resolvers and Forge Remote. Online calls use the invoking user’s context, while offline calls can act on behalf of a specified user where supported.
Existing Forge app permissions, product permissions, and API-specific access controls continue to apply. This change does not enable anonymous-user access.
This includes support for eligible unlicensed users accessing apps through the Jira Service Management portal.
The Forge global:ui module has moved from the Early Access Program (EAP) to Preview. You can now build apps that look and feel like Atlassian core products, featuring configurable side navigation and a dedicated entry in the Atlassian app switcher.
What’s changing
Increased sidebar customization: New components are available for the sidebar, including MenuSection, MenuSpacer, ReorderableMenuItems, SidebarFooter, and SearchableFlyoutMenuItem. You can also use UI Kit and custom icons.
Relevant search results: The Rovo search bar now prioritizes results from Teamwork Graph objects associated with the global:ui app you are viewing.
Custom search results pages: Pressing Enter in the search bar now navigates to your app’s /search?text=<input> route, allowing you to build a custom search results experience.
Compatible with all installation models: The global:ui module is now compatible with site, cross-context, and unit-level installations.
What you need to do
Review the global:ui documentation to understand the module's capabilities.
Explore the component reference for details on the new sidebar components.
Learn more about ingesting Teamwork Graph objects to improve search relevance for your app.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-154-ui-modifications-for-forge-custom-fields-in-jira-and-jsm/103577
What's changing
We're introducing a new sharing level for Forge and OAuth 2.0 (3LO) apps: organization-level sharing. With it, you can share your app with anyone in the same Atlassian organization as the app owner.
Key details:
Restricted installation: Only members of the app owner's organization can install the app using the installation link.
Existing installations: If you change a publicly shared Forge app to organization-level sharing, existing installations on sites outside your organization will keep working.
Upgrade restrictions: For apps updated to organization-level sharing, future app upgrades will only be available to members of the app owner's organization. Installations outside the organization stay on the current version unless upgraded by the app developer.
What you need to do
To use this new sharing level:
Navigate to the Developer Console and select your app.
Select Distribution from the left menu.
Under Distribution controls, select Edit.
Choose the Sharing within organization option and save your changes.
For more information on app distribution, see the distribute your apps documentation.
What's changing
We've updated the minimum compatible Node.js version for the Forge CLI. The CLI now requires Node.js 22.23.4, 24.22.1, 26.12.1, or newer.
Node.js 20 has reached end of life and is no longer supported. To continue using the Forge CLI to develop and deploy your apps, you must upgrade your local development environment to one of the supported versions listed above.
What you need to do
Check your current Node.js version by running node -v in your terminal.
If you are running a version older than the requirements, download and install a supported version from the Node.js website.
Update your Forge CLI to the latest version by running:npm install -g @forge/cli@latest
Verify the installation by running forge --version.
For more information on setting up your development environment, see the Getting started guide.
Registering the new bitbucket:deploymentCheck module. You can use this module to build custom deployment checks for Bitbucket Cloud. The motivation for this change is laid out here, with the aim to create a centralised checks platform. Some more details on future strategy and vision is mentioned in this doc.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-152-increasing-maximum-memory-for-forge-functions/103441
As previously announced, the jira:fullPage and confluence:fullPage modules have been removed on 30 September 2026 in favor of the unified global:fullPage module.
What’s changing
The product-specific jira:fullPage and confluence:fullPage modules are no longer supported in the Forge manifest.
Requests routed to legacy URLs will automatically forward to the corresponding global:fullPage URL.
Users accessing legacy paths will see a prompt to update their bookmarks.
Automatic forwarding support will be maintained until December 18, 2026.
If you haven’t already migrated your apps, refer to global:fullPage documentation to get started: https://developer.atlassian.com/platform/forge/manifest-reference/modules/global-full-page/
Rate this page: