Project management in air-gapped networks

Which requirements an air-gapped project tool must meet

This table maps each regulatory and operational requirement to what it asks of a disconnected project tool, the evidence an assessor expects, and where builds usually fall short. Read each row as a design input: the requirement sets the control, and the build must produce proof that it works across the gap.

Which project tool fits which air-gap situation

How to install and activate without internet access

Integration points and the deployment pattern inside the gap

A self-hosted project tool inside an isolated network depends on a handful of local services, each of which either stays inside the boundary or is brought across it through a controlled transfer. Map each component to its owner and its network path before you choose an edition, because the identity and storage choices decide which features you can use.

How an air-gapped project tool rollout runs

The sequence moves a project tool from a scoped edition decision to a supported, upgradable installation inside a disconnected network, with a documented output at each phase. Each step is checked before the next one starts, so the isolated environment never depends on live internet access.

1. Scope the edition and count seats

   The team confirms which platform and edition fits the requirement, whether that is OpenProject Community or Enterprise, Plane Community, Commercial or Airgapped, or a Redmine build. Owners list the named users, paid roles, required single sign-on or LDAP features and the support model, then match each one to the edition that includes it. Plane's Airgapped edition is proprietary and licensed separately from the AGPL-3.0 Community edition, so the license terms and seat counts must be settled before any download. The output is a signed scope document with the chosen edition, the license or subscription records and the seat count. Ask the vendor to confirm in writing which features the air-gapped edition includes.

2. Build the staging and transfer process

   Before anything crosses the boundary, the team sets up a connected staging network that collects the installers, container images, operating system packages, database extensions and documentation for the chosen release. Each artifact is recorded with a checksum and a source reference so the import side can verify it. The transfer path, whether removable media or a controlled data diode, is documented with its approval steps and logging. The output is a transfer manifest listing every artifact, its checksum and its approver, plus a written transfer procedure that the security team has reviewed.

3. Install offline in a test enclave

   Engineers install the platform in a test enclave that has no route to the internet, using only the transferred artifacts. For OpenProject, this means the packaged or Docker-based install with PostgreSQL 16 or later and the pg_trgm, btree_gist and unaccent extensions. For Plane, it means the air-gapped install path with its PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage services, all reachable only inside the enclave. Any step that tries to fetch a package or image from outside is a failure to fix before proceeding. The output is a running test instance, a record of every offline dependency and a list of open issues.

4. Map identity and permissions

   The team connects the test instance to the directory or identity provider that exists inside the network, such as LDAP, SAML or OIDC, and checks which options the chosen edition supports. Project roles, groups, portfolio visibility and admin rights are mapped from the source organization's model to the new platform's roles. Access reviews are scheduled with named owners so every role has a documented business justification. The output is a role matrix signed by the project management office and the identity owner, plus test logins for each role.

5. Import data from a supported source

   Where a supported importer exists for the source system and version, the team runs a test import into the enclave and compares record counts, attachments, custom fields, statuses and user assignments with the source. The Jira importer for Plane and the OpenProject Jira Migrator have specific source-version limits, and the OpenProject migrator is documented as beta and suited only to test setups, so the team confirms those limits before choosing an approach. Where no importer fits, the data is exported to a documented format and loaded by a scripted process that is reviewed. The output is a reconciliation report listing each data type, the counts on both sides and every known loss or transformation.

6. Run acceptance testing

   Business owners test the workflows that matter most: creating and tracking work items, running Gantt or agile views, time logging, reporting, notifications within the network and restoring from backup. Security staff check that logging, access controls and backups work as the scope document requires. Failures are logged with a severity, an owner and a retest date. The output is a signed acceptance record that lists each test case, its result and any accepted risks, approved by the sponsor before the cutover date is set.

7. Cut over to production

   The team freezes changes in the source system, runs the final import from the reconciled process, verifies counts again and switches users to the production instance. Backups of the source system and the new production database are taken and tested before and after the switch. Support contacts, a rollback plan and a communication to users are confirmed in advance. The output is a cutover record with timestamps, verification results, the backup identifiers and the sign-off from the system owner.

8. Document and repeat the upgrade cycle

   Each new release is treated as a repeatable transfer. The team follows the same staging, checksum and approval path, tests the upgrade in the enclave, reviews the release notes for database and configuration changes and then applies it in production with a rollback point. Vendor advisories and security updates are tracked on a set schedule, and the record of every release is kept with its checksums. The output is an upgrade runbook, a release log with checksum records for each artifact, and a named owner for the next review.

Evidence auditors and regulators ask for from an air-gapped project tool

This table maps each evidence item an assessor may request for a disconnected project tool to the component that produces it and the regulatory hook behind it. Read it as a checklist to agree with your auditor before go-live. DeployOpen prepares this evidence, but independent auditors and regulators assess it.

What to ask an implementation partner before an air-gapped project

Air-gapped project management questions buyers ask first

How upgrades cross the gap without breaking the audit trail

This sequence moves each OpenProject or Plane release across the air gap in a controlled way, so the running version, its checksum and its release date can be shown to an auditor at every change.

1. Watch vendor release notes on the connected side

   A named engineer on the connected side tracks the vendor release channels for the platform in use, such as the OpenProject release notes or the Plane releases page on GitHub. Each candidate release is logged with its version number, publication date, and the security or breaking-change notes that apply to your edition. The output is a short release register entry that says whether the release is a candidate for the next window. Confirm with the vendor which channel carries security advisories for your specific edition, since Community and Commercial or Airgapped editions can follow separate release cycles.

2. Pull and verify the release package

   The connected-side engineer downloads the container images, packages or Helm chart for the approved version and checks them against the publisher's published checksums or signatures before anything leaves the connected network. The package hashes and the verification result are written to the change record. Done means every artifact in the transfer set has a recorded hash that matches the publisher's value. If a hash does not match, the package is quarantined and the release is reported to the change board.

3. Stage the bundle in the transfer zone

   The verified artifacts are placed in the controlled transfer zone, along with the manifest listing each file, its hash and the version it belongs to. Access to the zone is limited to named staff, and the copy-in event is logged. The bundle is not opened or executed in the transfer zone. Done means the manifest and bundle can be read back and matched to the release register entry from the first step.

4. Test the upgrade in a copy of production

   The bundle is imported into an isolated copy of the production environment, including the database, object storage and configuration, and the upgrade is run exactly as it will run on the live system. Functional checks cover log-in, project and work package data, attachments, notifications and any integrations that stay inside the enclosure. The output is a test record with the starting version, the target version, the migration log and the pass or fail result for each check. Any migration error stops the change until it is resolved and retested.

5. Import into production and record the checksum

   After the test passes, the same verified bundle is imported into production through the approved media path, and the imported files are hashed again on the isolated side. The new hashes are compared with the manifest so that the deployed images match what was tested and verified. The engineer records the running version, the release date, the checksums and the time of import in the configuration management database or change log. Done means the recorded values match the staged bundle exactly.

6. Schedule the change with a documented rollback plan

   The upgrade is approved by the change board and scheduled in a maintenance window with a named owner and a named approver. The rollback plan states the database backup to restore, the previous image tags to redeploy, and the test that proves the rollback worked. Backups taken before the change are stored with their own hashes. Done means the change record links the release register entry, the test record, the checksums and the rollback plan, so an auditor can follow one upgrade from vendor release to running system.

7. Keep the version history for supplier evidence

   Each release, its publication date and its verification record are kept together as a version history for the planning platform. This history supports supply chain evidence under the NERC CIP-013-2 requirement on verifying the integrity and authenticity of vendor software and patches, which applies if the utility's program covers this tooling. Ask your compliance lead to confirm which evidence the auditor expects and how long it must be kept. The output is a dated, versioned evidence file that can be produced on request.