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 apps, 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.
What's changing
Forge now supports offline impersonation for Jira Service Management (JSM) portal-only users. This follows our June 12, 2026 release of online impersonation support.
You can now use asUser(accountId) to make asynchronous or background API calls on behalf of portal-only users (also known as customer accounts). For apps using Forge remotes, offline impersonation is supported via the offlineUserAuthToken mutation.
This allows your apps to perform background actions, such as processing data or updating requests, in the context of the portal-only user, while maintaining the appropriate permission checks.
Note that portal-only users can only make asUser() calls to Jira/JSM APIs using corresponding scopes declared in the manifest file.
What you need to do
To use offline impersonation for portal-only users in your app:
Ensure your app has the required scopes declared in the manifest.
Use the asUser(accountId) method in your backend code to call product APIs.
If you are using Forge remotes, implement the offlineUserAuthToken mutation to obtain the necessary credentials.
Redeploy your app to apply these changes.
For more information on how Forge handles access for unlicensed users, see our documentation.
Previous changelog release for online impersonation: https://developer.atlassian.com/platform/forge/changelog/#CHANGE-3278
Reference docs for implementation of offline impersonation in Forge:
You can now configure a Forge Containers service to scale down to zero running instances in non-production environments when it's idle.
Scaling to zero helps reduce costs in non-production environments by ensuring you only reserve compute capacity when your service is actively handling traffic. You can enable this behaviour for a service in your app's manifest.
What's changing
You can now set the min scaling property to 0 for Forge Containers services.
This behavior is supported in DEVELOPMENT and STAGING environments.
Forge Containers remains in Early Access (EAP). Features under EAP are subject to change and are not recommended for production use.
What you need to do
To enable scaling to zero, update your service's scaling configuration in the manifest.yml file:
1
2
3
4
5
services:
- key: example-service
scaling:
min: 0
max: 2For more information, see the Forge Containers manifest reference.
As per our previous announcement, admin-facing Connect end-of-support (EOS) migration messaging on the Connected Apps page is now rolling out to production instances. This messaging, which was previously limited to Developer Canary tenants, is being deployed in staggered cohorts.
The following app categories will begin receiving admin-facing messaging in production:
Apps that have declared connectToForgeMigration with a migration intent of NO
Apps that have declared connectToForgeMigration with a migration intent of UNDECIDED
Apps that have not adopted the connectToForgeMigration module
Apps without a Forge manifest (Connect apps)
Apps that have declared connectToForgeMigration with an intent of YES are estimated to begin receiving admin messaging in mid-August. We will provide another changelog entry at least 2 weeks before that change proceeds.
What you need to do
Adopt the connectToForgeMigration module in your Forge manifest for each major version of your app (https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-to-forge-migration-module/) if you have not already.
Declare your migration intent - this determines which cohort your app falls into and when messaging appears.
Provide a migration URL - this URL will be surfaced directly in customer-facing notices, replacing the default Atlassian messaging with your app-specific guidance.
For details about the full customer-facing experience, see What admins see on the Connected Apps page.
Exemptions
Apps that are blocked by an accepted Connect EOS FRGE ticket will be exempt from customer messaging until one month past the delivery date of the blocking feature. This exemption list is determined exclusively by partners who have submitted a Connect EOS Submission request on these accepted tickets, providing a valid use case and explanation and applies to only the apps that have been marked as affected by the feature in the submission. If an app utilises an affected feature but has not submitted a Connect EOS submission, it will not be exempted from this messaging.
End-user messaging is not included in this rollout. When available, we will follow the same approach of releasing to Developer Canary tenants first for partner testing, roll out in staggered cohorts, and provide at least 2 weeks advance notice via this changelog before each stage goes live.
You can now register confluence:contentProperty module dynamically at runtime, per installation, using the https://developer.atlassian.com/platform/forge/apis-reference/dynamic-modules/. This brings the same dynamic registration capability already available for Jira entity properties (jira:entityProperty) to the Confluence side.
Please see the documentation here for further details.
A new RFC is ready for review at https://community.developer.atlassian.com/t/rfc-140-updating-categories-in-the-editors-element-browser/101855
Support for Claude Opus 4.8 model is now available in Forge LLMs. For the exhaustive list of supported models, refer to our documentation here
Support for Claude Sonnet 5 model is now available in Forge LLMs. For the exhaustive list of supported models, refer to our documentation here
Point-to-Point logs export is now available in Early Access (EAP). This feature allows Atlassian to push Forge app logs directly to your preferred logging tool across all environments, including production.
During this EAP, we support the following tools:
Datadog
Sumo Logic
Amazon CloudWatch (US region only)
Splunk
What you need to do
Review the setup guide to understand how to share your tool details with us in the EAP form.
What's changing
Forge apps can now provide custom search suggestions for searchAlias properties of Forge object custom fields.
If your app already uses searchSuggestions, you can enable it for a specific alias by setting searchSuggestionsEnabled: true on the object schema property that defines that searchAlias. When users write JQL against that alias, Jira will show app-provided suggestions instead of default indexed values.
What you need to do
If your Forge object custom field already uses searchSuggestions and you want those suggestions to apply to a searchAlias:
Update your app's manifest to set searchSuggestionsEnabled: true on the schema property that defines the alias.
Ensure your searchSuggestions function is configured to handle requests for the alias.
No action is needed if your app doesn’t use search aliases, or if you want aliases to keep using Jira’s default autocomplete.
For more information, consult the https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field reference documentation.
As per our previous announcement, we will be progressing admin-facing migration messaging on the Connected Apps page from the Developer Canary Program to production instances. This rollout will begin in approximately two weeks.
The following app categories will receive admin-facing messaging:
Apps that have declared connectToForgeMigration with a migration intent of "no"
Apps that have declared connectToForgeMigration with a migration intent of "unsure"
Apps that have not adopted the connectToForgeMigration module
Apps without a Forge manifest (i.e., Connect apps)
Apps that have declared connectToForgeMigration with an intent of "yes" are estimated to begin receiving admin messaging in mid-August. We will provide another changelog entry at least 2 weeks before that change proceeds.
End-user messaging will not be included in this initial rollout. When ready, we'll follow the same approach:
Release to Developer Canary tenants first for early testing
Roll out in staggered cohorts
Provide at least 2 weeks advance notice via the Forge changelog before each rollout stage goes live
Adopt the connectToForgeMigration module in your Forge manifest for each major version of your app (https://developer.atlassian.com/platform/adopting-forge-from-connect/connect-to-forge-migration-module/).
Declare your migration intent as this determines which cohort your app falls into and when messaging appears.
Provide a migration URL. This URL will be surfaced directly in customer-facing notices, replacing the default Atlassian messaging with your app-specific guidance.
Preview the experience now using the Developer Canary Program. Customer messaging is already live on canary tenants. Install your app on a canary instance, navigate to the Connected Apps page, and confirm your migration URL renders as expected before the production rollout reaches your cohort.
Apps that are blocked by an accepted Connect EOS FRGE ticket will be exempt from customer messaging until one month past the delivery date of the blocking feature. This exemption list is determined exclusively by partners who have submitted a Connect EOS Submission request on these accepted tickets, providing a valid use case and explanation. If an app utilises an affected feature but has not submitted a Connect EOS submission, it will not be exempted from this messaging.
For the full customer-facing experience (including more information on what admins will see), please visit the documentation here. This page will also be shortly updated to capture our rollout approach.
Support for Claude Opus 4.7 model is now available in Forge LLMs. For the exhaustive list of supported models, refer to our documentation here
Forge multi-entry resource bundles are now generally available in Jira and Confluence. This feature allows you to group multiple named entry points within a single resource, helping you optimise app performance and stay within resource limits.
What's changing
Multi-entry resource bundles allow you to define multiple entry points for a single resource in your Forge manifest. This is particularly useful for complex apps that need to share code between different parts of the UI while keeping the overall bundle size manageable.
What you need to do
To get started with multi-entry resource bundles, you can update your manifest.yml to include multiple entry points under a single resource. For more details, see the documentation here.
Note: This feature is not yet supported in Atlassian Government Cloud.
From Jul 8, 2026, we will begin removing the temporary restriction announced in CHANGE-3109 that required every update to Connect to Forge apps with over 50,000 users to be classified as a major version update. We will contact partners first before lifting the restriction on their app(s).
This restriction was introduced as a temporary safety measure to protect downstream Forge services from sudden traffic spikes during large version migrations. Since then, we have completed significant scaling and reliability work across the affected services, so we are now able to return these apps to the normal minor version update path.
Affected Forge apps can return to using minor version updates, rather than being forced into major version updates and forge version bulk-upgrade batches.
You will still be able to use forge version bulk-upgrade if you prefer a controlled, batched rollout - this remains available and unchanged.
For detailed information on how to use forge version bulk-upgrade, see https://developer.atlassian.com/platform/forge/cli-reference/version-bulk-upgrade/.
To avoid any unexpected impact on in-flight migration activities, we will not automatically re-enable minor version updates for every affected app at once. Instead:
We will contact affected partners individually to confirm whether you would like minor version updates re-enabled for your app, and to coordinate timing against your current migration plans.
If you would like the restriction removed for your app now, please reach out to Ecosystem Support, and we will action the request.
What's changing
You can now control access for the jira:uiModifications module for different user types:
Anonymous – users who are not logged in
Unlicensed – users invited to a Jira space without a license (guests in case of Jira)
Customer – JSM portal customers
By default, Forge apps only run for licensed Jira and Jira Service Management users. With this update, you can allow your UI Modifications app to run for anonymous, unlicensed, or customer users by declaring it in your app manifest.
As previously announced, from Jun 29, 2026, UI Modifications will not run for anonymous, unlicensed or customer account users unless the module explicitly declares support for these user types in the Forge app manifest.
What you need to do
To allow your app to work for anonymous, unlicensed, or customer users, add the unlicensedAccess property to the jira:uiModifications module in your manifest.yml file.
1
2
3
4
5
6
7
8
9
10
11
modules:
jira:uiModifications:
- key: ui-modifications-app
title: UI modifications
resource: uiModifications
resolver:
function: resolver
unlicensedAccess:
- anonymous
- unlicensed
- customerOnly include the user types your app needs. For example, if your app only needs to work for anonymous users:
1
2
unlicensedAccess:
- anonymousFor detailed steps, refer to the https://developer.atlassian.com/platform/forge/access-to-forge-apps-for-unlicensed-users/.
What’s changing?
In preparation for the upcoming Developer Preview release of Forge Containers, 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 Containers.
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 Containers.
Rate this page: