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.
You can now migrate a Connect Jira Issue Field module to Forge's custom field module. The functionality is now available for String, Number and Read-only fields.
See https://developer.atlassian.com/platform/adopting-forge-from-connect/migrate-jira-issue-fields/ for more details.
Forge embedded macros are now available through Forge’s Early Access Program. To join the EAP, please complete this sign-up form.
Forge bodied macro apps can now render embedded Forge macro apps through the AdfRenderer component (UI Kit) and the view.createAdfRendererIframeProps method from @forge/bridge (Custom UI).
For more information, see the updated documentation for Forge rich-text bodied macros.
A new RFC is ready for review at: https://community.developer.atlassian.com/t/rfc-125-ui-modification-for-forge-custom-fields/98439
A new RFC is ready for review at: https://community.developer.atlassian.com/t/rfc-124-evolving-the-marketplace-trust-program/98418
Jira global background scripts are now available in Preview. This feature enables you to add an invisible container that coordinates data and behavior across all pages in Jira, enabling advanced integrations and automations.
We’re releasing this feature in preview to gather feedback and help you prepare for upcoming changes. You can use global background scripts in production environments during the preview period.
For more information, see Jira global background scripts (Preview)
As announced in July 2025, a number of glyphs for the Icon component will now be removed.
A new RFC is ready for review at: https://community.developer.atlassian.com/t/rfc-123-csm-extensibility-on-forge/98412
The avi:jira:created:issue event now includes an clonedFrom field if the issue was created through the “Clone” operation. This field contains the ID and key of the original issue.
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.
Rate this page: