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.
Support for Claude Opus 4.5 model is now available in Forge LLMs. This is in addition to the already supported Claude Opus 4 and Claude Opus 4.1 models.
Also note that Claude Opus 4 has been marked as deprecated and support will be removed in February 2026.
Forge LLMs remain in Early Access (EAP). Due to high demand, participation is limited. To request access, join the waitlist here.
For the exhaustive list of supported models, refer to our documentation here
We announced in a previous changelog that we would be changing the Forge user invocation rate limits from 1,200 requests per minute (RPM) to 20 requests per second (RPS). In response to customer feedback, we’ve decided not to implement this change. Invocation rate limits will continue to be 1,200 per one-minute fixed window.
These invocation rate limits are applied specifically by the Forge platform, and unrelated to the upcoming Jira/Confluence point-based rate limits. For more information, see https://developer.atlassian.com/platform/forge/limits-invocation/.
This fix will be rolled out on Jan 28, 2026 across all Jira Cloud instances.
We fixed bugs that caused the Issues Match REST API and webhooks to evaluate JQL queries differently than the standard Issue Navigator. JQL expressions using EMPTY or != with issue properties or the "Epic Label" field now return consistent results across all Jira Cloud features.
This fix is not backward-compatible. Integrations that relied on the previous behavior may see different results from the Match API or different events triggering webhooks.
Related tickets: JRACLOUD-96922, JRACLOUD-97120
JQL expression | Previous behavior (Match API/webhooks) | New behavior |
|---|---|---|
| Did not match issues where the field was unset | Matches issues where the field is unset |
| Matched correctly | No change |
| Did not match issues where the field was unset | Matches issues where the field is unset |
| Matched all issues, including those where the field was unset | Only matches issues where the field is set |
| Matched correctly | No change |
| Matched all issues, including those where the field was unset | Only matches issues where the field is set |
This applies to both issue properties (for example, issue.property[key].path) and the "Epic Label" field.
JQL expression | Previous behavior | New behavior |
|---|---|---|
| Returned issues where the property was never set | Only matches issues where the property exists and its value is not |
You may see differences in:
The issues returned by POST /rest/api/3/match when using JQL with EMPTY or != on issue properties or "Epic Label"
The events that trigger webhooks using JQL filters with these operators and fields
Review any JQL used in webhook filters or Match API requests that contains:
EMPTY operators with issue properties or "Epic Label"
!= comparisons with issue properties
Best practices:
Goal | Recommended JQL |
|---|---|
Check if a field is set |
|
Check if a field is not set |
|
Specific scenarios:
To find issues where a property is either not set OR has a different value:
1
issue.property[key].path != "a" OR issue.property[key].path IS EMPTYTo find issues where a property is set AND has a different value:
1
issue.property[key].path != "a" AND issue.property[key].path IS NOT EMPTYTest critical webhook flows and integrations that use the Match API to confirm they behave as expected.
Forge apps can now run for guest and anonymous users in Confluence. This means your apps will work on publicly accessible pages and for users who don't have a full Confluence license.
By default, Forge apps only run for licensed Confluence users. To allow your app to serve guest and anonymous users, add the unlicensedAccess property to your modules in manifest.yml.
Confluence has two types of unlicensed users that Forge apps can serve:
User type | Manifest value | Description |
|---|---|---|
Guest |
| Users with an Atlassian account who have limited access to a single Confluence space. Guests are authenticated but don't consume a paid license. |
Anonymous |
| Users who are not logged in. This includes anyone on the internet viewing public content. |
The following Confluence Forge modules support guest and anonymous access:
Add the unlicensedAccess property to your module in manifest.yml:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
modules:
macro:
- key: my-macro
resource: main
resolver:
function: resolver
title: My Confluence Macro
unlicensedAccess:
- unlicensed # Allow guest users
- anonymous # Allow anonymous users
function:
- key: resolver
handler: index.handler
resources:
- key: main
path: static/hello-world/build
app:
id: ari:cloud:ecosystem::app/your-app-idThe Forge CLI used to display the logs in chronological order, meaning that the first entry printed in the console was the most recent.
The behaviour has now changed and the CLI respects the timestamp value of the log entry to keep a sorted order. This means that the last entry printed in the console is now effectively the most recent.
Forge platform pricing is now in effect for Forge apps. To avoid any service interruptions to your Forge apps that exceed the free usage allowance, please make sure you:
After you’ve completed the developer space setup and assigned your private apps to the space, apps that provided consent to the developer terms during this process will automatically receive usage alert emails when any chargeable resource in the app reaches 50%, 75%, 90%, or 100% of the free usage allowance.
On Dec 17, 2025, a bug fix rolled out that started counting compute used by async functions (e.g. event‑driven long‑running tasks) and scheduled triggers. This caused a noticeable spike in reported compute usage for some apps.
To avoid an unexpected cost increase ahead of Forge pricing effective Jan 1, 2026, we’re temporarily reverting this change and delaying charging for async compute.
What this means:
Async and scheduled functions will not be charged from Jan 1, 2026.
Early in the new year, we will share an updated timeline for the implementation of async compute charging.
When we re‑enable async tracking and charging, we will provide clear advance notice.
To avoid a last‑minute cost increase ahead of Forge monetisation on Jan 1, 2026, we are:
Reverting the async usage tracking change for now
Async compute and scheduled trigger executions will no longer be included in chargeable compute usage.
This takes effect from Dec 23, 2025.
Delaying charging for async compute
We will not charge for async compute usage (including scheduled triggers) from Jan 1, 2026.
When we re‑enable async tracking and charging, we will provide clear advance notice.
Keeping December usage data as reference only
Usage recorded between Dec 17, 2025 - Dec 23, 2025 reflects a more accurate view of your async compute consumption.
This data can be used for analysis and optimisation, for example to:
Estimate the impact of async compute on your total consumption.
Identify opportunities to optimise background processing before charging resumes.
You can now deploy Forge app builds directly via the developer console.
Selecting Deploy build from the actions menu next for the build you want to deploy.
Select the environment to which you’re deploying the build to.
Note, app build deployment permissions adhere to the existing permission structure for app contributors.
We have fixed an issue in how compute usage was calculated for async events and scheduled triggers in Forge apps.
This change was rolled out progressively between Dec 17, 2025 and Dec 19, 2025. As a result, affected apps may now report higher compute usage than before. This reflects more accurate tracking of the resources consumed; there is no change to the actual behavior or performance of your apps.
If you have alerts, monitoring, or internal reports based on Forge usage metrics, you may want to review them to account for this correction.
Logs automatically generated by the Forge platform during remote invocations (not logs generated by the app itself) are removed. The following platform-generated log statements are impacted:
Making remote request: When remote invocation is triggered
Successful remote request: When remote invocation was successful
Failed remote request: When remote invocation fails
These logs will no longer be visible on the logs page in the developer console or in the logs CLI command. As a result, they are excluded from usage calculations and billing.
Developers utilising Forge remote will notice a reduction in their logs usage starting today.
To maintain visibility into remote invocations, we will be introducing success and failure information via metrics in the near future.
You can now use UI modifications with Jira Service Management (JSM) request create portal view. This is an extension of the existing jira:uiModifications module, allowing you to change the look and behaviour of JSM request create portal view. The module is designed to be used in conjunction with the UI modifications (apps) REST API.
For more information, see the JSM UI modifications module documentation.
Support for response streaming is now available in Forge LLMs. The new stream function in the @forge/llm SDK allows apps to process outputs as they are generated rather than waiting for the complete response.
Forge LLMs remain in Early Access (EAP). Due to high demand, participation is limited. To request access, join the waitlist here.
For implementation details, refer to the documentation here.
As part of the Forge platform pricing effective from Jan 1, 2026, we have introduced usage alerts. Developers will automatically receive notifications when the usage of any billable capability in the Forge app reaches key thresholds— at 50%, 75%, 90%, and 100% of free monthly usage allowance.
Alert emails are sent for apps in developer spaces that completed consent in the console for existing apps and the CLI for new forge apps.
The following UI Kit components are now generally available:
Comment, which displays discussions and user feedback.
Pressable, which is a primitive for building custom buttons.
CommentEditor, provides a contained comment editor UI with a simple toolbar.
ChromelessEditor, provides a simple text editor that does not have a toolbar.
For more information, see the component documentation.
To access these components, you will need to update your app to the latest version of @forge/react. In the terminal of your project directory, run:
npm install --save @forge/react@latest
Currently, the new workflow editor is the default editing experience in Jira and is being used by the majority of customers.
Starting 26th June 2026, we will begin removing the old workflow editor for customers, which means workflows will only be editable in the new workflow editor. We ask you to please help your customers in this transition by ensuring that any workflow-related apps will work effectively with the new workflow editor.
If you encounter any issues with how your apps behave in the new workflow editor, please raise a support ticket.
Some features to be aware of to improve app experiences in the new editor:
Dynamic configuration descriptions (Forge/Connect)
Make sure to provide a unique description for configured rules.
Additional context (Forge/Connect)
Determine whether the rule is loaded in the new or old workflow editor.
Default workflow editor for user (API)
Determine whether a user has a preference set for the new or old editor.
Deep linking to statuses and transitions
Link to the new workflow editor and provide an ID with either the selectedStatus or selectedTransition query params to pre-select a status or transition.
Rate this page: