Changelog

What's changing
The currentVersion field in the Forge Object Store API is deprecated and will be removed on September 1, 2026. This affects the following types:

• GetMetadataResult (Custom UI bridge)

• ObjectReference (Object Storage API return value)

What you need to do
Update your apps to use the createdAt field instead of currentVersion for tracking object versions or timestamps.

For more information, see the updated reference documentation:

• https://developer.atlassian.com/platform/forge/custom-ui-bridge/objectStore/

• https://developer.atlassian.com/platform/forge/storage-reference/object-store-api/

The devops:securityInfoProvider module has moved from preview to general availability. Your Forge app can now send security information (such as vulnerabilities and security containers) to Jira and surface it in the development panel of Jira Software issues.

Known limitation: Currently, Forge apps using the devops:securityInfoProvider module require a Connect key. This means apps using this module cannot be listed as new apps on the Atlassian Marketplace - only existing Connect-based security provider apps migrating to Forge are unaffected by this restriction.

We're actively tracking this limitation in https://jira.atlassian.com/browse/ECO-1602 and will update this page when it's resolved.

Get started

See the https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-software-security-info/ for the full manifest schema and property details.

For a step-by-step guide, check out the https://developer.atlassian.com/platform/forge/security/.

Forge LLMs are now generally available (GA), allowing you to build secure, Atlassian-hosted AI features into your apps. This release includes support for the latest Claude models and an updated deprecation policy to reflect the fast-moving AI landscape.

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.

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:

For 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

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

2. Declare your migration intent - this determines which cohort your app falls into and when messaging appears.

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

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

• Sign up for the EAP here.

• 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

1. 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/).

2. Declare your migration intent as this determines which cohort your app falls into and when messaging appears.

3. Provide a migration URL. This URL will be surfaced directly in customer-facing notices, replacing the default Atlassian messaging with your app-specific guidance.

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

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.