Today we’ve published Updates to Forge Pricing: Effective January 2026 as a follow up to our earlier blog A Preview of Future Forge Pricing. This announcement is intended for all developers of Forge apps, including partners and customers with custom apps. It provides additional details on the Forge pricing changes which will take effect on the 1st of January 2026.
In particular, I would point you to the new cost dashboard which can be found by navigating to Usage and costs in the Developer Console. The dashboard shows both month-to-date usage of Forge resources and forecasted costs for the ongoing month.
If your app isn’t on Forge yet, you can use our new cost estimator to get an understanding of your future costs.
We have released these features in advance to give you more clarity around what your Forge costs will be once pricing takes effect in 2026.
We’re also keen to get your feedback so we can refine and improve things over the coming months. Please drop a comment or ask any questions below.
Thanks for sharing—it’s great to have a clearer picture of the estimated costs.
At the moment, we’re focusing on reducing the load (and associated costs) of the “Functions - compute” capability.
I wanted to ask if you know of any additional tools or resources that could support a more detailed analysis?
Also, I’d appreciate your input on a few assumptions we’re working with:
Am I right in thinking that the number of invocations and function run time aren’t necessarily the most relevant optimization metrics?
Is it correct that memory usage (and potentially CPU allocation) are the more impactful factors in terms of performance and cost?
Are there any best practices or optimization strategies you’d recommend for minimizing memory or CPU consumption—or any patterns to watch out for?
Lastly, having cost insights at the function level would be incredibly helpful in identifying and focusing on the most resource-intensive parts of our codebase. If there’s any way to get that level of granularity, I’d love to hear about it.
Just wanted to check whether you had explored the Forge Backporting capability? This would enable you to release a new minor version update for the previous major version. In this, you could introduce limits or add increased CTAs regarding a need to upgrade the app.
And as soon as you’ve done that there is absolutely nothing developers can do to push customers onto the latest version. Atlassian offers no solution whatsoever nor are any notifications sent to admins to encourage them to update the app.
I’ve had multiple private discussions with internals over the past two years on this matter and still waiting on some tangible action.
Yeah you could but you’d be breaking the app. Pissing off a customer with a broken app and then asking them to pay surely can’t be a good conversion strategy.
And even if you wanted to do non-breaking backporting changes you would need to have a release record carefully tagged in git for every single deployment. And do so for every major version.
Every potential solution I’ve heard Atlassian staff suggest will be a nightmare of code complexity and won’t solve the existing problem of the vast majority of customers sitting on outdated versions.
Ultimately I think the only way Atlassian can solve this mess is to do opt-out updates. eg give admins 6 months warning (emails + notifications) to either manually update to the latest version or uninstall. If they take no action the app should be auto-updated to the latest version.
And if the auto-update involves free-to-paid change and the admin misses the 6 months of notifications, then there’s always the existing refund policy which perhaps could be extended for this particular scenario.
Hi Boris,
I assume you came up with 37.5 real users based on the 100,000 GB-seconds free tier? If yes, assuming you double your users you’re bill is 100000*0.000024 (~$2.4), right? Not trivializing your use case, I am mostly trying to understand the pricing myself.
Correct. If I have to pay for a free app, the incentives become that I should build it as an oAuth app outside of Forge where a $5 a month VPS can support thousands of customers.
I have been following the developments of the forge platform for a while now and was coming up with some ideas for free apps I would have liked to develop. It was looking to me like forge was going to be the most promising approach, but with this change I think I’m now going to have to go with oauth or connect instead. I’m not willing to pay just to be able to throw my idea out there and share a free app with other people. Made an account just to say this. Very disappointing!
This may have been asked before, but with Forge transitioning to consumption-based pricing, are there any plans to increase—or even remove—some of the current API limitations, such as the 100-value limit on KVS queries? I can understand the need for limits when Forge was still in beta and free but if we’re moving to consumption-based pricing then I don’t see why these limits should still be in place if we’re gonna be paying for it.
Hello @rcsr, we are actively revamping the quotas and limits to increase where feasible and eliminate redundant ones. With the transition to consumption based pricing, we plan to keep limits in place largely to avoid performance hits or if there are underlying technical limitations.
While I don’t have an update on your specific limit, we’ll have more details to share on this next month.
