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.
Following its initial Preview release, Forge Realtime does not require the read:app-global-channel:realtime scope to use global channels.
Impact: No behaviour change for apps already deployed or installed with this scope.
Action required: Remove the read:app-global-channel:realtime scope from your app manifest before your next deployment.
The legacy icon entry points in @atlaskit/icon have been permanently removed following the deprecation notice published in 2024. The removed entry points are: @atlaskit/icon/glyph/, @atlaskit/icon/core/migration/, @atlaskit/icon/utility/, @atlaskit/icon/base, @atlaskit/icon/svg, and @atlaskit/icon/migration-map.
The no-legacy-icons ESLint rule has also been removed from @atlaskit/eslint-plugin-design-system as it is no longer needed.
Apps using Forge Custom UI or Atlassian Connect that import from any of the above entry points must update their imports to use @atlaskit/icon/core/ instead. Migration guidance, codemods, and the full list of icon replacements were published in the original deprecation notice: https://developer.atlassian.com/changelog/#CHANGE-2773
What was removed
@atlaskit/icon/glyph/* — legacy SVG glyph icon components (~400 icons)
@atlaskit/icon/core/migration/* — migration shim components (~200 shims)
@atlaskit/icon/utility/* — 27 utility (12px) icon components
@atlaskit/icon/base and @atlaskit/icon/svg — legacy base components
@atlaskit/icon/migration-map — migration type helpers
no-legacy-icons ESLint rule from @atlaskit/eslint-plugin-design-system
What to use instead:
Import icons directly from @atlaskit/icon/core/*. The full icon replacement map instructions are in the original deprecation notice: https://developer.atlassian.com/changelog/#CHANGE-2773
What you need to do if you are using Forge Custom UI or Atlassian Connect:
Update any imports from the removed entry points to use @atlaskit/icon/core/* and bump @atlaskit/icon to the latest version.
What you need to do if you are using Forge UI Kit or Forge UI Kit 2:
Nothing. Icons in UI Kit are managed by Atlassian and are not affected by this change.
The spacing prop on icon components in @atlaskit/icon and @atlaskit/icon-lab is now deprecated. The prop was introduced to ease migration from the legacy icon system by allowing icons to carry their own padding. Now that the legacy icon migration is complete, whitespace around icons should be controlled by the surrounding layout rather than the icon itself — consistent with how the rest of the Atlassian Design System handles spacing.
The spacing prop will be removed in a future major release. While no immediate action is required and existing usages will continue to work for now, we recommend migrating away from spacing ahead of its removal. To migrate, replace spacing="spacious" or spacing="compact" with a Flex wrapper from @atlaskit/primitives/compiled using explicit padding tokens. A codemod and ESLint rule with IDE quick-fix are available to automate the migration. Full guidance: https://atlassian.design/components/icon/usage
Why is this being deprecated?
Spacing baked into an icon is invisible to parent components, making layout debugging harder.
The rest of the Atlassian Design System uses explicit layout primitives (Flex, tokens) to control spacing — the spacing prop is an outlier.
The internal implementation is incompatible with @atlaskit/css compiled styling patterns.
How to migrate
Before:
1
<AddIcon label="Add" spacing="spacious" />After:
1
2
3
4
5
6
7
8
9
10
11
12
import { cssMap } from '@atlaskit/css';
import { Flex } from '@atlaskit/primitives/compiled';
import { token } from '@atlaskit/tokens';
const iconSpacingStyles = cssMap({
space050: {
paddingBlock: token('space.050'),
paddingInline: token('space.050'),
},
});
<Flex xcss={iconSpacingStyles.space050}>
<AddIcon label="Add" />
</Flex>Migration tooling:
Codemod — run npx @atlaskit/codemod-cli and select icon-spacing-to-flex-primitive
ESLint rule — enable @atlaskit/design-system/no-icon-spacing-prop for IDE quick-fix suggestions
What you need to do if you are using Forge Custom UI or Atlassian Connect:
Migrate usages using the codemod or ESLint rule above. No immediate action needed — at least 6 months notice will be given before removal.
What you need to do if you are using Forge UI Kit or Forge UI Kit 2:
Nothing. The spacing prop is not exposed to Forge UI Kit developers.
The Forge CLI now supports listing developer spaces using a new command, forge developer-spaces list.
This command will display a table of your developer spaces including their IDs and names. It also supports JSON output using the --json option, similar to other list commands in the Forge CLI.
This command is included in the latest version of @forge/cli. Run npm install -g @forge/cli@latest to install this version.
We are still rolling out a small number of critical back-end fixes that help maintain the stability of the upgrade path for large apps. Extending by two weeks gives us the confidence that these changes are fully deployed and verified before we re-enable minor version updates.
We are extending the period during which all updates to Forge apps with over 50,000 users are classified as major version updates. The new end date is Apr 27, 2026.
During this time, you can continue to use the forge version bulk-upgrade command to roll out updates to customer sites.
For detailed information on how to use forge version bulk-upgrade, see https://developer.atlassian.com/platform/forge/cli-reference/version-bulk-upgrade/.
This change continues to have no effect on how apps qualify for the Forge revenue share rate. Your latest deployed app version determines revenue share eligibility.
See the prior announcement here: https://developer.atlassian.com/changelog/#CHANGE-3109
We're updating the behavior of DATETIME values returned by Forge Storage's SQL layer.
Previously, DATETIME values set to midnight (00:00:00) were returned without the time component — for example, 2026-01-15 instead of 2026-01-15 00:00:00. After this change, the time component will always be included.
What's changing
DATETIME values at midnight will now return the full timestamp, including 00:00:00.
Previously, the time component was omitted for midnight values, returning only the date.
This change will be rolled out on October 6, 2026.
This change is not backward-compatible. Apps that parse or compare DATETIME values and rely on the absence of the time component for midnight values may see unexpected results.
What you need to do
Review any code that reads DATETIME values from Forge Storage.
Ensure your app handles DATETIME values with a time component, including 00:00:00.
Test your app before October 6, 2026 to verify compatibility.
For more information, see Forge Storage.
Effective April 4, 2026, Forge usage on up to the first five sandboxes associated
with each production site where your app is installed is now exempt from billing.
Usage resulting from customers testing your app in sandboxes will no longer appear
on your monthly Forge bill.
This change makes it easier for customers to test and validate Forge apps in sandbox
environments without incurring additional charges to you.
What you need to do
No action is required. The billing exemption is applied automatically based on
sandbox association with a production site.
Notes
This policy applies to both Marketplace apps and private apps.
Sandboxes are intended solely for testing and validation. We monitor for anomalous
traffic patterns and may suspend, restrict, or throttle usage if misuse is detected.
If this policy changes in the future, we will communicate at least three months
in advance.
For more information, see our community post
You can now migrate a Connect Jira Issue Field module to Forge's custom field module. The functionality is now available for Single select and Multi select fields.
See https://developer.atlassian.com/platform/adopting-forge-from-connect/migrate-jira-issue-fields/ for more details.
We've published a new guide - https://developer.atlassian.com//platform/forge/working-around-jql-1000-limit/ - to help Forge app developers handle the custom JQL functions returning more than 1,000 values. The guide covers four practical strategies and code examples, along with trade-off comparisons, and guidance on when to use which approach.
Following our deprecation notice on Sep 29, 2025:
Customers can no longer install Connect private apps.
Partners and developers can no longer update existing Jira or Confluence apps using a Connect descriptor on the Atlassian Marketplace.
Existing installations of Connect private apps will remain unaffected for now.
From now on, private apps can only be installed via Forge installation links. See https://developer.atlassian.com/platform/forge/distribute-your-apps/ for instructions on sharing these links to your customers.
This milestone is in line with our timeline for ending support for the Connect platform.
To continue providing updates to users of your Connect app, it must be migrated to Forge. You can start doing this without completely rewriting your app by incrementally adopting Forge from Connect.
We have now added the ability to use the following as dynamic modules, available under Forge’s Early Early Access Program (EAP):
To start testing, sign up for the EAP here.
Forge now supports a preUninstall module, allowing apps to run cleanup logic before uninstallation. Use this to remove stored data, secrets, or other resources when your app is uninstalled. For more details visit https://developer.atlassian.com/platform/forge/events-reference/life-cycle/#life-cycle-events
We’ve updated how license information is exposed for Forge apps so that the license object is only present for paid, production Marketplace apps, matching our documented behavior.
If you’ve followed the currently documented patterns to check license status, you should not see any change. Our changes may impact apps that rely on custom or undocumented ways of inferring license state for free apps (for example, assuming a license object is present for free installations).
Please refer to our updates docs for more information https://developer.atlassian.com/platform/marketplace/listing-forge-apps/#checking-the-license-status
Forge apps can declare displayConditions in the app manifest for the following JSM portal modules and have them evaluated by the host, consistent with how display conditions work for Jira and Confluence Forge modules today:
Portal footer
Portal header
Portal profile panel
Portal request create property panel
Portal request detail
Portal request detail panel
Portal request view action
Portal subheader
Portal user menu action
Since the preview release, we’ve also added support for the serviceDesk and customerRequest context variables in the Jira expressions that back display conditions for these modules.
For further details, including available conditions and context variables, see the documentation
Following the EAP release, Feature flags is now generally available for all Forge apps.
Feature flags let you control feature rollouts and manage deployments safely. This GA release introduces front-end (client-side) feature flags in addition to the previously released server-side flags. You can now manage feature rollouts end-to-end across both your backend and UI.
If you participated in the EAP, no migration is required — your existing feature flags will continue to work.
For implementation details and examples, see the Feature flags documentation.
Rate this page: