Forge vs Connect in 2026: Connect Is Ending. Here Is What That Changes

Updated 12 October 2026. When we first wrote this in January, we treated Connect as a platform you could still choose. That is no longer true, so we have rewritten the advice. The dates below come from Atlassian's own announcements, linked in each section.

If you build apps for Jira or Confluence, the question used to be "Forge or Connect?". In 2026 it is a different question. Atlassian has set an end date for Connect, and the only real choices left are how and when you move to Forge.

We build on Forge every day, and we have written before about the hard-won lessons from running apps on the Marketplace and the discipline of building inside someone else's platform. Here is where things stand now.

The Short Version

Forge is Atlassian's app platform. It is serverless, it runs on Atlassian's infrastructure, and it is where every new capability lands.

Connect is the older platform: you host the app yourself, the UI runs in an iframe inside the product, and you integrate through REST. It is being retired. Atlassian ends support for Connect on 31 January 2027.

For a new app, use Forge. For an existing Connect app, plan the move now.

The Connect Timeline

Atlassian has been phasing Connect out since 2025:

• 17 September 2025: new Connect apps can no longer be listed on the Marketplace. Existing apps keep working.
• 31 March 2026: Connect apps can no longer ship Connect-based updates. Changes now have to go out through Forge.
• 31 January 2027: end of support. Atlassian moved this date from December 2026 in August to give teams room around the holidays and annual planning.

End of support does not mean every Connect app switches off that day. It means the platform stops being looked after. In Atlassian's words, they will only fix "critical security vulnerabilities in Connect", feature deprecations "will happen with little notice", and apps that stay on Connect "might stop working properly". Over time, they may become unsafe to run. That is from Atlassian's guidance on private and custom apps, and it applies just as much to Marketplace apps.

What Forge Gets You

Forge handles infrastructure so you do not have to. No servers, no deploys and no uptime monitoring for the core runtime. You write handlers, Atlassian runs them, and the app scales with demand.

The security story is also 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 ask about this during procurement, and an app that qualifies for Atlassian's "Runs on Atlassian" badge answers most of those questions before they are asked.

The developer experience is mature now. The CLI, the local tunnel, storage, scheduled triggers and async events are all solid in production, and Forge SQL gives you a relational store when key-value storage is not enough.

What Has Changed in Forge This Year

Three changes since January matter for anyone deciding how to build.

Forge now has a price. Since 1 January 2026, Forge uses consumption-based pricing. Each app gets a free monthly allowance (for example, 200,000 GB-seconds of function time), and you pay for usage above it. Most small and medium apps stay inside the free tier. Anything doing heavy storage writes or long-running compute needs a cost estimate before launch. The current rates are on Atlassian's Forge platform pricing page.

You can run your own compute. This used to be the strongest argument for Connect. With Forge Remote, a Forge app can call a backend you host yourself, and Atlassian has said remote capabilities stay free. The trade-off: apps that send data to your own backend are not eligible for the Runs on Atlassian badge.

Long-running work can now stay on Atlassian. In August 2026, Atlassian moved Forge container services into Preview. You can run a container image on Forge infrastructure as a persistent service, deploy it to production and publish it on the Marketplace, while keeping the Runs on Atlassian badge. It is billable, and it is still in Preview, so check its limits before you depend on it.

Where Forge Still Bites

It is not all upside.

You are on someone else's runtime, so you live within its CPU, memory and invocation time limits. Functions are stateless and short-lived. If you are used to long-running services with warm caches, you have to adjust, or use containers or a remote for that part.

Calls to anything outside the Atlassian ecosystem go through declared egress. They work, but they are logged, and every external domain you add is something a security-conscious customer will ask about.

And because Forge now has usage pricing, a design that was free on your own servers can cost money on Forge. That is usually small, but it belongs in the plan.

What We Recommend Now

For a new app: build on Forge. There is no longer a choice to make here.

For an existing Connect app: start now, even if the move feels early. This is the opposite of what we wrote in January, when we said to wait for a rewrite you were doing anyway. That advice made sense while Connect had no end date. It does not now. The migration is rarely a straight port: for many apps it is a partial rewrite, and some Connect features have no direct Forge equivalent. Those are the parts you want to find in October, not in January.

How to approach it:

1. Assess first. List the app's modules, scopes, stored data and external calls, and mark which ones map cleanly to Forge, which need a rebuild and which have no equivalent.
2. Move in steps. Atlassian's adopting Forge from Connect path starts by putting the existing app on a Forge manifest. After that you can migrate one module family at a time, replacing each Connect module with a Forge one, rather than doing one big switch.
3. Keep heavy work where it belongs. If part of the app really needs its own compute, use Forge Remote or container services for that part, and keep the interactive core on Forge.
4. Plan the customer side. Data migration, permission changes customers have to approve, and the Marketplace listing all need a plan, not just the code.

For custom and private apps that your company runs on its own site: the same applies. Jira admins will see a warning in Connected Apps for apps still on Connect, and Atlassian will not rewrite them for you.

The Strategic Reading

In January we wrote that Forge was "the safer bet". It is now simply the platform. Everything Atlassian ships for apps, from new UI components to AI features and Rovo, lands on Forge.

The boring answer is usually the right one. In 2026 there is only one answer, and the useful work is in moving well: early, in steps, and with the hard parts found before the deadline rather than after.

---

Still running a Connect app, or not sure what moving it involves? Get in touch for a migration assessment, or see our Atlassian development services. We build on Forge every day and will tell you plainly what moves, what needs rebuilding and what it will take.