Platform Differences between Jira Data Center and Jira Isolated Cloud
Understand how Forge and P2 differ in hosting, API access, security, and programming model, and why scripts need rethinking when you migrate.
ScriptRunner for Jira Isolated Cloud does not have the same feature set as the Data Center version. You can learn about the parity for each ScriptRunner for Data Center feature on our Feature Parity page. We also provide details on workaround script/function alternatives where there is currently no parity with Isolated Cloud.
Scripts in Jira Isolated Cloud do not execute within the same process as Jira Cloud and must therefore interact with Jira via the REST APIs and Forge-specific APIs rather than the Java APIs. Forge apps run in isolated, serverless containers completely separate from the Jira Cloud infrastructure, with all interactions mediated through defined API boundaries.
Automatic migration between Data Center and Isolated Cloud does not exist due to differences in the programming model and API. Jira Isolated Cloud uses the Atlassian Forge framework to allow add-ons like ScriptRunner to provide additional functionality, whereas Jira Data Center use the Atlassian Plugins framework, known as Plugins2, or P2. There are fundamental differences between Forge and P2 that directly impact ScriptRunner functionality and script writing; the main ones are outlined in the table below:
| Data Center (P2) | Isolated Cloud (Forge) | |
|---|---|---|
| Hosting Environment | Apps run within the Jira Data Center environment, sharing the same JVM and having direct access to the Java API. | Apps run in isolated, serverless containers managed by Atlassian's infrastructure, completely separate from the Jira Cloud environment. |
| Access to APIs | Provides direct access to Jira's internal APIs, enabling deeper integration and manipulation of its core functionality. | Limited to Atlassian's REST APIs and Forge-specific APIs. No direct access to internal APIs. All interactions are mediated through defined API boundaries. |
| UI | Any part of the UI can be customized. JavaScript runs on the page in the same context and frame as the host application. Host application code can be manipulated and broken by add-ons, and add-on code can easily be broken by host code (or its dependent libraries) updates. | UI customization is restricted to predefined extension points using UI Kit (React components) or Custom UI (sandboxed iframes). JavaScript runs in isolation and cannot access or manipulate the host application's DOM or code. |
| Security model | Operates within Jira's security context, following server-based authentication and authorization mechanisms. | Operates in a zero-trust security model with strict isolation. All API calls are authenticated and authorized by Atlassian's platform. Apps cannot bypass security boundaries. |
| Authentication and authorization | Code can run as any user in the system, including as no user (which is not the same as Anonymous). Authentication and authorization can be bypassed. | Impersonation is supported via Run As, but only within the app's granted OAuth scopes. Authorization cannot be bypassed. |
| Programming model | In the same JVM as the host application. Events can be vetoed, and code runs synchronously. A bug in add-on code can seriously affect application stability or performance. | Serverless functions run asynchronously in isolated containers. Events cannot be vetoed (only observed). Invocation limits and timeouts prevent apps from affecting platform stability. Functions have execution time limits (typically 20 seconds. |
| Extension points | Offers a wide range of extension points within Jira, enabling customizations at various levels, including UI and backend processes. | Provides a curated set of extension points (modules) for UI customization, triggers, scheduled functions, and web integrations. More limited than Data Center but expanding over time. |
| Development and deployment | Requires familiarity with Java and the Atlassian SDK for development, with deployment involving installation on the Jira server. | Uses TypeScript with the Forge CLI for development. Deployment is automated through Atlassian's infrastructure (forge deploy/install). No server management required. |
| Scalability and maintenance | Apps are subject to the same resource constraints as the Jira server and require maintenance within that environment. | Automatically scales with Atlassian's infrastructure. Atlassian handles maintenance, updates, and resource allocation. Apps have invocation limits and storage quotas to ensure fair resource usage. |
There are significant differences between the Forge and P2 frameworks, and it is necessary to rethink how ScriptRunner scripts execute and interact with the host application when moving from Data Center to Isolated Cloud. The reliance on REST APIs in Jira Isolated Cloud may present some limitations compared to the Data Center environment, as the available APIs may not cover all functionalities or provide the same level of access. However, it also offers benefits such as improved scalability, security, isolation, and the ability to integrate with other cloud services through Atlassian's managed infrastructure.
The asynchronous and isolated nature of Forge has implications with regards to host interaction. For example, Jira Isolated Cloud can't implement event listeners that prevent or veto event processing; events can only be observed and reacted to after they occur. Additionally, Forge functions have execution time limits and invocation quotas, which require careful consideration when designing automation workflows. Similarly, for Data Center scripts, it's crucial to consider performance impacts, especially when interacting with slow external systems or when synchronous execution could block critical processes.
Both Isolated Cloud and Data Center environments present unique trade-offs in script writing, balancing functionality with stability, performance, and security.