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.
The rovo:mcp module has progressed from the Early Access Program (EAP) to Preview. This module enables Forge apps to expose https://developer.atlassian.com/platform/forge/manifest-reference/modules/rovo-action/ as tools that you can add to custom agents in Rovo Studio.
What's changing
Apps using the rovo:mcp module can now appear under Connected Apps in Rovo Studio. This allows makes configured actions available as tools for custom agents, enabling them to interact with external data and services.
What you need to do
If you were already using the module during the EAP, no changes are required.
To get started, add the rovo:mcp module to your Forge app manifest and configure the actions you want to expose.
Review the updated documentation for implementation details:
The installations page in the developer console has been redesigned to scale with large app install bases and to give you more control over how you view your data.
Key improvements include:
Performance at scale — the page loads quickly even with large install bases.
Configurable columns — hide, resize and reorder columns, and pin your most important column to suit your workflow. Your preferences are saved locally.
Improved search and page navigation — find specific installations faster with a more responsive search and cleaner pagination.
This feature is currently in Early Access. To participate, sign up for the EAP.
The Forge bridge invoke method now supports an optional metadata argument. This allows you to receive additional information about an invocation, such as rate limiting details, alongside the response.
What's changing
When you pass a metadata argument into the invoke function, it returns an object containing both a body field (the invocation response) and a metadata field. Any supported field set to true in the metadata argument will be returned within this metadata field.
Currently, rateLimitProperties is the only supported field in the metadata. This allows you to monitor rate limiting information for your invocations to better manage app performance and reliability.
Example usage:
1
2
3
4
5
invoke('getText', { example: 'my-variable' }, { rateLimitProperties: true })
.then(({ body, metadata }) => {
// Log metadata for debugging purposes
console.log(JSON.stringify(metadata));
}What you need to do
If you want to access invocation metadata, update your invoke calls to include the third metadata argument and handle the new response structure ({ body, metadata }).
Existing calls to invoke without the metadata argument remain unchanged and will continue to return the response body directly.
For more details, see the Forge bridge invoke documentation.
What's changing
You can now use a single manifest.yml file across different deployments while adapting your Forge Container services configuration based, for example, on the environment type (development, staging, or production). This allows you to optimize for cost or performance by overriding settings like memory or CPU for specific environments.
What you need to do
To start using environment-specific configurations, update your manifest.yml using the new overrides syntax. For detailed implementation steps and examples, refer to the Forge Containers manifest overrides reference.
Static Content Macros for Confluence on Forge are now available in Forge’s Early Access Program (EAP).
Render your Confluence macros as static content instead of iframes, reducing app invocations. To enable static rendering, sign up for the EAP and add the static property to your macro module in manifest.yml, specifying either a function or endpoint (for Forge Remote).
The Forge Developer Console now provides visibility into build tags for your deployments. This update allows you to:
Identify if a specific tagged build was used for a deployment.
See if the most recent deployment to an environment used a tagged build.
To view the build tag for a specific deployment:
Navigate to the Deployments tab in the Developer Console.
Select the menu button and click more info under the actions column for the desired deployment.
To view the most recent tagged build for an environment:
Navigate to the Environments tab in the Developer Console.
Click on the date shown under the Last deployment column.
We are extending the Connect End of Support (EOS) date from December 2026 to January 31, 2027. This extension is intended to give partners and developers additional runway to complete their migrations without overlapping with end-of-year activities and annual planning cycles.
For more information, please read https://www.atlassian.com/blog/development/getting-ready-for-connect-end-of-support
We are deprecating the confluence:fullPage(Preview) and jira:fullPage(Preview) modules on Sep 30, 2026. These modules are being replaced by the new global:fullPage(Preview) module, which provides a unified way to create immersive, full-screen experiences for your Forge apps across Atlassian products.
The global:fullPage module is based on the same underlying infrastructure as the product-specific modules, so you can expect a consistent experience with minimal migration effort.
What you need to do
To ensure your apps continue to function correctly, you must migrate to the global:fullPage module before the deprecation date.
Update your app manifest to use the global:fullPage module.
Define the compatibility property in your manifest to specify which Atlassian products your app requires.
Update any internal routing or links to use the new URL format: https://<site-hostname>/apps/full-page/<installation-id>/<route-prefix>/<app-route>.
For detailed migration steps and configuration options, refer to the global:fullPage documentation.
What's changing
The Teamwork Graph API can now be called directly from Forge app frontends (UI Kit and Custom UI) as part of the Teamwork Graph EAP. This is enabled via the new Forge bridge API, requestTeamworkGraph().
Previously, Teamwork Graph queries could only be executed from the Forge backend using @forge/api. This update allows you to fetch unified context across Atlassian products directly from the client side, reducing latency and simplifying app architecture.
What you need to do
Update the @forge/bridge package to the latest version in your app's frontend directory:
1
npm install @forge/bridge@latestEnsure your app has the required permissions in manifest.yml:
For Jira: read:graph:jira
For Confluence: read:graph:confluence
For more details on implementation and available data, see the requestTeamworkGraph documentation and the Teamwork Graph API guide.
To participate in this release, you must be enrolled in the Teamwork Graph EAP.
The Forge platform will be undergoing maintenance in Commercial production on August 5, 2026 between 4am - 7am UTC.
There should be a few minutes of downtime within this window. During this time, the following capabilities will not be intermittently available:
Creating, updating, or deleting apps
Deploying apps
Installing, uninstalling, upgrading apps
App invocations will continue to work for existing users of the apps. However, new customers may be unable to use apps as consent process will be impacted during this interval as well.
You can now package Forge functions and UI Kit modules manually through Forge’s Early Access Program (“EAP”). This allows you to bypass the fixed version of Webpack bundled within the Forge CLI and upload your code directly from specified directories without modification.
What's changing
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
Sign up for the EAP using the registration form.
Over the coming weeks, if your Marketplace app is still running on Atlassian Connect, you can expect to receive a direct ECOHELP ticket from us.
Why we're doing this: Jan 31, 2027 marks end-of-support for Connect. We want to make sure every vendor has had a direct, personal heads-up with enough runway to complete their migration.
Who will receive a ticket:
• Group 1 — Connect apps (no Forge manifest at all)
• Group 2 — Forge apps with remaining Connect modules
What we'll ask:
Leave a comment and fill in the short survey at the top of the ticket
Complete your migration before Jan 31, 2027
The description also covers what to do if you're already migrated, in progress, or planning to discontinue — plus links to the migration guide and developer community.
Forge Custom UI: Browser Storage Access support
Forge Custom UI apps can now opt in to the Storage Access API by declaring in their manifest.yml.
1
2
3
permissions:
sandbox:
- "allow-storage-access-by-user-activation"When enabled, the app's iframe will include the allow-storage-access-by-user-activation sandbox attribute, allowing the app to request access to unpartitioned cookies via the Storage Access API (document.requestStorageAccess()) after a user gesture. This is useful for apps that need access to browser storage in contexts where third-party storage is blocked by default.
Requirements:
• App must opt in explicitly via the new allowStorageAccessByUserActivation permission
Forge Container services are now available in Developer Preview. You can package your Forge app's backend as a container image to support long-running, resource-intensive workloads directly on Atlassian's hosted app platform.
Container services let you bring your own runtime and dependencies while keeping Forge's security and deployment model. They're eligible for the Runs on Atlassian program, including support for data residency.
What's new
You can define a container service in your app's manifest.yml and deploy it alongside your existing Forge functions using the Forge CLI.
Container services support any language or runtime that can be packaged as a container image, provided the image complies with the image security guidelines.
Services are deployed across multiple Atlassian regions to support performance and data residency, with instances provisioned only in regions where your app is installed.
Get started
Usage of Container services is metered and billed. Container services use a reservation-based model. See Forge platform pricing for details, and review the available cost optimisation techniques to manage your running costs.
The Forge shared responsibility model has been updated to reflect the responsibilities that apply to apps using Container services. Review it before deploying to production.
See the Forge Container services reference for the full manifest schema, supported resource limits, regional behaviour, and image requirements.
Support for Claude Opus 5 model is now available in Forge LLMs. For the exhaustive list of supported models, refer to our documentation here
Rate this page: