Self-hosted Jira alternative for air-gapped networks

Why air-gapped networks need a Jira alternative that runs fully offline

If your classified, OT or offline network depends on Jira Data Center, you need a replacement that installs, updates and runs without any outbound connection. Atlassian's timeline sets the pressure: new Data Center subscriptions for new customers end on March 30, 2026, licenses and expansions stop for existing customers after March 30, 2028, and on March 28, 2029 Data Center licenses expire and become read-only. For disconnected environments, the realistic self-hosted options are OpenProject, the Plane Airgapped edition and Redmine. Each can run without internet access, but each reaches an offline network differently, so the choice depends on how your team plans, tracks and reports work.

The decision starts with the update path, because an air-gapped system only gets new software when someone carries it across. OpenProject ships Docker images, .deb and .rpm packages for 64-bit Linux, and Kubernetes Helm charts, so you need to confirm which artifacts your mirror and accreditation process can accept. Plane publishes an Airgapped edition, which is proprietary and separate from the AGPL-3.0 Community Edition, so confirm its licensing terms, release cadence and how images reach you. Redmine is GPL v2 and installs from a source package, but its upgrade guide requires you to migrate the database, uploaded files and any third-party plugins, so every plugin needs a verified version for each target release.

Plan dependencies before you select a product. Each option needs PostgreSQL, and OpenProject requires version 16 or later with the pg_trgm, btree_gist and unaccent extensions. Plane needs Redis or Valkey, RabbitMQ and S3-compatible object storage, and Redmine supports PostgreSQL, MySQL, SQL Server and SQLite, though SQLite is not suited to multi-user production use. Ask each vendor for an offline dependency list, then build a test environment on an isolated network and run a full upgrade rehearsal. Also record which Jira data must come across, since OpenProject's beta Jira Migrator only supports Jira Data Center 10.x and 11.x.

What an air-gapped project tool must satisfy

A tool that runs in a disconnected enclave has to meet requirements that a cloud tool never has to meet. The cards below cover the runtime, install, update, identity and exit requirements that connect to Atlassian's Data Center timeline and to what Jira's cloud backup leaves out.

No outbound calls at runtime

Confirm the platform runs with zero egress. Check whether licensing checks, telemetry, update notices, plugin catalogs, map tiles, fonts or external avatars trigger network calls, and whether each can be disabled in configuration. Test in a network segment with outbound traffic blocked and watch for DNS and timeout errors during normal use, such as sending notifications or rendering attachments.

Offline install artifacts

Plan the install from artifacts you can carry in. OpenProject offers Docker-based installation, .deb and .rpm packages for 64-bit Linux, and Kubernetes with Helm charts. Plane documents air-gapped installs. Confirm which container images, package repositories and language dependencies must be mirrored into the enclave, and who signs and verifies each artifact before it crosses the boundary.

Controlled update transfer

Treat every upgrade as a managed import. Each update must be downloaded outside the enclave, checked against published checksums or signatures, transferred through your approved media process and tested against a copy of production data. Redmine's upgrade guide calls for backing up the database and uploaded files, copying configuration and plugins, then running migrations, so the database and plugin set must move together.

Identity inside the enclave

Sign-in must work without public identity providers. Confirm that LDAP or internally reachable SAML or OIDC endpoints serve the enclave, because hosted identity services will not resolve there. OpenProject lists LDAP group synchronization and SSO as Enterprise features, and Plane lists SAML and OIDC on Pro and above with LDAP on Enterprise. Redmine supports multiple LDAP sources in its base edition. Confirm which feature each candidate needs in writing before you pick an edition.

Data export without vendor cloud

Export must not depend on the vendor's cloud. Jira Cloud's backup covers work items, boards, sprints, comments, users, workflows and schemes, but excludes automation rules, third-party apps and Assets. Before you choose a successor, list every automation, app and Assets object your teams use, and confirm that a self-hosted export or API route covers each one. Atlassian's Data Center licenses become read-only on March 28, 2029, so run this test before that date.

Which option fits which offline environment

In a classified enclave, the first question is accreditation. Every component, including the operating system, database, object storage and application, must come from media the security authority has approved, and the reviewers need to see where each one came from and what license governs it.

OpenProject: Docker images and .deb or .rpm packages for 64-bit Linux give you material to build an approved offline bundle. Packaged installs support Ubuntu 22.04, Debian 12, RHEL 9.x and SUSE Linux Enterprise Server 15. The software is GPL-3.0, so the source is open to review.
Plane Airgapped: This edition is built for disconnected installs, but it is proprietary. The accreditation file must cover a closed-source edition under a commercial license, so confirm the license terms and what source access is possible before you plan around it.
Redmine: It is GPL v2 with no paid edition, so there is no separate vendor edition to accredit. The remaining cost sits in hosting, upgrades and maintenance. It supports PostgreSQL, MySQL 8.0 to 8.4 and SQL Server 2012 or higher.
Dependencies: OpenProject needs PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions. Plane needs PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage such as MinIO, so each one must be approved too.
Runtime: Redmine 7.0 runs on Ruby 3.2, 3.3, 3.4 or 4.0 and does not support JRuby, so the Ruby build must be approved in its own right.

Before choosing, ask your accreditor which packaging formats, language runtimes and database versions are already approved.

A disconnected general office, such as a branch, a lab or a field site without a reliable link, mainly needs a platform that installs from local media, signs users in against local directories and receives updates through a repeatable process. Here licensing and staffing usually matter more than accreditation.

OpenProject: The Community edition is free and covers work packages, Gantt charts, agile boards and time tracking. Enterprise on-premises is priced per named user per month, from 5.95 euros on Basic, and SSO and LDAP group synchronization sit in the paid plans. Check the current pricing page before budgeting.
Plane: The Community Edition is AGPL-3.0 and matches the Free tier's feature set. A paid self-hosted plan requires switching to the Commercial Edition with a license key. The Airgapped edition is a separate proprietary product, so choosing it is a separate decision.
Redmine: It includes LDAP authentication and has no paid edition, so the only recurring costs are hosting, plugin upkeep and the people who run it. Confirm which sign-in options your version needs from plugins.
Updates: Redmine's upgrade guide calls for backing up the database and uploaded files, copying configuration, uploads and plugins to the new installation, and then running db:migrate and redmine:plugins:migrate. Rehearse this on a copy before any production change.
Cost drivers: Staff time to apply updates, plugin compatibility and offline backup storage drive most recurring cost in this setting.

Ask for a dated list of the updates your office will receive, how each one arrives, and who applies it.

How OpenProject, Plane Airgapped and Redmine compare offline

This table compares the three self-hosted options on license, offline install, authentication, Jira import path and trade-offs for disconnected networks. Read each row as a checklist item to confirm with the vendor before you commit to a platform for a disconnected environment.

Criterion	OpenProject	Plane Airgapped	Redmine
License	GPL-3.0 Community edition, with paid Enterprise plans for SSO, LDAP and SCIM	Airgapped edition is proprietary, separate from the AGPL-3.0 Community edition	GPL v2, with no paid edition
Offline install method	Packaged installs or Docker images, which you must mirror into the disconnected network	Airgapped install method documented by Plane, with packaging to confirm with Plane	Source or package install on Ruby on Rails, with gems and plugins mirrored internally
SSO and LDAP inside a disconnected network	SAML, OIDC, CAS, Kerberos and LDAP group sync sit in Enterprise plans	SAML and OIDC are listed from Pro upward, LDAP from Enterprise, so confirm Airgapped licensing tiers	Built-in LDAP authentication, with SAML or OIDC usually added through plugins to confirm
Jira import path	Beta Jira Migrator for Data Center 10.x and 11.x only, not Jira Cloud	Jira importer covers Server and Data Center, and Cloud, confirm offline availability for Airgapped	No supported Jira importer; third-party scripts are neither tested nor supported, so plan CSV import
Update delivery	Releases such as 17.9.2 arrive as images or packages you must bring in through your transfer process	Update packaging and release cadence for Airgapped to confirm with Plane	Upgrade by copying config, uploads and plugins, then running database migrations
Principal trade-off	Broad feature set, but Jira migration is beta and SSO needs a paid tier	Plane workflow model with less direct Jira import support on Airgapped to confirm	Mature and free, but issue workflow and Jira migration need manual effort

How updates reach a disconnected network

Every option on this page needs a controlled transfer process for updates, because none of them can pull new images, packages or dependencies from the internet once the network is disconnected. Plan the transfer as a recurring operation with an owner, an approval step and a record of what crossed the boundary. The supplied release dates give the cadence to plan around: OpenProject 17.9.2 was published on October 15, 2026, Plane v1.4.2 on August 23, 2026, and Redmine 7.0.2 on September 30, 2026. Those dates show that minor releases arrive every few weeks, so a quarterly transfer will leave you running versions that are several releases behind. Ask each vendor how Airgapped or offline updates are delivered, whether as signed bundles, tarballs or registry exports, and how they publish release notes for offline review. The Plane GitHub releases page is the place to track its cadence.

Redmine has the most explicit support policy of the three, and it should drive your planning. The 7.0.x line receives new features, bug fixes and security updates. The 6.1.x line receives only bug fixes and security updates, and 6.0.x receives only important security updates. Lines 5.1.x and older are unsupported. Pick the line that fits your patch window, and confirm the end of support for the line you choose before you commit. Redmine's upgrade procedure also requires you to migrate plugins with redmine:plugins:migrate, so each transfer must include third-party plugin code and the Ruby gems it needs. Stage the gems for your target Ruby version (7.0 supports Ruby 3.2, 3.3, 3.4 and 4.0) in an internal mirror, and test the full upgrade on a copy of production before it reaches the disconnected network.

For OpenProject and Plane, the staged payload is container images, system packages and any database extensions. OpenProject supports Docker-based installs and .deb and .rpm packages, and it requires PostgreSQL 16 or later with the pg_trgm, btree_gist and unaccent extensions, so each transfer should include a check that these extensions are present in your offline PostgreSQL build. Plane's self-hosted stack also depends on Redis or Valkey, RabbitMQ and an S3-compatible store such as MinIO, and each of those images needs its own transfer and digest check. Record the checksum of every artifact, keep the previous version's images for rollback, and confirm with each vendor whether its Airgapped build ships a supported upgrade path between versions or requires a full reinstall.

How to deploy and operate an offline Jira alternative

This sequence takes an air-gapped Jira replacement from a proof of concept to a documented, repeatable process for bringing software, images and updates across the boundary. The result is a running platform that your team can patch, back up and restore without internet access.

Confirm the option with a proof of concept
Before any media crosses the boundary, stand up OpenProject or Plane on a staging host that matches your target network's operating system, database and identity constraints. Your platform team does this, with a security lead reviewing the results. Import a representative sample of projects, not only a trivial one, and check that workflows, permissions, attachments and any required custom fields behave as expected. Keep in mind that OpenProject's Jira Migrator is in beta and supports only Jira Data Center 10.x and 11.x, and that Plane's Jira importer is designed around Plane Cloud and the Commercial Edition, so confirm the edition and source version you will use. The step is complete when the team signs off on a written list of gaps and workarounds.
Mirror container images and packages
Decide which installation method fits the environment. OpenProject supports Docker-based installation (recommended), .deb and .rpm packages for 64-bit Linux, and Kubernetes with Helm charts. Plane documents Docker Compose, Kubernetes with Helm and other methods including Podman and air-gapped installs. On a connected staging network, pull the exact release tags you have validated, along with the images for PostgreSQL, Redis or Valkey, RabbitMQ and object storage that the chosen method requires. Verify checksums or digests against the vendor's published values, then copy them to approved removable media or a one-way transfer system. The step is complete when every image and package in the bill of materials has a recorded version, digest and transfer record.
Build an internal artifact repository
Load the mirrored images into an internal container registry, and place operating system packages and language dependencies into internal repositories that the air-gapped hosts can reach. Harbor is one self-hosted option for OCI content, and Pulp can serve multi-format packages. Your infrastructure team owns this layer, and your security team should approve the signing and scanning policy for anything that enters the repository. Include the Helm charts and the Compose files that match your validated release. The step is complete when a clean test host can install the platform using only internal sources, with no outbound name resolution or internet routes.
Install PostgreSQL and enable required extensions
OpenProject officially supports PostgreSQL 16 or later since OpenProject 16.0.0 and requires the pg_trgm, btree_gist and unaccent extensions. Install PostgreSQL 16 or later from your internal repository, create the database and role, and enable those three extensions before the first OpenProject start. Size the database host against OpenProject's sizing guide, which suggests 4 cores and 4 GB RAM for up to 200 users, 8 cores and 8 GB for about 500 users, and 16 cores and 16 GB for about 1,500 users. Your database administrator performs the work and records the configuration. The step is complete when the extensions appear in the database catalog and a test connection from the application host succeeds.
Connect internal identity and access controls
Point the platform at your internal directory before you open it to users. OpenProject lists LDAP group synchronization and single sign-on (SAML, OIDC, CAS, Kerberos, Okta) among its Enterprise features, so confirm which of these your license covers. Plane lists SAML and OIDC on Pro and above, with LDAP among its Enterprise features on self-hosted installs. Create a small set of administrator accounts, remove default credentials, and restrict administrative access to a management network. Your identity team and the security team perform this, and the output is a documented access matrix. The step is complete when a test user can sign in through the approved path and an access review confirms that only expected roles are assigned.
Rehearse the upgrade procedure with backups
Plan every update as a rehearsed change. Take a backup of the database and the uploaded files, then apply the new release to a staging copy first. For Redmine, the upgrade guide calls for backing up the database and uploaded files, copying configuration, uploads and third-party plugins into the new installation, then running db:migrate and redmine:plugins:migrate before clearing the cache and restarting. OpenProject and Plane follow their own release notes, which should be read before each change. Check the release notes for the version you are moving to, such as OpenProject 17.9.2 on October 15, 2026 or Plane v1.4.2 on August 23, 2026, and confirm the migration steps. Restores should be tested as well as backups. The step is complete when a restore to a clean host has been proven and the rollback sequence is written down.
Document the transfer workflow
Write the procedure that governs every movement of software and data across the boundary. Cover who requests a transfer, which scanning and review steps apply, how media is labeled and logged, how checksums are verified after arrival, and which internal repository receives the content. Include the security patch path, so urgent fixes can move without skipping review. Keep a register of each release, its digest and the date it entered the environment. Your security and compliance leads own the document, and the auditors or assessors you work with should be able to read it. Confirm the requirements of your own accreditation or classification regime with your authority before finalizing. The step is complete when a second operator can perform a full update from the written procedure alone.

Evidence assessors ask for under offline constraints

Independent auditors reviewing an air-gapped deployment will ask for records that show what is running, how it got there, who can reach it and whether it can be recovered. The cards below describe the artifacts to produce and keep. DeployOpen can help prepare them, but auditors and certification bodies make the assessment.

Version and support status

Record the exact OpenProject, Plane or Redmine version in production, its release date and its support window at the time of go-live. For Redmine, the support line matters: 7.0.x is the fully supported line, while 6.1.x receives only bug fixes and security updates and 6.0.x only important security fixes. Keep the upstream release notes that match each deployed version so an assessor can tie the running code to a published source.

Transfer and verification register

Every installer, container image, package and plugin brought across the air gap needs an entry: source, date, checksum, who approved the transfer and where it was scanned. Packaged OpenProject installs and Docker images, and Plane's Airgapped edition, should each be logged separately. Without this register, an assessor cannot show that the artifact inside the enclave is the one that was published.

Access control configuration

Export the configuration that defines who can sign in and what they can change. For OpenProject, that includes the Enterprise SSO and LDAP group synchronization settings if those plans are in use. For Redmine, document the LDAP authentication setup, role-based permissions per project and whether the REST API is enabled by an administrator. Keep dated snapshots, not just the current state, so access reviews can be compared over time.

Backup and restore test records

A backup that has never been restored is not evidence. Record each restore test: the backup set used, the target host, the duration observed, and the outcome of checking project data, attachments and users. Redmine's upgrade guide centers on backing up the database and uploaded files, so both must be covered. Confirm the database and object storage sets are restored to the same point in time, since Plane stores data across PostgreSQL and S3-compatible storage.

Upgrade runbooks and change records

Write a runbook for each upgrade path before the first one happens. For Redmine, the documented sequence is to back up the database and uploaded files, copy configuration, uploads and third-party plugins to the new installation, run the database and plugin migrations, clear the cache and restart. Attach the test results from a staging enclave, the approver and the rollback point. Assessors look for evidence that changes are planned and reversible, not just that they happened.

Import and export records for project data

Keep a record of every data movement into or out of the enclave: the source system, the export file, the tool used and the counts before and after. OpenProject's Jira Migrator is in beta and supports only Jira Data Center 10.x and 11.x, and its documentation advises use only in test setups, so the record should state that limitation. Note which items did not transfer, such as comments or attachments that failed, so the gap is documented rather than discovered later.

Questions about cost, effort and running Jira alternatives offline

What drives the total cost of a self-hosted Jira alternative?

Cost comes from five components: hosting, implementation, plugins, upgrades and the staff who run the system. Hosting covers servers or virtual machines inside your network, storage, database and backups. Implementation covers installation, configuration, identity integration and migration. Plugins and add-ons, upgrades and ongoing administration recur over the life of the system. Software licensing is the component that differs most between tools. Redmine is free under GPL v2 with no paid edition. OpenProject Community is free, but SSO, LDAP synchronization and SCIM sit in paid Enterprise plans. Plane's self-hosted Community Edition is AGPL-3.0, but LDAP and API-enabled audit logs are Enterprise features. Ask any vendor or implementer to price each component separately so you can compare them.

Does Redmine have a paid edition for classified or offline networks?

No. Redmine has no paid edition because the software is released under the GNU General Public License v2. The cost of a Redmine deployment therefore comes from hosting, implementation, plugins, upgrades and the people who maintain it. Your network security team should still confirm which authentication features you need. Redmine supports multiple LDAP authentication sources natively, while SAML or OIDC sign-in typically depends on plugins, so plugin selection, testing and maintenance should appear in any quote.

Which OpenProject and Plane features require a paid license?

For OpenProject, the Community edition is free and includes work packages, Gantt charts, agile boards, time tracking and dashboards. Single sign-on, LDAP group synchronization, SCIM provisioning, custom branding and the Jira Migrator sit in paid Enterprise on-premises plans, which OpenProject prices per named user per month. For Plane, the Community Edition matches the Free tier feature set. Moving to a paid plan requires switching from Community to the Commercial Edition and applying a license key. SAML and OIDC start at the Pro tier, while LDAP and API-enabled audit logs are Enterprise features. Confirm current prices and tier contents with each vendor before budgeting, since plans change.

How long does it take to deploy Jira alternatives in an air-gapped network?

Duration depends on scope rather than on the tool alone. The main variables are the number of users and projects, whether you need single sign-on and LDAP integration, how many environments you run, whether you migrate historical data, and how much of the update path must be proven inside the disconnected network. OpenProject's sizing guide ties hardware to user counts, for example 4 cores and 4 GB RAM for up to 200 users. Plane's air-gapped install and Redmine's manual upgrade procedure each add their own steps. Ask for a timeline in the written scope, with milestones for installation, integration, migration, testing and handover, rather than a single estimate.

What must our team provide before an implementation starts?

Most of the input comes from your side. Expect to provide the target hosting environment inside your network, including virtualization or Kubernetes capacity, a PostgreSQL service and S3-compatible storage for Plane, plus Linux hosts for packaged installs. Identity details for LDAP or SAML, a list of projects, users, roles and workflows to carry over, and the approved route for moving software packages, container images and plugins into the enclosed network are also needed. Name a technical owner and a business owner for acceptance. Confirm your change-control and evidence requirements early, because they shape the deliverables.

Can our own staff run an air-gapped Jira alternative after launch?

Yes, if you can assign people with the right skills and time. Running any of these tools requires Linux administration, database operations, backup and restore testing, monitoring, user and role management and a documented upgrade process. Redmine's upgrade guide describes backing up the database and files, copying configuration, uploads and plugins, then running database and plugin migrations, so plugin compatibility must be checked at each release. OpenProject and Plane publish release cycles that your team would need to track and test in an isolated environment. Decide whether your team will own these tasks fully, share them, or buy ongoing support through a retainer.

What should a fixed-scope quote include for an offline deployment?

A fixed-scope quote should be built from a written scope that DeployOpen agrees with you before work starts. It should list the platforms and editions in scope, the environments to build, the hosting and integration assumptions, identity integration, migration boundaries, hardening, backup and restore testing, documentation, handover and acceptance criteria. It should separate one-time work from recurring items such as upgrades, support and continuous testing, which are available as retainers. Ask for named exclusions, such as third-party plugins or data that cannot be exported, and a clear change process. DeployOpen does not publish a price list, so the quote follows from the written scope.

How do security patches and version updates reach an isolated network?

Updates reach a disconnected network through a controlled transfer, not an automatic download. Your team or implementer must review each release, copy the packages, container images, Helm charts or source archives into the enclosed environment, and test them in a staging copy before production. Redmine's 7.0.x line receives new features, bug fixes and security updates, while 6.1.x receives only bug fixes and security updates, so your chosen branch determines what arrives. Confirm with each vendor how security advisories are published, how far back patches are backported, and what the supported Ruby, PostgreSQL and Kubernetes versions are for each release.

When to start the move before March 2029

Start the planning now, because the Data Center timeline leaves less room than it appears. Atlassian stops new Data Center subscriptions for new customers on March 30, 2026, stops licenses and expansions for existing customers after March 30, 2028, and makes Data Center licenses read-only on March 28, 2029. For an air-gapped network, the practical deadline is the 2028 cutoff, because a site that still needs to add users or projects after that point will have no Atlassian option, and a read-only instance can still be queried but no longer changed. Any move that must happen before the lights go out also needs test migrations, accreditation or change approval time, and a rollback path, so work backward from the date you can least afford to miss.

Settle the importer limits before you pick a target. OpenProject's Jira Migrator is in beta, supports only Jira Data Center 10.x and 11.x, and is documented for test setups only, so confirm your exact Data Center version first and run a test import rather than assuming it will carry your history. Plane's Jira importer covers Jira Server and Data Center, but its availability depends on running Plane Cloud or the Commercial Edition, which an air-gapped site may not be able to use in the way it expects. Check which edition and license model fit your network before you commit. Also confirm what each importer carries, such as issue history, comments, attachments, custom fields and workflows, because the gaps decide how much rebuilding your teams will face.

Make three decisions before any data moves: the target platform, the identity model and the transfer process. The identity decision matters early because OpenProject places SSO, LDAP group synchronization and SCIM provisioning in paid Enterprise plans, and Plane places LDAP and API-enabled audit logs in its Enterprise tier, so decide which of these your offline directory needs before you build accounts. For the transfer, decide how export files cross the air gap, who approves them, and how they are checked. Ask the vendor or your own security team to confirm which update and package channels can reach the disconnected network, because the same channel will govern your upgrades after cutover.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped networks. For an offline Jira replacement, the work starts with the network rules and the update path, then covers installation, configuration and handover.

How we scope

Map which users, classification levels and OT or offline networks need project tracking, and which data may cross any boundary.
Confirm the target platform (OpenProject, Plane Airgapped or Redmine) against the required features and the importer version limits.
Agree the scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope.

How we build

Prepare offline installation media and dependencies, such as container images or packages, through your own approved transfer process.
Configure authentication, roles, backups and the database, including the PostgreSQL extensions OpenProject requires.
Test restores, upgrade steps and the import of a representative project set in a staging environment before cutover.

How we hand over

Document the installed components, versions, configuration, access model and backup and restore procedures for your operators.
Provide the update procedure for offline media, including how new releases are reviewed, transferred and applied.
Prepare the control evidence your internal reviewers and independent auditors will ask for, without issuing any attestation ourselves.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Security testing of the deployed application and its infrastructure can be scoped separately, using the same written process.
Support covers the platform in your environment, so changes to the offline update path are agreed with your team in writing.