Forge vs Connect in 2026: Which Atlassian Platform Should You Actually Bet On?
The answer used to be 'it depends'. It still is, but the balance has shifted. Here is how we think about the Forge vs Connect decision for new Atlassian apps in 2026.
If you are building a new app for Jira or Confluence, you have two platforms to pick from: Forge and Connect. Both are supported. Both are on the Marketplace. Both will still be around next year. And yet the decision matters, because picking the wrong one costs you months.
We have shipped on both, and we have written before about the hard-won lessons from actually running apps on the Marketplace and the discipline of building inside someone else's platform. Here is how we think about the platform choice itself, in early 2026.
The Short Version
Forge is where Atlassian is investing. It is serverless, it runs on Atlassian's infrastructure, and it has become genuinely capable in the last eighteen months. For most new apps, it is the right default.
Connect is the older platform. You host the app yourself, your UI runs in an iframe inside the Atlassian product, and you integrate via REST. For a specific set of use cases, it is still the better choice — but that set is narrower than it used to be.
Details below.
What Forge Gets You
The short story is that Forge handles infrastructure so you do not have to. No servers, no deploys, no uptime monitoring for the core runtime. You write handlers, Atlassian runs them, and your app scales with demand without you doing anything.
This is more valuable than it sounds. Atlassian's own documentation describes Forge as their strategic platform, and the investment pattern bears that out: the feature gap between Forge and Connect has narrowed steadily, and most of the genuinely new capabilities — storage, async events, custom UI kit components, queue triggers — have been shipped Forge-first.
The security posture is also meaningfully stronger. Forge apps run in an isolated sandbox, permissions are declared up front in the manifest, and data residency is handled by the platform. Customers in regulated sectors increasingly ask about this, and being able to answer "Forge-native, Atlassian-hosted, complies with their data residency model" is a real advantage during procurement.
The developer experience has also improved. The CLI is mature. The tunnel for local development works. Storage primitives, scheduled triggers, and async event handlers are now genuinely usable in production.
Where Forge Still Bites
It is not all upside.
You are running on someone else's runtime. That means you live within their CPU limits, their invocation time limits, and their pricing model. For most apps this is fine. For computationally heavy workloads — large data exports, bulk processing, anything that wants to hold a lot in memory — the limits show up and there is no workaround other than offloading work elsewhere.
The invocation model can also surprise you. Forge functions are stateless and short-lived. If you are used to building long-running services that keep caches warm, you have to adjust. This is not hard, but it is a mental shift.
Integrating with anything outside the Atlassian ecosystem is slightly more friction than it would be in a self-hosted app. External HTTP calls work, but they are metered, logged, and subject to egress rules.
Where Connect Still Makes Sense
Connect is not deprecated, and it is not going away. There are cases where it is genuinely the better choice.
Heavy computation. If your app does serious processing — machine learning inference at scale, large data transforms, anything CPU-bound — you will be happier owning the hosting and not fighting Forge's limits.
Deep external integration. If your app is primarily a bridge to another system that you also own, Connect keeps all your infrastructure in one place. You do not have two deployment pipelines, two monitoring setups, two sets of secrets to manage.
Existing Connect apps. If you already have a large Connect app in production, migrating to Forge is a real project, not a weekend job. Atlassian's migration guidance is honest about this. The right time to migrate is when you are already doing a significant rewrite anyway, not as a standalone initiative.
Custom UI that does not fit the Forge UI Kit. The UI Kit has come a long way, and Custom UI in Forge (iframes with a sanctioned API) closes most of the remaining gaps, but if your app has an unusual interaction pattern that Connect's more permissive iframe model makes easier, that is a legitimate reason to stay.
What We Actually Recommend
For a new app in 2026: start with Forge. The platform has matured enough that the default should be Forge unless you have a specific reason to choose otherwise. The reasons we have seen that genuinely justify Connect are all some variation of "we need to own the compute". If you cannot articulate a version of that reason, you probably do not need it.
For an existing Connect app: do not migrate just for the sake of migrating. Wait until you are doing a significant feature rewrite, a rebranding, or an architectural overhaul anyway. Pair the migration with work you were going to do. A standalone "move from Connect to Forge" project rarely justifies itself on a spreadsheet, even if it makes sense in principle.
For an app that straddles: Forge and Connect are not mutually exclusive. You can have a Forge app that calls out to a Connect-style service you host yourself. If your app has a small, interactive core and a large, compute-heavy back end, splitting it is often the cleanest answer.
The Strategic Reading
The thing to notice about Atlassian's platform direction is that Forge is where the new things land. Atlassian's developer changelog makes this obvious if you read it for a few months. New primitives, new integration points, new UI components — all Forge first, some Forge only.
This does not mean Connect apps are second-class citizens. It does mean that if you want to be well-positioned for whatever Atlassian ships next — AI-adjacent features, new marketplace mechanics, new data APIs — being on Forge is the safer bet.
The boring answer is usually the right answer. In 2026, the boring answer for new Atlassian apps is Forge.
Planning a new Atlassian app and not sure which way to go? Get in touch — or see our Atlassian development services. We have shipped on both platforms and can give you a straight answer for your specific case.