Forge Remote: Connecting Atlassian Forge to Your Own Infrastructure
The Limits of the Purely Serverless World
Atlassian Forge has fundamentally changed how apps are built for Jira and Confluence: no need to host your own infrastructure, built-in security, and native data protection. But what happens when Atlassian’s pure serverless infrastructure reaches its limits? Enterprise applications such as existing on-premise databases, long-running compute processes, or complex backend logic in Java, C#, or Python can’t always be squeezed into a Node.js Lambda function.
A core question arises: do teams essentially have to rebuild their entire company architecture in Forge runtimes just to move to the Atlassian Cloud?
The answer: no. That’s what Forge Remote is for – it closes the gap between the managed Atlassian Cloud and a company’s own infrastructure.
How Does Forge Remote Work?
In a pure Forge app, the frontend and backend run entirely within the Atlassian Cloud. Forge Remote, by contrast, allows UI components (Custom UI or UI Kit) to be hosted in the Atlassian Cloud while the business logic runs on the company’s own cloud infrastructure (AWS, Azure, or its own servers).
Frontend (Custom UI / UI Kit). Continues to run securely, hosted within the customer’s Atlassian environment.
Backend (Remote Gateway). Runs on your own infrastructure – AWS, Azure, or on-premise.
Communication between Forge and the remote backend takes place over a cryptographically secured protocol. Atlassian signs every request with a Forge Invocation Token (FIT) – a JWT verified against Atlassian’s public JWKS endpoint. The backend verifies this signature, ensuring that the request is guaranteed to originate from an authenticated Jira or Confluence tenant.
Three Scenarios Where Forge Remote Is the Solution
In what kinds of use cases is Forge Remote the tool of choice? Let’s look at three concrete examples.
Heavy compute & ML processing. Forge functions’ execution limits are often not sufficient for video processing, generating large PDFs, or running your own LLM models. The remote backend takes on the heavy lifting asynchronously.
ERP and on-premise integration. Behind the firewall sits an SAP system or a SQL database. A remote microservice within the company network securely delivers the data to the Forge frontend in the user’s browser.
Connect migration without a complete rewrite. With the gradual end of Atlassian Connect, teams don’t need to completely rewrite their grown app logic, which would take weeks. Instead, the backend continues to be used as a remote service – now under Forge’s new security and authentication umbrella.
A Look at Practice: How the Data Flow Works
Without even diving into the code, the integration can be described in three simple steps.
The declaration. In the Forge app’s configuration (manifest.yml), the team specifies its own server’s endpoint under remotes, along with the required permissions. This tells Atlassian exactly where requests are allowed to be routed.
The automatic handshake. When a user triggers an action in an Atlassian tool – Jira, for example – the Forge frontend sends the request to the Atlassian Gateway. The platform automatically attaches all security tokens and forwards the request to the backend. The team doesn’t need to worry about the complex OAuth handshake logic.
The response in the company network. The remote server receives the request, validates its origin within milliseconds, and executes the desired business logic – for example, a database query in the company’s own data center or a complex calculation. The result is sent back to Jira and displayed natively to the user in the interface.
Decision Matrix: Pure Forge vs. Forge Remote
The following compact matrix provides guidance on when pure Forge is a good choice and when the development team turns to Forge Remote instead.
| Criterion | Pure Forge (Serverless) | Forge Remote |
|---|---|---|
| Hosting & maintenance | 100% Atlassian (zero ops) | Own backend (AWS, Azure, on-prem) |
| Programming languages | JavaScript / TypeScript | Any (Java, Python, Go, C#) |
| Compute limits | Execution limit (~25s), limited memory | No execution limit, but event invocations must still respond within 5s |
| Data storage | Forge Key-Value / SQL Storage | Own databases & on-premise |
| Setup effort | Very low | Medium to high (auth verification) |
Best Practices and Pitfalls
Architectural freedom comes with responsibility. Teams deploying Forge Remote in enterprise environments need to keep a close eye on three factors in particular.
Latency Optimization
Since requests now travel from the Atlassian Gateway to your own server and back, network latency is introduced. Batching and caching matter: avoid making a separate request for every single detail. Bundling data on the backend and intelligent caching on the frontend form the best strategy.
End-to-End Logging and Tracing Across System Boundaries
A request fails – is the problem in the frontend, at the Atlassian Gateway, or in your own backend? This is where the context information supplied by Atlassian can help, by having the team pass a unique correlation ID through every call. It’s also advisable to connect the remote backend to a central monitoring tool (such as Sentry or Datadog) in order to link backend errors directly to user actions in Jira.
”Runs on Atlassian” and the Data Protection Trade-off
Pure Forge apps can earn the “Runs on Atlassian” quality seal, which certifies “zero data egress” for the app: no data leaves the secure Atlassian environment. Does this badge become void for apps using Forge Remote? Yes – since data logically flows to the external backend, the “Runs on Atlassian” seal is off the table. But that’s a conscious architectural trade-off. Anyone who needs to connect an existing SAP system or a complex legacy backend simply can’t insist on “zero egress.” The responsibility merely shifts: the operating company must ensure that the remote backend meets the highest standards and provide customers with clean data processing agreements.
A Key to the Step into the Atlassian Cloud
For mid-market and enterprise organizations, Forge Remote is a key that makes it possible to take the step into the Atlassian Cloud without having to throw existing systems overboard. Here, Forge Remote proves to be a Swiss Army knife for complex enterprise integrations in the Atlassian Cloud: the platform combines the trust and UI integration of Forge with the freedom of your own server infrastructure.
Planning to connect a legacy system to Jira or Confluence? If your team wants to build the Forge Remote integration yourselves, our Forge Developer Trainings cover exactly that. Would you rather have it built and hardened for you? Our Atlassian development team is here to help.