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.
My take away from this is that I won’t be porting the free version of my app to Forge, I’m just going to remove it from the marketplace. It isn’t just the risk of accruing cost but the additional overhead of even needing to model potential costs.
I assume there will be new pricing models before 2026, right?
As proposed, based on consumption would be nice. But at least I want to set quotas for certain tiers. Especially for < 10 users, which are free in most of our apps.
Hello @AdamMoore,
Thanks for posting information about the new pricing model. Unfortunately, we as TNG app vendors see several problems with this pricing model.
As already mentioned by others, we can only charge app-users seat-based, but we will get charged consumption-based across all environments per app. This is very risky for us as app-vendors:
If we have a few customers/licenses being the ones responsible for large usage, we as app-vendors do not have any means to influence that. Instead, all we can do is increase the pricing of our apps for the next month - so that ALL our customers will have to pay more. Is this an acceptable model for the customers, that they pay for the app-usage of other customers with higher consumption? Just to remember, one of Atlassian core values is: Don’t #@!% the customer.
On the other hand, looking at potential abuse, there could be customers/licenses who want to financially harm us as app-vendors: They could just create a site with a free user and an automatic job with lots of usage. We as vendors are incapable of stopping them. This is a big financial threat which is implemented fairly easily.
In order to mitigate these issues, we would need to be able to at least set quotas for the user tiers. Ideally usage larger than a certain amount would be billed to the customer causing the high usage. Eventually, we would welcome a solution:
