Air-gapped / sovereign deployment guide

Air-Gapped Isn't a Feature — It's a Constraint

Most “Jira alternative” comparisons treat air-gapped as a checkbox next to on-premises. It isn't. It's a claim about whether a platform's entire performance surface — not just the parts someone remembered to test — actually works with zero outbound connectivity, on Data Center's own clock.

Mar 30, 2026
Already past
New DC sales closed
Mar 30, 2028
The real planning deadline
Existing-customer purchases close
Mar 28, 2029
Atlassian's own terminal date
Full end-of-life, read-only
Not affected
Separate hybrid license track
Bitbucket Data Center

Why This Is a Gate, Not a Preference

For most buyers leaving Jira, deployment model is a cost-and-control decision — self-managed versus a vendor's cloud, weighed against price and convenience. For a regulated, classified, or genuinely disconnected estate, it isn't a decision at all. A platform that assumes internet reachability — for licensing, for search, for identity, for updates — is disqualified by policy before a feature comparison even starts. The question this page answers isn't “which tool is best” — it's what has to be true of any tool before that question is even worth asking.

What “Air-Gapped” Actually Requires

Four things have to hold, and a feature checklist checks none of them. Verifying these against any platform — GForge included — takes longer than reading a comparison table, and that's the point: this is a boundary to test, not a box to tick.

Zero outbound connectivity, not just a firewall rule

Search indexing, license checks, telemetry, crash reporting, and update checks all have to run with no external call succeeding — ever, not just when the network happens to be down. A platform that degrades gracefully without internet access is not the same as one built to never expect it.

No vendor-held encryption keys

If the platform vendor can decrypt your content from outside your network — for support, for recovery, for anything — the estate isn't air-gapped no matter where the servers physically sit. Key custody has to stay inside the boundary, full stop.

Identity resolved entirely on-prem

Authentication against a local LDAP or SAML provider, with no callout to a cloud identity service as a fallback path. A login flow that silently reaches outside the network the moment the local IdP has a bad day is a hole in the boundary, not an outage.

Offline software updates and licensing

License files and patches delivered as artifacts an admin carries across the boundary by hand — not an activation flow that phones home, and not a licensing model that assumes periodic internet contact to stay valid.

The Clock Doesn't Care Whether You're Connected

Atlassian's own wind-down of Data Center runs on three dates, regardless of a customer's network posture: March 30, 2026, when new Data Center sales and self-service trials stopped; March 30, 2028, when existing customers lose the ability to purchase, renew, or expand impacted products; and March 28, 2029, when those licenses expire and go read-only. An air-gapped estate does not get a longer runway because it's harder to migrate — if anything, the opposite: evaluating, procuring, and re-accrediting a replacement inside a disconnected or classified network routinely takes longer than a standard migration, which makes the 2028 date the one to plan against now, not the 2029 date most coverage leads with. Full breakdown of all three dates and what each one actually closes off →

The One Exception Worth Getting Right

Bitbucket Data Center is explicitly excluded from this end-of-life plan and continues under a separate Bitbucket Hybrid License offering, with no published end date. An estate running Jira, Confluence, and Bitbucket together on Data Center is not on one uniform clock — treating all three as equally at risk is the single most common factual error in this space, and getting it wrong in front of a security or procurement reviewer costs credibility the rest of the case can't buy back. What actually changes for Bitbucket, and what doesn't →

Air-Gapped Is Not the Same Problem as Data Residency

Choosing which region hosts your cloud tenancy and disconnecting entirely from the internet are different problems with different solutions, and it's worth being precise about which one an organization actually has. Data residency controls are a cloud feature — a setting inside a connected, vendor-run tenancy that pins data to a region, with real gaps of its own. What Atlassian's own data residency page does and doesn't cover → A genuine air-gap requirement isn't solved by picking a region — it's solved by removing the connection entirely, which no commercial cloud tenancy, regardless of region, is built to do.

An Architecture That Meets the Constraint

GForge Next runs entirely inside infrastructure you control — no vendor-held keys, no phone-home licensing, identity resolved against your own directory. It's one architecture that satisfies the requirement above, not the only one, and it's worth verifying against your own boundary rather than taking that claim on faith.

Size My Instance

Related Reading

Sources

Compiled September 2026 from Atlassian's own end-of-life documentation and community post. Re-verify dates directly at atlassian.com before relying on this page in a compliance or procurement review.