Accessing Forge Storage externally and the future of Forge Storage


I’d like to know if there’s any way to access the Forge Storage from outside, for example from an AWS Lambda.
I’ve tried the Web Trigger functionality, but the url where the trigger can be called is generated, and can only be generated from within Forge.
We need to know where to access the Storage when a scheduled job starts outside of Forge, therefore we’d have to store this url somewhere else. Using another storage to store the location of the actual storage kinda defeats the purpose of using this system at all… Not to speak about the severe quota limitations.

My question is:

  • Is there any other way to access the Storage API externally?
  • What are the plans with Forge Storage going forward, can we expect better functionality than a plain key-value store? The current implementation seems more like a proof-of-concept or a tech-demo, than a solution for real-world scenarios.

We ask ourselves the same question. Currently the Storage API doesn’t cover basic query functionalities. When we asked Johnny Ferguson (Head of Product Management, Ecosystem Platform) about it in the last Forge webinar he said: “RDBS [Relational Database System] is something we think we will probably have to support in a remote fashion for quite a while.”

That is why we now start implementing Forge apps with a remote backend on Firestore. Not ideal. But staying on Connect feels bad too. Maybe we can migrate our persistence layer back to Atlassian Cloud when Storage API or sth. else covers the requirements of data queries.


Here is @Johnny answering @JulianWolf’s question: Forge Roadmap Webinar: Q4 2021 - YouTube

Your workaround is exactly where I would have headed.

The Forge team knows that there are a lot of opportunities to add to the Storage API and have it on their roadmap as a future item: Trello


Echoing @MateKavaleczMidori 's question — having a way to store app properties (equivalent to the connect API) that are accessible externally would be super useful!

The only workarounds currently seem to be storing a web trigger URL somewhere externally, or to add properties to another entity (projects, issues, users — an approach I imagine could cause complexity if a new user or project is created, etc). I can’t see any mention of this in the roadmap, is this something that’s being considered?

The only properties I see on the Forge public roadmap for developers is @JakubMierzewski’s
jiraProperties Forge Module but, it doesn’t have any details on the card… :frowning:

Also quite a few FRGE issues with properties in them: Forge - Issues - Ecosystem Jira

Let me go bug @JakubMierzewski and see if there is something similar in the works.


[Forge Jira entityProperty module EAP - #2](https://jiraProperties Forge Module) is released, I just have updated a public roadmap. @JimmyLoughran is it solve your use case?

1 Like

Hey there — it is awesome to see indexable entity properties.

In my particular use case I’d like to store (and read) properties against the “app” entity, which is possible in Connect.

The current solution in Forge appears to be the storage API, that can be exposed / accessed via a web trigger.

Are there any plans to include app entity properties in Forge, that are accessible directly via an API?