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.
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.
What’s changing
The new rovo:skill module allows you to package reusable, task-specific instructions and supporting reference files within your Forge app. You can add these skills to Forge Rovo agents through the app manifest.
Key features include:
Tool orchestration: Skills can declare Forge action modules as tool dependencies, allowing them to coordinate multiple actions into a complete workflow.
Rovo Studio integration: Forge Rovo skills will also be available to custom agents in Rovo Studio. This capability will roll out progressively over the week following this announcement.
Dynamic selection: At runtime, an agent selects a skill based on its description and the user’s request.
During the EAP, the following limitations apply:
Apps that declare rovo:skill can only be deployed to development environments.
Skill-to-skill dependencies are not supported.
Executable skill sources, including scripts, are not supported.
A skill directory must not exceed 100 MB uncompressed.
Tool dependencies must be action modules declared by the same app.
What you need to do
Sign up for the Forge Rovo skills EAP.
Review the rovo:skill module reference to learn how to define skills in your manifest.
For guidance on choosing between prompts, skills, and actions, see the rovo:agent module reference.
As per our previous announcement, admin-facing Connect end-of-support (EOS) migration messaging on the Connected Apps page is now gradually rolling out to production instances for apps that have declared a migration intent of ‘yes’.
Apps that have declared connectToForgeMigration with a migration intent of "yes"
The following app categories have already been rolled out to receive admin-facing messaging as per our previous changelog:
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)
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.
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. 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.
In https://developer.atlassian.com/changelog/#CHANGE-3253, we announced that Forge custom fields (FCF) of type object can now render a rich custom edit experience in Jira's bulk edit. At that time, issue and project details were not available in the extension context during issue-bulk-edit, and we recommended using renderContext === 'issue-bulk-edit' to detect this case and render a fallback UI.
This limitation has now been removed. Issue and project context is now available in your app's extension context during bulk edit. You can use this context to make more informed decisions about the UI or the options you display.
If you previously added a fallback UI for the issue-bulk-edit render context, you can now update your app to use the available issue and project context instead.
Review the updated https://developer.atlassian.com/platform/forge/manifest-reference/modules/jira-custom-field/#extension-data:~:text=module%20is%20rendered.-,issues,-issue%5B%5D for details on the context shape.
No action is required if your edit experience does not depend on issue or project context.
Forge Frontend logging is now available in Early Access Program (EAP). This feature is supported for both UI Kit and Custom UI across all environments, including production. It captures console.error, uncaught exceptions, and unhandled promise rejections.
What's changing
Direct frontend observability: You can now view platform logs, custom log errors, and exceptions from your app's frontend directly in the Forge Developer Console and CLI.
Log export support: Frontend logs are accessible via the Export app logs API and Point to Point Logs Export.
Customer-controlled logging: Frontend logs are accessible when customers have provided consent to share app logs in admin.atlassian.com.
No billing during EAP: Frontend logs generated during the EAP period will not be charged.
What you need to do
Sign up for the EAP: Submit a request via the EAP form to enable this capability for your apps.
What's changing
We fixed an issue where the ttl returned for Forge Remote offline user impersonation tokens could incorrectly report 30 minutes, even though the token remained valid for up to four hours.
The returned ttl now accurately reflects the token’s remaining validity. This change only affects the reported value and does not alter the actual token lifetime.
What you need to do
If your app uses a fixed 30-minute token-refresh workaround, update it to use the returned ttl value from the offlineUserAuthToken mutation. This allows your app to cache it longer and refreshes tokens less often than previously.
We are removing support for anonymous (unauthenticated) users from the Forge Feature Flags Client SDK (FeatureFlags in @forge/bridge). Starting December 1, 2026, the Client SDK will no longer evaluate feature flags when no authenticated user is present.
Currently, the Client SDK can be initialized even without a logged-in user (i.e., when no accountId is available). After this change, FeatureFlags.initialize() will only function for authenticated users with a valid Atlassian account. If your app calls initialize() without an accountId in the user's identifiers, the SDK will not return evaluated flag values and will fallback to default values.
You are affected if your Forge app meets both of these conditions:
Uses the Feature Flags Client SDK (FeatureFlags from @forge/bridge)
Allows anonymous access (e.g., your app module has unlicensedAccess enabled and you serve users who are not logged in)
If your app only serves logged-in users, no action is needed.
Option A — Use a default value for anonymous users
Before calling initialize(), check whether an accountId is available. If not, skip initialization and use a hardcoded default for your feature flag logic:
1
2
3
4
5
6
7
8
9
const { accountId } = await view.getContext();
if (accountId) {
const featureFlags = new FeatureFlags();
await featureFlags.initialize(user, config);
const enabled = featureFlags.checkFlag("my-flag", false);
} else {
// Anonymous user — use default behaviour
const enabled = false;
}Option B — Move flag logic to the server-side SDK
If you need to control behaviour for anonymous users, use the https://developer.atlassian.com/platform/forge/feature-flags/feature-flags-sdk/ in a resolver. The server SDK supports targeting by installContext (site-level), which does not require a user identity.
Deprecation notice issued | Sep 2, 2026 |
End of support (breaking change) | Dec 1, 2026 |
The deprecation period is 90 days. During this time, the existing behaviour will continue to work, but you will see deprecation warnings in the developer console.
We’re updating the invocation rate limits for Forge apps to support larger-scale apps and platform stability.
What’s changing
The invocation rate limits for user-led invocations (UI and web triggers) are being updated to the following values:
Per app installation: The limit is changing from 5,000 requests per minute (RPM) to 300 requests per second (RPS) or 7,000 RPM (whichever is hit first).
Per environment: The previous global limit of 30,000 RPM is being removed to provide more flexibility for apps with large numbers of installations.
Per user: The limit remains unchanged at 1,200 RPM.
What you need to do
If your app frequently performs high-burst activities, you may need to implement retry logic or optimize your function calls to stay within the 300 RPS threshold.
Retry logic can be implemented using:
The rateLimitProperties field returned from Forge bridge invoke
Web trigger rate limiting response headers
For implementation examples and more details, see the Forge invocation limits documentation.
You can now manage web trigger URLs programmatically from within your Forge Container Services environment. These new REST API endpoints provide parity with the @forge/api package and the Forge CLI, allowing your container-based apps to create, list, and delete web trigger URLs.
What's changing
We’ve added the following HTTP endpoints to the Forge Container Services REST API:
POST /forge/webtrigger/url: Create a new web trigger URL or retrieve an existing one.
GET /forge/webtrigger/urls: Retrieve all web trigger URLs associated with the app.
DELETE /forge/webtrigger/url: Delete a specific web trigger URL.
These endpoints enable containerized apps to handle their own web trigger lifecycle dynamically without relying on external CLI commands.
What you need to do
If your container-based app requires dynamic web trigger management, you can start using these endpoints immediately. Refer to the Forge Container Services REST API documentation for detailed request and response schemas.
Rate this page: