Forge remote is now available in preview!

Hi everyone,

I’m pleased to announce that Forge remote is now available in preview :smiley:

Check out the docs here and leave any questions or comments below.



Sounds great for complexer apps. But are we now not completely back on the “connect” concept?

I like forge a lot because of the serverless principle and that all data stays within the Atlassian Ecosystem.

I really would rather have better storage APIs with better query possibilities than more remote features :slight_smile: But I guess a lot of Marketplace Partners with complex apps will appreciate this :rocket:

Will there be a distinction between forge and “forge remote” apps on the Marketplace? Will forge remote apps be cloud fortified?
What about SLI/SLAs for forge remote and cloud fortified?

That said, I would really love to have a “higher trusted” badge for “classic forge” apps where the data stays within the Atlassian Ecosystem. :slight_smile:

I’m assuming that all requests are now proxied through the Forge infrastructure (instead of just going straight to us with a jwt token applied on the front end). Am I correct?

I was wondering if there as any documentation about where this Forge infrastructure is hosted? Is it pinned to the end users Data Realms or can we chose where it is pinned (if we don’t want to be in the UK for example)?

What type of logging is done from the Atlassian side?

Does Atlassian view the request going through this proxy is a service for the end user (ie Atlassian’s customer according to gdpr) or is a service to the vendor (ie sub-processor relationship). I’m thinking it’s the later since the vendor is chosing to make use of this - but it would be great to understand what agreement “owns” this proxy.

Can you talk about performance? What type of delay is viewed as “acceptable” by Atlassian when we use this instead of Connect for front end modules?



1 Like

Hi @AdamMoore It’s a great addition to Forge, especially in cases where Forge Storage falls short.

However, is there any reason why 25 seconds runtime/execution limit is still there? I mean it’s not FaaS anymore, so why keep this execution limit?

If you remove the limit, this would be an instant hit :fire:

Update: Actually, I missed this part in the docs :point_right: which has a workaround for requests that take longer than 25s.

At the moment, all Forge invocations are executed in us-west-2 US West (Oregon) and that will be the case for remote invocations as well. We are working on multi-region compute for the Forge platform.

1 Like

Thanks @rlander, and yes @danielwester for now all invocations go via us-west-2.

But, in preparation for Forge data residency we are making all services involved in invocations multi region (in all the regions Atlassian supports) and then we’ll be able to offer multi region invocations for Forge remote. You’ll be able to add multiple base urls for the regions you want to support in the Forge manifest. We’re planning to tackle this in the first quarter next year.

I’ll come back to you on the data controller question.


@chhantyal the 25 second limit is something we could possibly increase. What would kind of limit would you think is reasonable for a UI invocation?

Hey @clouless, thanks - great questions/comments.

The difference with Forge remote is you’re starting with the secure Forge sandbox and incrementally opting in to the least privilege you need to get a particular job done. This is quite different to Connect which is very open by default. In general the trust posture is still much higher.

And we are still heavily focused on Forge’s hosted compute and storage. The investments we’re making in hosted far outweigh the investments we’re making in remote. Projects like the NodeJS runtime, complex queries and data residency are starting to come through and there will be lots more next year. I do think Forge remote provides a high “bang for buck” though.

With respect to the Marketplace, we don’t have any plans to start branding Forge/Forge Remote/Connect because they don’t really help customers make informed choices. What we are committed to doing is including the right trust signals so that they can make informed choices. The egress permissions on the Forge install screen is one thing, the Privacy and Security tab is another. We’ll continue to evolve and improve those signals.

I think what you’re looking for is possible in future, but it might be more like “runs entirely in the Atlassian cloud” distinction (can you tell I’m not in marketing :smile:) rather than a “Forge” badge specifically.


Hi @AdamMoore, are multi-region remotes still on the roadmap?

Yes, still on the roadmap. Unfortunately I don’t think it will be this quarter though, most likely next quarter

1 Like

Thanks Adam.