Jira Forge vs Connect: Which Platform Should You Build Your App On?

We've shipped Jira Marketplace apps on both Forge and Connect. And every time someone asks us which platform to pick, the honest answer is: it depends on what your app actually needs to do.

This isn't a "Forge is always better" post. It's the comparison we wish existed when we were making that decision ourselves — covering real tradeoffs, not just the marketing copy on Atlassian's docs.

The Core Difference

The platforms differ at a fundamental level, not just in features:

Atlassian Connect is the older model. Your app lives on your infrastructure — your servers, your database, your hosting bill. Atlassian sends webhook events to your endpoints, and your code calls back through the Atlassian REST API using JWT authentication. You own everything.

Atlassian Forge flips this. Your code runs inside Atlassian's infrastructure as serverless functions. No public endpoints, no JWT validation, no servers to maintain. Atlassian invokes your functions directly and handles auth, storage, and tenant management for you.

The mental model: Connect is a web app that integrates with Jira. Forge is code that runs inside Jira.

How the Architectures Actually Work

Here's what each flow looks like at runtime:

Security: Where Connect Apps Go Wrong

This is the section we wish someone had written for us earlier.

Connect apps require you to implement JWT validation on every incoming request. Get it wrong and you have an unauthenticated endpoint that anyone can call. This happens more than you'd think — security researchers find misconfigured Connect apps in the Atlassian Marketplace every year.

With Forge, there are no public endpoints. Period. Atlassian invokes your functions internally. There's nothing to expose, nothing to misconfigure. Secrets live in the Forge Secrets API, not in your .env file that someone might commit to GitHub.

Storage Capabilities

The storage story is where you'll feel the most platform-level constraint:

For most Jira apps — storing config, workflow state, user preferences — Forge Storage is plenty. Where it breaks down: apps with complex relational data (reporting, analytics), large file handling, or anything that needs to JOIN across datasets.

Runtime Limits That Actually Matter

Forge functions run in a sandboxed environment with hard limits. These aren't theoretical — they'll hit you in production:

The 25-second timeout is the one that catches teams off-guard. If your function does any of the following, you'll hit it:

• Calls a slow external API (AI services, ERP systems)
• Processes bulk Jira data (importing hundreds of issues)
• Runs file parsing or transformation

Connect has no such limit. Your server, your rules.

Developer Experience: Day-to-Day Reality

Forge DX

Deploying a change is one command: forge deploy. No Docker, no CI pipeline, no container registry. For local development, forge tunnel gives you real-time hot reload with actual Atlassian data flowing through your local code.

The tradeoff: you're in Atlassian's ecosystem. TypeScript only. The SDK is your interface to everything. The community is smaller (fewer Stack Overflow answers, fewer open-source examples to learn from).

Connect DX

Full control over your stack. Python, Java, Ruby, Go — whatever your team knows. Standard web development patterns. The Connect framework is essentially "build a web app with a specific auth scheme." That's familiar territory.

The cost of that familiarity: you manage deployment complexity — Docker, Kubernetes, CI/CD pipelines, environment management. And unlike Forge, you need to handle tenant lifecycle events (install, uninstall, upgrade) manually.

// Forge: calling Jira API — no auth setup needed
import { requestJira } from "@forge/bridge";

const response = await requestJira("/rest/api/3/issue/PROJ-123");
const issue = await response.json();

// Connect: same call requires JWT setup first
const jwt = require("atlassian-jwt");
const token = jwt.encode(payload, sharedSecret);

const response = await axios.get(
  `${baseUrl}/rest/api/3/issue/PROJ-123`,
  { headers: { Authorization: `JWT ${token}` } }
);

Marketplace Review

Both platforms go through Atlassian's review process, but Forge has a smoother path:

• Forge apps get a simplified security review (Atlassian trusts their own runtime)
• Connect apps require detailed documentation of how you store and protect tenant data
• Forge apps can earn the "Forge-powered" badge — increasingly used by enterprise buyers as a trust signal

When to Pick Forge

• Building a new app with straightforward storage needs
• Small team that doesn't want infrastructure overhead
• Cloud-only deployment (Forge doesn't support Data Center)
• Apps with simple server-side logic: CRUD, workflow rules, panel UIs
• You want a streamlined Marketplace security review

When to Pick Connect

• Your app genuinely needs a relational database
• Long-running background processes or ML inference
• You need to support Jira Data Center / Server
• Extending an existing service with its own backend
• Non-JavaScript stack (Python ML pipelines, Java enterprise systems)
• High-volume apps where Forge timeout limits become blockers

Our Honest Take

We've shipped apps on both. Forge has gotten significantly better in the last 18 months — the DX is genuinely good now, and for most Marketplace app use cases, you'll never hit the storage or timeout ceilings.

Our default for new projects in 2025: start with Forge. The developer velocity is higher, the security posture is better out of the box, and you avoid a whole class of infrastructure decisions that don't need to be made yet.

Revisit Connect when you hit a concrete limitation — not before.

Building a Jira Marketplace app and want to get the architecture right from the start? Talk to our team — we've shipped apps on both platforms and can help you avoid decisions you'll regret at scale.

Related: Jira Apps & Integrations at DevNexus