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
With Forge CLI 13.4.0 you can now configure the Forge CLI to use a network proxy natively through CLI settings or environment variables. This removes the need for manual workarounds, such as modifying the CLI source code or using the global-agent package.
To save a proxy configuration for all Forge CLI commands, run:
1
forge settings set proxy ${yourProxyServer}Alternatively, you can configure the proxy for your current terminal session by setting the FORGE_PROXY environment variable:
1
export FORGE_PROXY=${yourProxyServer}Update to the latest version of the Forge CLI by running npm install -g @forge/cli.
Configure your proxy using the forge settings command or the FORGE_PROXY environment variable as shown above.
For more information on using Forge in restricted network environments, see Using the Forge CLI on a corporate network.
As per our previous announcement, we will be progressing admin-facing migration messaging for apps that have declared a migration intent of ‘yes’ on the Connected Apps page from the Developer Canary Program to production instances. This rollout will begin in approximately two weeks.
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.
Preview the experience now using the Developer Canary Program. Customer messaging is already live on canary tenants for apps that have declared ‘yes’ to the migration intent. 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.
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.
Following the initial Point-to-Point Logs Export EAP announcement, the feature now includes the following improvements:
What's changing
Environment filtering: You can now filter which environments (production, staging, or development) send logs to your third-party logging tool. This helps you manage costs by, for example, exporting only production logs while using the Forge Developer Console for other environments.
Per-app export URLs: You can now configure unique export URLs for different sets of apps within your developer space. This gives teams with multiple apps the flexibility to route logs to separate destinations.
Google Cloud Logging support: You can now export Forge app logs directly to Google Cloud Logging, in addition to existing support for Datadog, Sumo Logic, Amazon CloudWatch, and Splunk.
What you need to do
If you haven't already, sign up for the EAP.
Review the setup guide to understand how to configure your observability vendor and share the required details in the EAP form.
What's changing
The Forge CLI build and deploy commands now include a new --inspect option. This option copies the Forge application bundle, as packaged for Atlassian infrastructure, into your local .forge/inspect directory.
You can use this to:
Investigate the final structure of your application before it is deployed.
Troubleshoot bundling issues or unexpected behavior in the deployed app.
This new option replaces the undocumented FORGE_INSPECT_ARCHIVE environment variable, which is now deprecated and will no longer function.
What you need to do
To inspect your application bundle, run either of the following commands:
forge build --inspect
forge deploy --inspect
After the command completes, you can find the packaged application files in the .forge/inspect directory within your project.
See the https://developer.atlassian.com/platform/forge/cli-reference/build/ and https://developer.atlassian.com/platform/forge/cli-reference/deploy/ documentation for more information.
Forge CLI 13.3.0 introduced a server-side manifest check as part of the new approval workflow. However, environment variables in the manifest.yml file were not being interpolated before being sent to the validation endpoint. This caused the linter to return false-positive MANIFEST_INVALID_RULE errors for valid manifests.
This issue is fixed in Forge CLI 13.4.0. The CLI now correctly interpolates environment variables before performing the pre-deployment manifest check.
Update your Forge CLI to version 13.4.0 or later by running:
1
npm install -g @forge/cli@latestFor more information on using variables in your manifest, see the manifest variables reference.
To learn more about why these manifest checks and approvals are required, see the documentation on major version upgrades.
You can now use UI modifications in the Jira Service Management (JSM) agent view. This is an extension of the existing jira:uiModifications module and covers the views your agents use inside a service project.
What's changing
UI modifications now support three specific agent views:
Global issue create (GIC) - viewType: GICAgentView
Issue view - viewType: IssueViewAgentView
Issue transition - viewType: IssueTransitionAgentView
The agent view supports the same fields and methods as equivalent Jira views but is tailored for service projects.
Key differences include:
Extension context: Exposes the requestTypeId of the work item.
Supported fields: The set of supported fields differs from the JSM request create portal view.
REST API: The UI modifications REST API (GET, POST, and PUT) now accepts these three agent view types. When configuring agent view contexts, portalId must not be set, and requestTypeId is optional (omitting it means the context is not scoped to a specific request type). One of projectId, issueTypeId, or viewType can act as a wildcard, with a maximum of one wildcard per context.
You can use view.getContext() to detect the current view type:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import { view } from '@forge/bridge';
import { uiModificationsApi } from '@forge/jira-bridge';
uiModificationsApi.onInit(async ({ api }) => {
const context = await view.getContext();
switch (context.extension.viewType) {
case 'GICAgentView':
// Runs when an agent creates a work item in a service project.
break;
case 'IssueViewAgentView':
// Runs when an agent opens a work item in a service project.
break;
case 'IssueTransitionAgentView':
// Runs when an agent transitions a work item in a service project.
break;
default:
break;
}
}, () => []);No action is needed if you don't want to support the agent view. If you do want to add agent view support, simply define the context for the Agent View view types using the REST APIs – your Forge app will then be invoked automatically in the agent-specific views.
For more information, see:
• JSM UI modifications module documentation (to be attached)
• uiModifications API bridge (to be attached)
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.
Rate this page: