Update: Since publishing this blog post, we’ve heard a great deal of feedback from Partners and developers. We want to answer a few of the questions you asked here on the blog for greater visibility, and outline how we plan to address concerns.
We heard some developers express concern that Connect will be removed from service in 2022. We want to be clear: this is not the case, and we apologize for the ambiguity. The end of 2022 is the date when we expect that all apps will be able to start the process of going from State 1 to State 2 (and many will be able to start the process sooner). It is not a deadline for making the updates necessary to move to State 2, nor is it the date when any Connect services will be switched off.
In the spirit of OCNB, we do want to be transparent that remote iframes and JWT auth will be deprecated in Connect at a future date. We don’t yet know when the official deprecation date will be for these Connect features, but we are committed to providing equivalent functionality in Forge and plenty of time to make updates before any Connect functionality is removed. We know replacing these features is likely to be a significant undertaking for Connect app publishers, and because of this, we decided to provide this information early, even though the pathway to reaching State 2 is still being built.
If you use JWT and remote iframes in your Connect app, we ask you to collaborate with us, keep providing your honest feedback, and share the details of your implementation. Our priority is helping Partners get to State 2 with as little disruption as possible, and to do this, we need to understand your current architecture. This will inform both what we build for you and when.
We’re holding an Office Hours session on Oct 20 with the Forge Product team, and we invite you to sign up to attend here. Bring your questions, talk to us about the complexity you anticipate and the essential functionality you need—we take all of this into consideration for roadmap planning and we’re here to support you in this process.
During Developer Day 2021, we presented a first look at the pathways we’re building to unite Forge and Connect as a single platform. Since that announcement, we’ve continued to make progress towards defining what this unification process will look like. We wanted to share our latest thinking and give you an update on where we are today.
It’s still early days, and our intention in sharing this information is to give you a look at our long-term roadmap in order to help inform your own long-term roadmap planning. In places where dates are uncertain or features must be shipped to unblock subsequent steps, we’ll link to public-facing resources where you can track updates. We’ll also share quarterly communications on this topic as development progresses and timelines come into focus. You can stay up to date by subscribing to #forge-connect in the Developer Community.
The unification process won’t be an all-or-nothing replacement of Connect capabilities with Forge capabilities. Instead, we view Forge adoption as a series of four progressive states. Apps move to higher states by gradually replacing Connect components with Forge equivalents. Today, it’s possible for developers to experiment with moving their apps to the first state. In the future, we’ll unblock all four states, which will allow a Connect app to keep its existing Marketplace listing and customer installs while gradually adopting Forge functionality.
Along the way, we’re committed to helping Partners through the transition. We’re prepared to offer high touch support for Partners moving their apps to Forge via the Developer Community, and we’ll be paying close attention to feedback.
Each app will follow a slightly different journey. For some Connect apps, particularly those that do not use off-Atlassian storage and compute, the path to adopting Forge components may be relatively straightforward. We recognize that some apps must use off-Atlassian compute or storage for various reasons, and we aren’t planning on having these options go away. While we aren’t ready to share details on the protocol and mechanisms just yet, Forge apps will be able to interact with remote compute and storage services and vice-versa. Though this provides greater flexibility in app architecture, developers will be encouraged to use native Forge compute and storage services where possible.
We’ll go into more detail about these states and what this looks like for Marketplace apps later in the post, but first we’ll share some background on why Forge represents the future of the Atlassian Marketplace.
Forging a world-class app ecosystem
Apps that are developed on Forge have some notable differences from apps built with Connect. One of the most obvious is where the app is hosted. Forge apps are hosted by Atlassian, within the Atlassian Cloud. Connect apps are hosted entirely by the app developer, on infrastructure that app developers are responsible for configuring, maintaining, and scaling.
While Atlassian-managed infrastructure has clear benefits for developers who no longer need to worry about the overhead of servers and hosting, it also helps app developers meet the trust and security requirements of customers. Self-hosted app infrastructure on platforms like AWS, GCP or Azure creates greater surface area for a malicious attack, and app vendors are responsible for hardening services that store data or run their application. Through shared responsibility, Forge is designed to help you protect against common attack vectors and meet security requirements and guidelines for cloud apps in the Marketplace, including built-in authentication and authorization, egress control, vulnerability scanning and patch updates.
As Atlassian further hardens the platform and obtains additional security certifications, apps will benefit from these improvements with no additional effort. This reduces the resources required for vendors to become compliant and ensures safe and secure apps for our mutual customers. We’re continuing to invest in Forge with the goal of building not just the best developer experience but also the best customer experience.
New apps that are developed from scratch on Forge benefit from these features from day 1. For Connect apps that are already listed in the Atlassian Marketplace, we’re building out a pathway to adopt the benefits of Forge gradually, without needing to rewrite the app completely.
We call this path Connect-on-Forge, which we’ll outline in the next section.
Connect on Forge: four states of Forge adoption
An app’s evolution from Connect to Forge consists of a series of four states, where each state reflects a greater degree of Forge adoption. The process begins with State 0, fully on Connect, followed by optional but recommended enhancements to your app which lead to State 4, fully on Forge.
It’s worth spending a little time on terminology—what do we mean by fully on Connect or fully on Forge? As soon as a Connect app is registered on Forge (the step that moves an app into State 1), it gains a Forge manifest and is recognized as a Forge app, even though it still has remote compute and storage. From State 1 onwards, an app is considered a Forge app, and every progressive state the app moves into reflects a greater degree of Forge adoption. When we say “fully Forge”, we mean that the app has moved all storage and compute within the Atlassian Cloud, a step that we recognize may not be feasible for all apps.
Ultimately, we want 1) customers to have greater visibility into where and how their data is consumed by apps and 2) app developers to have a means of processing data and compute within the Atlassian cloud, except in cases when remote services are absolutely necessary; for example, apps whose purpose is to integrate with an external SaaS application. While we will not be building an approval process around State 3 and State 4 exceptions, with egress disclosure in place, we will make it more transparent to end customers where data is shared and processed.
State 0: Classic Connect
The starting point is State 0, an app that was built on Connect and has yet to take any steps toward adopting Forge functionality.
State 1: Registered on Forge
LIMITED ALPHA RELEASE
An app in State 1 has gone through the process of registering the Connect app on Forge, allowing it to be recognized as a Forge app.
The Connect-on-Forge registration process is still in alpha, and it’s not yet possible to list a Connect-on-Forge app on the Marketplace. We expect this limitation to be removed by the end of 2021, which will allow a Connect app to maintain its existing listing, with minimal disruption to customers who have already installed the app. To customers, the switch from Connect to Forge will look like a typical app update.
While this feature is still under construction, early adopters can begin to experiment with Connect-on-Forge apps in their test environments. We don’t yet recommend this feature for production use. You can track our development progress in the Community and Changelog, where we’ll post updates.
State 2: Forge Auth and UI
COMING SOON
Before reaching State 2, an app must have already moved into State 1 by registering as a Forge app. Then, the app must meet 2 requirements:
- If the app uses JWT auth to authenticate against product APIs, it must be replaced with Oauth 2.0
- Connect remote iframes must be replaced with Forge Custom UI or UI kit
In State 2, the app gains important security benefits. First, an app developer can limit the types of data the app can access using scopes, bringing the app in line with the principle of least privilege. Second, replacing Connect remote iframes protects app users from common remote iframe browser-based vulnerabilities and domain hijacking.
Because these security improvements are high priority, we will be requiring all Connect apps to reach State 2, and in the future, Connect will stop supporting JWT auth and remote iframes. While these services are not being deprecated yet and we are still far out from making this a hard requirement, we encourage app developers to start planning to make these changes as soon as development is unblocked, which we estimate will happen towards the end of 2022.
It’s important to note: Connect remote iframes and JWT auth will not be deprecated until Forge provides equivalent or similar functionality. We are not aiming for 1:1 parity with modules that use Connect remote iframes, but do plan to support corresponding use cases in Forge. The timeline for these changes will allow enough buffer for app vendors to apply necessary updates.
We’re currently working to unblock State 2 for app developers. Stay tuned for updates in the Changelog, and you can also track regular announcements here.
State 3: Atlassian hosted (Data only)
FUTURE
Before reaching State 3, an app must have already met the requirements to become a State 2 app. Then, the app must host any remote-hosted data in the Atlassian Cloud. Some apps do not require any remote data storage at all by design, and these apps would be eligible to pass directly from State 2 to State 4.
Reaching State 3 helps apps leverage upcoming features like storing app data in the same region as the customer’s Cloud instance, meeting data residency requirements for many customers. State 3 also helps app developers meet the needs of highly-regulated enterprise customers who restrict storage of their data on third-party infrastructure. Finally, State 3 paves the way for reaching State 4, where apps adopt the full capabilities and benefits of the Forge platform.
For apps that do require remotely hosted data, we are in the process of building tooling that will help developers migrate data from self-hosted databases to Forge. We encourage app developers to start considering moving their apps to this state once their apps are eligible, because they will benefit from an easier path to security compliance, support for app data residency, as well as access to free (up to quotas, through 2023) and secure storage on the Atlassian Cloud.
Although strongly recommended, State 3 and State 4 are not hard requirements, leaving room for exceptional cases where apps cannot move away from “off-Atlassian” compute and storage. Examples of exceptional cases include:
- Apps that are by nature integrations between the Atlassian platform and external applications.
- Apps with extremely heavy compute and storage requirements that exceed Forge quotas.
- Apps that require massive amount of data for machine learning or reporting purposes.
State 4: Atlassian hosted (Data & Compute)
FUTURE
Before reaching the final state, State 4, an app must not store any data outside of the Atlassian cloud (either through migration or by design). In addition, an app must migrate any remote-hosted compute in the Atlassian cloud. Some partners may take the opportunity to rebuild their Connect app as a Forge app (State 4) and migrate the Marketplace listing to carry over previous installs and reviews.
We’re in the process of building migration pathways that will open up State 4 to developers, and we encourage developers who can migrate their compute to the Atlassian Cloud to do so once we’ve unblocked migration. Apps who reach State 4 gain performance and scalability improvements as well as an easier path to enterprise-ready compliance certifications.
- In terms of scalability, Forge infrastructure automatically scales up resources in response to increased traffic, without any configuration on the part of app developers.
- In terms of performance, Forge functions will run in the same region as the customer’s Cloud instance, resulting in improved latency for any interactions with product and storage APIs.
- And in terms of compliance, the underlying platform that apps run on and store data in will be certified SOC2 compliant. SOC2 certification means Atlassian uses tools and practices that allow us to meet a high level of security, privacy, reliability and disaster recovery readiness. This doesn’t automatically make apps compliant too, but greatly reduces the work required when vendors pursue their own compliance certifications.
| State | Estimated Effort | Criteria | Benefits |
| State 0: Classic Connect | |||
| State 1: Registered on Forge LIMITED ALPHA | EASY Takes less than a week. | Register Connect app on Forge | Allows an app to carry over existing Marketplace listing, with minimal disruption to customer installs |
| State 2: Forge Auth and UI COMING SOON | MINOR REWORK Takes weeks to months. | – Must satisfy State 1 criteria – Replace JWT auth with OAuth 2 and its more granular data scopes – Replace Connect remote iframes with Custom UI or UI kit | – Allows apps to access only the data they need, reducing the risk assumed by developers – Improves security, hardening apps against common remote iframe browser-based vulnerabilities and domain hijacking – Enables progressive migration to Forge’s hosted capabilities, allowing apps to gradually convert existing Connect modules to Forge while adding on Forge modules to incorporate new features. |
| State 3: Atlassian hosted (Data only) FUTURE | MINOR TO MAJOR REWORK Effort varies depending on how heavily your app relies on data storage. Likely to be significant. | – Must satisfy State 2 criteria – All app storage on-Atlassian (via entity properties or storage services), or storing no data at all – Integrations: App storage on-Atlassian or integrated service via External Auth | – Access to free (up to platform quotas, through 2023) and secure storage on Atlassian’s cloud – Satisfy cloud data residency requirements by adopting Atlassian product capabilities – Easier path to compliance certifications (e.g. SOC2) |
| State 4: Atlassian hosted (Data and Compute) FUTURE | MINOR TO MAJOR REWORK Effort varies depending on app’s overall complexity. Likely to be significant. | – Must satisfy State 3 criteria – All core app compute runs on-Atlassian (via FaaS) – Integrations: Core compute runs on Atlassian or integrated service via External Auth | In addition to above… – Improved performance and scalability using Atlassian’s cloud – Significantly easier path to compliance certifications (e.g. FedRAMP) |
What steps can you take today?
First, if you’re building a new app, we recommend building it on Forge. This positions your app to take advantage of Atlassian-hosted data and compute, as well as enhanced security, from day 1. If you find any capabilities missing that prevent you from building on Forge, please make a request here: Give feedback.
Second, you can experiment with registering an existing Connect apps on the Forge platform, a feature still in alpha. Registering a Connect-on-Forge app is as simple as making some minor changes to your app’s Forge manifest file and running a few Forge commands, although there are still limitations that prevent Connect-on-Forge apps from being production-ready or listed in the Marketplace. For further details, see the documentation.
Lastly, start assessing your existing Connect apps and planning ahead for what moving to Forge will look like. Take stock of your app’s architecture, particularly around JWT auth, remote iframes, data storage, and core compute. We recommend prioritizing States 1 and 2 in the near term and putting States 3 and 4 on your longer-term radar. We’ll continue to provide regular updates on our work to bring Connect and Forge together, to help you prepare to take advantage of unification as soon as these pathways are ready.
What’s next?
We are actively working to support Connect-on-Forge apps on the Atlassian Marketplace, which will include the ability to migrate existing Connect app listings while preserving installations. This will unblock apps to move from State 0 to State 1 and is scheduled to be completed by the end of 2021.
Once apps are clear to reach State 1, we will begin adding more functionality, such as allowing Connect-on-Forge apps to authenticate with Atlassian APIs using OAuth 2.0 and use storage in Atlassian’s cloud—work that will begin to unblock States 2 and 3. While long-term estimates can fluctuate, our rough timeline to fully unblock State 2 and hosted storage for Connect-on-Forge apps is by the end of 2022.
We’re committed to sharing information early and often, and you can expect frequent updates on this topic as we work to combine Connect and Forge into a unified development experience. If you’d like to know more, stay up to date on the latest developments or share feedback, please join the conversation on the Atlassian Developer Community.