Moving to Confluence Cloud is often the result of months of planning, security reviews, and internal discussions. IT teams evaluate compliance requirements, legal departments review data protection agreements, and administrators configure data residency to ensure that company information is managed according to organizational policies.
Once everything is approved, employees begin using Confluence to collaborate, document processes, and manage business information. Eventually, someone needs functionality that isn't available out of the box, and the natural next step is to explore the Atlassian Marketplace.
This is where an interesting question emerges. Your organization may know exactly where its Confluence data is hosted, but does it know where that information goes when a Marketplace app processes it?
It's a distinction that can easily be overlooked, particularly when an application feels like a natural extension of Confluence itself.
Not all Marketplace apps work the same way
From an end user's perspective, Marketplace applications are simply additional capabilities within Confluence or Jira. They appear inside the familiar interface, interact with existing content, and help teams accomplish tasks that would otherwise require manual work or external tools.
However, the technical architecture behind these applications can vary significantly. Some rely on infrastructure operated by the application vendor or third-party cloud providers, while others execute their application logic and store application data entirely within Atlassian-hosted infrastructure. There are also hybrid approaches that combine different services depending on the functionality required.
None of these architectures should automatically be considered more or less secure. External infrastructure may be necessary for specialized processing, integrations, or services that cannot be delivered entirely within the Atlassian platform. What matters is understanding the implications of each approach, particularly when applications interact with confidential information, internal documentation, or regulated business data.
For enterprise organizations, this isn't merely a technical distinction. It can influence vendor assessments, data protection reviews, operational responsibilities, and the overall complexity of approving a new application.
Data residency is only part of the conversation
Consider an organization that has configured Confluence Cloud data residency to meet its internal requirements. Its teams use the platform to maintain financial reports, employee documentation, operational procedures, and compliance records. From the organization's perspective, the location of its core Confluence data has already been addressed.
Now imagine that one department requests a Marketplace application to analyze information across multiple Confluence pages, generate reports, or manage structured business data. Depending on how that application is built, some information may need to be transferred to infrastructure outside Atlassian's environment for processing or storage.
This doesn't necessarily represent a security problem, nor does it automatically mean that the organization's data residency requirements have been violated. However, it introduces another layer of considerations that may not have been covered during the original Confluence Cloud assessment.
Security teams may need to understand what information is transferred, where it is processed, which services are involved, and what controls are available to administrators. They may also need to review additional contractual arrangements or assess the operational dependencies introduced by the application.
The important distinction is that configuring data residency for Confluence doesn't automatically answer every question about how an installed Marketplace application handles information.
Where Runs on Atlassian enters the conversation
Atlassian's Runs on Atlassian initiative provides a useful way to approach this discussion. Rather than evaluating every application architecture entirely from scratch, organizations can identify apps that meet a defined set of requirements related to where application workloads run and how data is handled.
Applications eligible for the Runs on Atlassian designation use Atlassian-hosted compute and storage, support data residency requirements aligned with the hosting Atlassian product, and provide administrator controls over permitted external data egress. These characteristics can make certain aspects of the technical evaluation more straightforward, especially for organizations that prefer to minimize additional infrastructure dependencies.
It's important to understand what this designation does and doesn't mean. Runs on Atlassian is not a universal security certification, and it doesn't eliminate the need to review application permissions, access controls, functionality, or compliance requirements. Similarly, applications without the designation may have excellent security practices and meet demanding enterprise requirements.
What Runs on Atlassian offers is a recognizable architectural distinction that can help organizations ask more informed questions during the application selection process.
For administrators and Solution Partners working with enterprise customers, that additional transparency can be valuable. It provides another criterion to consider alongside functionality, pricing, vendor reputation, support, and existing security certifications.
More information is available in the official Runs on Atlassian documentation.
Five questions worth asking before approving a Marketplace app
When evaluating an application, the objective shouldn't be to introduce unnecessary bureaucracy or discourage teams from adopting useful tools. Instead, organizations can benefit from a consistent set of questions that helps them understand the implications of their decisions before an application becomes part of an important business process.
1. Where does the application process and store information?
Understanding whether an application uses Atlassian-hosted infrastructure, external services, or a combination of both provides a starting point for evaluating its architecture and operational dependencies.
2. How does the application handle data residency?
Organizations with specific regional requirements should understand which application data is covered by residency commitments, where it is stored, and whether any additional processing occurs elsewhere.
3. Does the application communicate with external services?
External integrations aren't inherently problematic, but administrators should understand which services are involved, what information may be transferred, and whether the organization has appropriate controls over those connections.
4. What permissions does the application require?
Even applications operating entirely within Atlassian-hosted infrastructure still need appropriate permissions. Reviewing the scope of access requested by an application remains an essential part of the approval process.
5. Does the application qualify for Runs on Atlassian?
The designation can provide additional information about an application's architecture. Its presence may simplify certain evaluation questions, while its absence should encourage further investigation rather than an automatic rejection.
These questions don't replace a formal security assessment, but they can help make the initial conversation between administrators, security teams, business stakeholders, and Solution Partners considerably more productive.
Should application architecture become part of the buying decision?
Historically, most Marketplace app evaluations have focused on a familiar combination of functionality, usability, pricing, support, and vendor reliability. These remain essential considerations because organizations ultimately install applications to solve business problems, not to satisfy an architectural preference.
However, as Confluence and Jira become increasingly important repositories of business information, the way applications interact with that information deserves greater attention. Two applications may offer similar functionality while relying on substantially different processing and storage models, creating different operational and governance considerations for the organization adopting them.
This is particularly relevant for Solution Partners advising enterprise customers. Recommending an application isn't simply about identifying the tool with the longest feature list; it's also about understanding whether that tool fits the customer's technical environment, security expectations, and long-term operating model.
Perhaps application architecture deserves a more visible place in that conversation. Not as a replacement for functionality or traditional security evaluations, but as another factor that helps organizations make informed decisions about the applications they introduce into their Atlassian environments.
What do you think?
I'm interested in how other Confluence administrators, security teams, and Atlassian Solution Partners approach this today, particularly when working with larger organizations that have established application approval processes.
Is Runs on Atlassian already something you consider when evaluating Marketplace apps, or is application architecture still secondary to functionality, pricing, and traditional security certifications?
And for Solution Partners, are enterprise customers beginning to ask where Marketplace applications process their data, or is this still a conversation that usually starts with the technical team?
