Announcing Forge Platform Limit and Quota Increase

[SushantBista]

Hi everyone,

We are excited to share that we have increased Forge storage quotas and API limits. Increasing these limits has been widely requested by developers and partners, and this improvement will expand the use cases that can be built on Forge - helping you build more robust, more complex apps.

As of this week, the following changes have been made:

NEW total storage capacity quotas

• We have doubled the storage capacity
• We have increased the limit for secret storage API (encrypted storage to store sensitive credentials)

NEW weekly storage transfer capacity quotas

• We have doubled the read and write capacity

NEW storage API limits

• Key length limit has been increased from 100 to 500
• Value size has increased from 32 KB to 128 KB

NEW operations per second (per installation) limits

• We have increased the update operations (write) limit from 10 RPS to 20 RPS (all other storage operations per second limits remain the same)

Read more about platform quotas and limit updates in the docs.

Invocation runtime limit

In case you might’ve missed the announcement in November, we have also extended Forge runtime to 25 seconds for all modules.

Apps that exceed quotas or limits

As Forge adoption increases, we’re closely observing usage data to determine appropriate limits and optimize platform performance.

We understand that not all quotas are easy for you to monitor yourself at the moment, and we are working on improved monitoring tools for future release.

If you believe your app needs higher storage capacity, please contact us via the Developer Service Desk. If you believe your app may need an increase of other quotas or limits, please provide your feedback via Forge Jira Project to help us understand your use case.

Read more about apps exceeding quotas or limits here.

Your feedback matters

As we continue to explore additional enhancements, we would love to hear your feedback in the poll/comments below.

We want to hear about your app storage requirements and usage. Help us understand if this release has addressed your Forge storage related issues so we can prioritise the enhancements that matter the most to you.

Thank you!

Does this enhancement unblock your app to use Forge hosted storage?

• No, I have unresolved issues relating to platform limits
• No, I have other storage blockers
• Yes, but I have other blockers not related to storage
• Yes, I can use Forge hosted storage!

[MatthiasClasen]

Thanks for the update and the improvements! If we now get a more sophisticated storage API, we can build our Cloud apps solely within Atlassian Cloud: [FRGE-377] - Ecosystem Jira

[SushantBista]

@MatthiasClasen thanks a lot for your feedback!

We are exploring some of the requests on that (awesome) ticket (e.g. query by value), while other items are planned for future explorations. We are increasing our focus on storage API improvements.

We would love to get more details on what storage related restrictions are specifically blocking you. If suitable, I will reach out directly to understand more.

[MatthiasClasen]

Currently, restrictions on transactions, queries and sorting prevent us from using the storage API in our Forge apps.

[clouless]

Kudos to raising the limits

The only thing missing would be a “query by value” thing, where we could also do reverse-lookups on json values. Or some other advanced form of query mechanism. The “startsWith” thing is useful, but we have to code a lot of workarounds to have our lookups work fast.

thanks a lot for all the improvements on forge Feels great to write apps with this framework

[SushantBista]

@MatthiasClasen thank you for the details. This is very helpful!

[SushantBista]

@clouless thanks a lot for your feedback and support!! This is very helpful as we are exploring ‘query by value’ functionality.

[nathanwaters]

The key-value storage limit should be something like 25MB. That’s what Cloudflare Workers KV offers: KV · Cloudflare Workers docs

You wouldn’t believe the amount of time I’ve wasted coding and testing helper functions to save/retrieve 32KB data chunks across multiple entity properties (Connect) and storage (Forge).

Increasing the limit to 128KB doesn’t make much difference. Developers will still need to go through that painful hack for certain types of applications.

Try build something like a survey app where you need to save/retrieve potentially hundreds of responses. You’ll quickly hit the 128KB key-value limit and thus need to split the data across multiple KVs.

An alternative I’d suggest to the Forge team is to build a looper function into the API so developers don’t need to worry about the KV limit, only the overall storage limit. ie they could just call storage.set() or storage.get() on megabytes of data and the API would manage splitting/retrieving it server-side.

eg this is how my keys end up looking:

• ${app}:responses:${macroId}:0
• ${app}:responses:${macroId}:1
• ${app}:responses:${macroId}:2

But I need to take the large data array, split it into max 128KB chunks, and save each KV. Then if data has been removed I either need to delete all the KVs and start fresh or overwrite each KV and then delete any remaining.

Then when I retrieve these KVs I need to loop through each one and stop when it hits an empty or undefined key.

You can see how it’s not fun to build for the first time.

If you guys dogfooded your dev platforms (Connect or Forge) you’d have picked up on this a long time ago. Hell, you make it so unnecessarily hard to keep data within the customer’s instance that for many of my Connect apps I resorted to saving compressed JSON data inside Confluence content attachments. As a result most developers on Connect simply resort to storing data in external databases, which is obviously a security issue. I can see the same situation playing out on Forge.

[SushantBista]

@nathanwaters Thank you for your great feedback! This is very helpful in better understanding your blockers and issues. Our team is assessing your suggestions and we will provide an update soon.