The choice between Atlassian Forge vs. Connect is no longer really a choice. Connect has a formal end-of-support timeline, and Forge is where all new development belongs. Here’s what that means for developers, how the two frameworks actually differ, and what to do if you have existing Connect apps in production.
From Connect to Forge: A Brief History
Atlassian Connect launched as the first framework for building cloud apps on Jira and Confluence. It followed a conventional model: your app lives on a server you host, communicates with Atlassian products via webhooks and REST API calls, and you’re responsible for everything — infrastructure, uptime, security, and scaling.
Forge launched in 2021 as a fundamentally different approach. Instead of hosting your own server, your app runs as serverless functions on Atlassian’s own infrastructure (backed by AWS Lambda). Atlassian handles hosting, security sandboxing, and runtime management. Developers define capabilities through a manifest file and deploy via the Forge CLI.
For several years, both frameworks coexisted. Then in 2025, Atlassian formally announced that Connect would be phased out entirely. The transition isn’t optional — it’s a matter of when, not if.
Atlassian Forge vs. Connect: The Core Differences
The two frameworks reflect fundamentally different philosophies about where app logic should live and who should manage it.
Connect hands control to the developer: you build on any language, host wherever you want, and integrate via REST. That flexibility comes with a cost — your team owns the infrastructure, the certificates, the uptime, and the security posture of the app.
Forge inverts that model. Atlassian manages the runtime, the sandboxing, and the hosting. You write JavaScript or TypeScript, declare your app’s capabilities in a manifest, and deploy with a single CLI command. Less flexibility on the surface, but dramatically less operational overhead.
Here’s how the two compare across the dimensions that matter most:
The biggest practical difference for most teams isn’t the hosting model — it’s the language constraint. Connect lets you write in Java, Python, Ruby, or whatever your team knows. Forge requires JavaScript or TypeScript. For Java or Groovy shops, that’s a real adjustment that needs to be factored into project timelines.
Atlassian Forge App Development in Practice
Once you’re working in Forge, the development model is well-structured and the tooling is solid. A few things worth understanding before you start:
The module system. Forge apps are defined by a manifest file that declares every capability your app needs — custom fields, event listeners, UI panels, scheduled jobs, custom JQL functions, and more — all as Forge modules. This is more structured than Connect’s approach, and it means your app’s capabilities are explicit and auditable rather than implied by server-side logic.
Function time limits. Forge functions time out at 25 seconds. For short operations — field calculations, event-triggered updates, lightweight API calls — this is plenty. For long-running processes, you’ll need to redesign around async queued events rather than synchronous chains. This is the most common architectural adjustment teams make when moving to Forge.
Built-in environments. The Forge CLI gives you separate development, staging, and production environments out of the box. There’s no infrastructure work required to get a proper deployment pipeline — it’s part of the platform.
Security by default. Atlassian reviews Forge apps for security before they’re listed on the Marketplace, and the sandboxed runtime limits what an app can access. For teams building internal tools, this reduces the compliance burden considerably compared to self-hosting a Connect app.
Version control and collaboration. Because Forge apps live in a proper codebase — manifest, function handlers, dependencies — they fit naturally into standard engineering workflows: pull requests, code review, branching, CI. Connect apps could be structured this way too, but there was nothing enforcing it. Forge makes good practices the default.
If your team wants to build Forge skills in-house, check out our Forge Development Bootcamp — a hands-on program designed to get developers up and running on Forge fast.
Connect’s End-of-Support Timeline
Atlassian has laid out a three-phase sunset for Connect. The first two milestones have already passed — the third is what’s still ahead:
- September 17, 2025 (past): New Connect apps can no longer be submitted to the Atlassian Marketplace
- March 2026 (past): Existing Connect apps can no longer receive updates on the Marketplace
- Q4 2026 (upcoming): Connect enters full end-of-support — apps built on Connect may continue to function initially, but Atlassian will not maintain compatibility as the platform evolves
That last phase is the critical one. “Apps may continue to run at their own risk” is not a stable place for production tooling. As Atlassian ships platform changes, Connect apps will progressively break in unpredictable ways with no support path.
For a practical breakdown of what these phases mean app by app, our Forge Apps site covers the deprecation timeline in detail — it also tracks migration status across the Marketplace app catalog.
Atlassian Forge vs. Connect: Which Should You Use?
For new development: Forge, without question. Building on Connect today means building on a framework with a confirmed end-of-life. You’d be creating a migration project for yourself before the app is even finished.
For existing Connect apps: The March 2026 deadline has passed — Marketplace Connect apps can no longer receive updates. If you haven’t started your Forge migration yet, now is the time. The Q4 2026 end-of-support date is the hard wall: after that, Connect apps may break as Atlassian ships platform changes with no compatibility guarantees. Migrations done under deadline pressure tend to cut corners that create problems later.
For custom internal solutions: If you’re building something for your own Jira or Confluence instance rather than the Marketplace, Forge is still the right choice. The Marketplace deadlines don’t directly apply to internal apps, but the end-of-support does — your Connect-based internal tools will face the same compatibility risks in Q4 2026.
On Forge’s limitations: Forge is not without constraints. The 25-second function timeout rules out certain long-running patterns without architectural redesign. The sandboxed environment means you can’t make arbitrary outbound calls without declaring them in the manifest. And some niche Atlassian APIs that were accessible via Connect’s REST surface aren’t yet fully available in the Forge API. For the vast majority of custom app use cases these limitations don’t matter — but it’s worth auditing your requirements against Forge’s capabilities before committing to a migration timeline.
On the language trade-off: If your team writes Java or Groovy today, be honest about what the shift to JavaScript or TypeScript actually requires. It’s not insurmountable, but it’s not trivial either. Budget time for the learning curve, particularly around async patterns and the event-driven model Forge functions use. If you’re also migrating Groovy scripts from Data Center as part of a broader move to Cloud, our guide on Groovy script migration covers that side of the transition in detail.
Ready to Build on Forge?
Atlassian Forge vs. Connect is a settled question — Forge is the present and the future of Atlassian Cloud app development. The more useful question now is how to make the transition smoothly, whether that means migrating existing Connect apps or building new custom solutions from scratch.
Seibert Solutions builds custom Forge apps and helps teams plan Connect migrations. If you’re working through this transition and want experienced help, get in touch with our team.