Why We Build Exclusively on Atlassian Forge (And Why It Matters for Your Data)

When you install an app from the Atlassian Marketplace, you're making a trust decision. That app is going to interact with your Jira data — your issues, your users, your workflows. But not all Marketplace apps handle your data the same way.

There are two fundamentally different architectures for Atlassian apps: Connect andForge. The difference matters more than most teams realize.

Connect: The External Server Model

Most established Marketplace apps — including many of the most popular ones — are built on Atlassian Connect. Connect apps run on the vendor's own servers, outside of Atlassian's infrastructure. When you use a Connect app:

• Your data is sent to the vendor's servers via REST API calls
• The vendor manages their own infrastructure, security, and compliance
• You're trusting a third party to handle, store, and protect your data
• The vendor pays Atlassian a 20–25% revenue share on every transaction

This model has worked for years. But it creates a real tension: every Connect app is another vendor in your security review pipeline, another data processor in your compliance documentation, another external endpoint your data flows through.

Forge: The Native Model

Forge apps run entirely inside Atlassian's infrastructure. When you install a Forge app:

• Your data never leaves Atlassian's servers
• The app runs in a sandboxed environment managed by Atlassian
• No external API calls, no vendor-hosted servers, no data export
• The app inherits Atlassian's own security controls (SOC2, ISO 27001)

For teams that care about data security — and especially teams pursuing compliance certifications — this is a meaningful difference. A Forge app doesn't add a new entry to your vendor risk register.

Why We Chose Forge

At Orbiscend, every product we build runs on Forge. This wasn't a convenient default — it was a deliberate architectural decision.

For Argon (our JQL search extension), this means your search queries and results never leave Jira. When you run a regex match across your issues or query parent-child hierarchies, that processing happens inside Atlassian's infrastructure.

For Dike (our SOC2 compliance tool), the irony would be too painful otherwise. A compliance tool that sends your data to external servers would undermine the very compliance posture it's supposed to improve. Dike runs where your data already lives.

What This Means in Practice

If you're a Jira admin evaluating Marketplace apps, here are the practical implications:

Security reviews are simpler. A Forge app doesn't require a separate vendor security assessment. The app runs in Atlassian's environment, under Atlassian's security controls.

Compliance documentation is lighter. For SOC2, ISO 27001, or GDPR purposes, a Forge app is processed by Atlassian — not by a third-party vendor. That's one fewer data processor to document and audit.

Performance is more predictable. No external API latency, no dependency on a vendor's uptime. If Jira is up, the app is up.

Data residency is preserved. Your data stays where Atlassian stores it. No cross-border transfers to vendor servers in different jurisdictions.

The Trade-Off

We should be honest about what Forge doesn't do. The Forge platform is newer and more constrained than Connect. Some types of apps — particularly those that need to integrate with systems outside of Atlassian — are better suited to Connect. Forge apps can't do everything.

But for tools that operate on your Jira data — searching, analyzing, monitoring, reporting — Forge is the right architecture. The security and performance advantages are real, and they compound as your organization's compliance requirements grow.

Try the Forge Difference

Both Argon and Dike are free to install and use. If you're curious about what Forge-native apps feel like compared to Connect-based alternatives, install one and see for yourself. The "Runs on Atlassian" badge on our listings isn't just a logo — it's a promise about where your data lives.