How defense teams run project management with Plane: A complete guide

Most project management software assumes the browser can always reach the internet. Many defense programs operate under a different set of conditions.

Some teams work inside SCIFs, classified networks, isolated laboratories, or contractor-controlled enclaves where outbound connectivity is restricted or prohibited. Others work on connected networks but must control where Controlled Unclassified Information (CUI) or export-controlled technical data is stored, processed, and shared.

That rules out cloud-only project management tools. Linear has no self-hosted option. Jira Cloud runs on Atlassian's infrastructure and cannot be installed inside a customer-managed air gap. Self-hosted software also needs close evaluation. External telemetry, licensing checks, authentication services, CDNs, and update mechanisms can all create dependencies on systems outside the network.

The infrastructure constraint does not make the engineering work simpler. A defense program may coordinate hardware, software, systems engineering, integration, testing, contract deliverables, and formal reviews across a prime, several subcontractors, and a government customer. Each organization needs access to its part of the program without seeing controlled information outside its scope.

Air-gapped project management must support modern engineering workflows without depending on services outside the authorized environment. Plane's self-hosted air-gapped edition gives defense teams a way to run those workflows inside infrastructure they control.

Project management across the defense ecosystem

Defense organizations work at different speeds and levels of the supply chain, but their project management needs usually fall into these recurring use cases.

Major defense program delivery

Primes and program offices coordinate work across hardware, software, systems engineering, manufacturing, integration, suppliers, and government stakeholders. The work includes:

• Complex Work Breakdown Structures
• Formal reviews such as PDR and CDR
• Contract deliverables and supplier work packages
• Dependencies between hardware, software, and test teams
• Schedule, risk, and EVM reporting

Long-term program plans often sit in one system while engineering teams manage weekly execution somewhere else. Plane connects Initiatives, Projects, Cycles, Work Items, and dependencies so program leaders can follow delivery without asking teams to maintain a separate status record.

Defense software and DevSecOps delivery

Software teams build, test, and release inside restricted or air-gapped environments without relying on public SaaS infrastructure. The work includes:

• Short development Cycles and release planning
• Feature, defect, and security-remediation tracking
• Code review and integration testing
• Embedded software and hardware coordination
• Release readiness and field validation

Plane supports Cycles, Modules, release-focused Projects, and workflows that connect development with testing and remediation. Teams can keep the pace of a modern software workflow while running Plane and approved supporting services inside customer-controlled infrastructure.

Research, prototypes, and technology maturation

Government laboratories, military R&D teams, and industry partners manage work that changes as the research develops. The work includes:

• Experiments and technical findings
• Prototype baselines and design changes
• Technology Readiness Level tracking
• Research risks and test campaigns
• Work shared across government, academic, and industry partners

A fixed product backlog can impose structure before the team knows what the prototype will become. Plane lets teams create Work Item Types and properties for experiments, findings, TRLs, sponsors, and review status. Pages and Wiki retain the research context, while Project access controls separate work with different partners or data restrictions.

Supplier and subcontractor delivery

Subcontractors and component manufacturers manage engineering work for one or more primes while protecting internal intellectual property. The work includes:

• Component and subsystem engineering
• Manufacturing, qualification, and acceptance
• CDRLs and engineering change proposals
• Corrective actions and delivery evidence
• Schedule and risk reporting to the prime

Separate Projects and granular access controls help isolate work by customer, contract, or subsystem. Custom Work Item Types, approval workflows, dependencies, Dashboards, APIs, and exports provide the status a prime needs without exposing unrelated supplier work.

Across these use cases, the requirement is the same: coordinate complex programs without moving sensitive data outside the approved environment. The project management system must support different delivery models while preserving access boundaries, traceability, and program-level visibility.

Defense subcontractors and component manufacturers

Subcontractors and component manufacturers manage engineering work for one or more primes while protecting their internal intellectual property. The work includes:

• Component and subsystem engineering
• Manufacturing, qualification, and acceptance
• CDRLs and engineering change proposals
• Corrective actions and delivery evidence
• Schedule and risk reporting to the prime

Separate Projects and granular access controls help isolate work by customer, contract, or subsystem. Custom Work Item Types, approval workflows, dependencies, Dashboards, APIs, and exports give the prime the status it needs without exposing unrelated supplier work.

Across these use cases, the requirement is the same: coordinate complex programs without moving sensitive data outside the approved environment. The project management system must support different delivery models while preserving access boundaries, traceability, and program-level visibility.

See how Plane fits your part of the program at plane.so/industries/defense.

Executing program delivery and workflows in Plane

Plane provides several levels for organizing and managing defense work. The right setup depends on the program, deployment boundary, and access model.

Structuring defense organizations and work streams

Teamspaces group related Projects under a division, engineering function, or program office. Projects can represent subsystems, contract work packages, internal teams, suppliers, or defined delivery outcomes.

Initiatives connect related Projects and give program leaders a broader view of progress. A large program might use:

• A Teamspace for the program or engineering division
• Projects for avionics, radar, embedded software, test infrastructure, and integration
• An Initiative connecting the Projects that contribute to a major program outcome

Separate Projects can also help restrict supplier access. A subcontractor can work in the Project assigned to its deliverables without being added to unrelated program work.

Project separation is only one part of access control. Administrators must still configure roles, memberships, sharing rules, and identity groups according to the program's authorization model.

Executing core engineering tasks and system decomposition

Work Items are the base unit of execution in Plane. Teams can use them for requirements-derived tasks, defects, test activities, risks, change requests, findings, and contract deliverables.

Parent and sub-work-item relationships help teams break larger efforts into work owned by different disciplines. A subsystem change might contain separate Work Items for:

• Systems engineering analysis
• Hardware design
• Embedded software changes
• Interface updates
• Integration testing
• Verification evidence
• Formal review

Relations and dependencies show where one activity blocks or affects another. Teams can see when software is waiting for hardware, a test is waiting for an environment, or a deliverable cannot proceed until another group approves a change.

Plane maintains traceability around the execution of the work. Formal requirements, product configurations, source code, test evidence, and controlled records may still belong in dedicated requirements, PLM, source-control, or evidence-management systems.

Defense programs manage objects that carry more structure than a generic Task. Examples include:

• Contract Data Requirements List items
• Engineering change proposals
• Plans of action and milestones
• Security findings
• Corrective actions
• Test activities
• Risks
• Approval requests

Custom Work Item Types let teams represent these as distinct kinds of work. Each type can carry the properties and workflow relevant to it.

A CDRL item might include a contract reference, responsible organization, submission date, review status, and approving authority. An engineering change proposal might include the affected baseline, technical impact, review board, and disposition.

Bridging macro milestones with iterative sprints

Software teams may plan work in short iterations while the wider program works toward reviews and delivery events that are months or years away. Cycles and Modules give teams that short-term rhythm. Projects and Initiatives carry the structure it plugs into.

Cycles organize work within a defined delivery period. Modules group Work Items by component or subsystem within a Project, independent of any single Cycle.

A Cycle is scoped to the Project it belongs to, so a software team can manage its current Cycle without separating its work from the subsystem Project it supports. When that Project rolls up into a program Initiative, progress moves with it automatically, and program leaders can follow execution at the Initiative level without asking the team to maintain a second reporting system.

Dependencies also make schedule risks easier to spot. A delayed hardware interface, unavailable test environment, or unresolved change request can be linked to the software and integration work it affects.

Unifying technical and executive visibility

Engineers, program managers, and leadership need different views of the same work, not a copy of it that's already gone stale by the time it reaches leadership.

Dashboards give program leaders that shared view. They pull from the same Work Item and Project data teams update during execution, reporting on open work, state distribution, ownership, priorities, Cycle progress, and overdue items, without anyone rebuilding the report in a spreadsheet.

Individual contributors get to that same data through layouts:

• Board views for active workflow
• List and Table views for detailed review and bulk updates
• Calendar views for date-based work
• Timeline views for schedules and dependencies
• Saved Views for recurring filters

An engineer might save a view of assigned Work Items that are ready to begin. A systems lead might track blocked integration work. A program manager might review high-priority items across several Projects. Whichever layout someone works in, it reads the same data Dashboards roll up, so nothing has to be entered twice to reach both audiences.

Centralizing classified knowledge and technical specs

Pages keep project-specific documentation close to the work. Teams can use them for meeting notes, design discussions, review preparation, interface notes, and working procedures, then connect that context with the relevant Work Items.

Wiki provides a broader knowledge base for information that applies across the organization, such as standard operating procedures, engineering guidance, security policies, onboarding material, and shared program terminology. Pages support documentation around individual Projects, while Wiki maintains an org-wide knowledge base.

For sensitive content that does belong in Plane, Private Pages restrict visibility to only the people who need it. Classified or export-controlled information should still only go there when the Plane deployment is accredited for that information and program policy explicitly permits it.

Data-handling note: An air-gapped deployment controls where Plane runs. The organization must still decide what information users may enter into it.

Automating compliance-driven defense deliverables

A CDRL should not follow the same workflow as a routine engineering task. Neither should an engineering change proposal, POA&M, or corrective action. In Plane, teams can give each one its own Work Item Type, properties, owners, due dates, and review path.

Workflows and approval steps control who reviews the item and when it can move forward. A CDRL might pass through Draft, Internal Review, Customer Review, Accepted, and Rework Required. An engineering change proposal can require technical, configuration, and program approval before implementation. A POA&M can carry its severity, owner, remediation date, supporting evidence, and verification status through closure.

Driving data-based governance and enterprise reporting

Program reporting often becomes a separate workstream. Engineers update the tracker, program managers copy the data into spreadsheets, and leadership reviews a snapshot that may already be out of date.

Plane Dashboards use the same Work Item and Project data that teams update during execution. Program leaders can review status, ownership, blocked work, priorities, overdue items, and Cycle progress without asking engineering teams to rebuild the report.

Plane's REST API and webhooks expose structured project and work data for internal integrations. Depending on the available endpoints and configuration, teams can connect Plane with engineering, reporting, or enterprise systems.

An EVM integration may map Plane data such as Work Items, Projects, Cycles, dates, status, and time records into Primavera P6, Deltek Costpoint, or another approved platform. Plane does not produce a certified EVM result simply by exposing the data. The organization must design, validate, and maintain the integration.

This separation lets engineering teams work in Plane while the program continues using its designated requirements, configuration, financial, and contract-reporting systems.

Air-gapped architecture and data sovereignty

An application does not become air-gapped because someone disconnects its internet connection. It must be able to install, run, authenticate users, load assets, store data, and receive updates without calling an external service.

Plane's self-hosted, air-gapped edition is designed for environments without outbound network access.

See the full air-gapped architecture at plane.so/airgapped, or talk to sales about your program's deployment.

Deploy Plane inside customer-controlled infrastructure

Plane can run through Docker-based or Kubernetes deployments inside a customer-managed data center, private cloud, isolated VPC, or other approved infrastructure.

The organization controls where project data, attachments, activity records, and configuration information are stored. It also decides:

• Which network or enclave hosts Plane
• Which users and devices can reach it
• How data is encrypted
• Where attachments and backups are stored
• How logs are monitored and retained
• Which internal systems can connect to Plane
• How availability and disaster recovery are managed

Plane provides the application deployment model. The customer remains responsible for accrediting and operating the surrounding environment.

Remove runtime dependencies on external services

A zero-egress deployment cannot rely on telemetry endpoints, external APIs, public CDNs, or remote licensing services for core operation.

Teams evaluating an air-gapped platform should confirm:

• Whether the application makes outbound calls at runtime
• Whether it requires an external licensing server
• Whether interface assets load from public services
• What happens when optional integrations cannot reach the internet
• Whether administrators can disable features that require external access

The evaluation should cover the complete deployment, including integrations, plugins, authentication, monitoring, and AI services.

Move updates through an offline process

A disconnected deployment cannot download updates directly from a vendor service. Infrastructure teams must transfer approved release artifacts across the boundary and apply them through the organization's change-management process.

Plane updates can be moved into the environment and made available through a local container registry. This lets infrastructure teams inspect, approve, test, and schedule each release without giving Plane an outbound connection.

The organization should define how it will:

• Verify and scan release artifacts
• Record update approvals
• Test releases outside production
• Schedule deployments
• Roll back a failed update
• Document the installed version

Air-gapped software still needs regular patching. The difference is that the organization controls how and when each update enters the environment.

Connect local identity and AI services

Plane can connect to enterprise identity systems through supported SAML, OIDC, LDAP or Active Directory, and SCIM configurations. Account management stays tied to the organization's existing access processes. When someone joins a program, changes roles, or leaves the organization, administrators can update access through the same identity system used across the rest of the environment.

Plane does not interpret security clearances on its own. The customer must translate program roles, need-to-know rules, and access decisions into identity groups and application permissions.

AI requires a similar boundary decision. A fully air-gapped deployment needs an approved model endpoint running inside the authorized environment. Prompts, project context, responses, and model logs must stay within that boundary.

The Self-hosted Commercial Edition may use an approved external model provider when the organization permits that connection.

Note: Installing Plane inside an air gap does not automatically make every integration or AI configuration suitable for that environment. Review each connection and its data flow separately.

Defense governance, compliance, and supply chain control

A defense project management deployment must fit within the program's wider governance model. Hosting the application on customer infrastructure is a starting point, not the complete control environment.

Plan beyond Jira Data Center

Jira Data Center can run on customer-managed infrastructure, including disconnected environments. Atlassian has announced that affected Data Center products will reach end of life on March 28, 2029.

Defense teams that depend on Jira Data Center will need more than a feature-equivalent replacement. They must account for offline installation and updates, identity integration, audit records, data migration, marketplace dependencies, and the ability to operate without external services.

Plane's Self-hosted Air-gapped Edition gives organizations a supported option for keeping project management inside customer-controlled infrastructure without an outbound network path.

Define the CMMC and ITAR boundary correctly

CMMC and ITAR address different concerns.

CMMC assesses whether an organization has implemented required safeguards for Federal Contract Information and Controlled Unclassified Information within a defined assessment scope. ITAR controls the export and access of defense articles, services, and related technical data.

Neither turns a project management application into a compliant environment on its own.

Plane can run inside customer-controlled infrastructure that forms part of the organization's security boundary. When deployed and configured appropriately, project data can remain inside that infrastructure.

Plane may support parts of the organization's security model through:

• Customer-controlled hosting
• Connection to local identity systems
• Role-based access
• Project-level separation
• Activity and audit records
• Customer-managed backups and retention
• Offline update procedures

The customer still owns network segmentation, encryption, endpoint security, monitoring, vulnerability management, incident response, personnel controls, physical security, backups, restoration testing, and access reviews.

Compliance boundary: Plane can run within an environment subject to CMMC or ITAR requirements. It does not certify the surrounding environment or remove the customer's responsibility for operating it correctly.

More information about Plane's security approach is available at security.plane.so.

Isolate subcontractor access

Plane can connect to the organization's identity provider and apply role-based, granular access controls within the application. Administrators can combine identity groups, Workspace membership, Project membership, and assigned roles to limit access.

A supplier access model might work like this:

• The prime owns the Workspace and program structure.
• Each supplier receives access only to the Projects relevant to its contract scope.
• Supplier users receive the minimum role required for their work.
• Program managers retain access to the Projects they oversee.
• Administrators review access when contracts, roles, or personnel change.

The customer must test this model against the program's authorization requirements. A Workspace or Project is an application boundary. It does not replace a separately accredited network or classification boundary.

Preserve local records and connect reporting systems

Activity and audit records can help admins trace changes to work. Depending on the event and deployment configuration, the available history may include state changes, assignments, comments, approvals, and other user actions.

Before relying on these records for an assessment, confirm:

• Which events Plane records
• Whether records identify the actor and timestamp
• How long records are retained
• Who can access them
• How they can be exported
• Whether they meet the program's investigation and assessment needs

Plane does not need to replace the program's requirements, PLM, source-control, test, financial, or EVM systems. It can connect the execution surrounding those systems through references, links, APIs, and webhooks.

Read more about Plane's approach to governance and access control at security.plane.so, or talk to sales about your program's specific boundary.

Conclusion

An air gap does not make a defense program simpler. Primes still run PDRs and CDRs. Subcontractors still owe CDRLs and engineering change proposals. Software teams still ship on Cycles while hardware and contract schedules run years longer. None of that goes away behind a SCIF wall or an isolated enclave. It just has to happen without a path to the internet.

That is the actual problem air-gapped project management has to solve: not making a tracker work offline, but giving a defense program the same coordination a connected team gets, without ever depending on a system outside the boundary. Plane's Self-hosted Air-gapped Edition is built for that: Work Items, Cycles, Initiatives, Dashboards, and workflows running entirely on infrastructure the customer controls, updated through an offline process the customer owns.

Plane provides the application layer. Accreditation, configuration, operations, and compliance stay with the customer, the same as they would for any infrastructure the customer runs itself.

Explore Plane Self-hosted, or talk to the Plane team about the deployment model that fits your program.

FAQs

Can Plane run without internet connectivity?

Yes. Plane's Self-hosted Air-gapped Edition is designed for environments without outbound network access. Administrators transfer and apply updates offline instead of allowing the application to download them directly.

The organization should confirm the complete deployment architecture, update procedure, and runtime behavior during technical evaluation.

Is Plane's air-gapped edition available on every plan?

No. The Air-gapped Edition is available with Enterprise Grid. Contact Plane for current licensing and deployment requirements.

Is Plane CMMC certified or ITAR compliant?

CMMC assesses an organization and its defined environment, not a project management product in isolation. ITAR is an export-control regime rather than a product certification.

Plane can run inside a customer-controlled environment, but the customer remains responsible for configuring and operating that environment according to its contractual, assessment, and export-control requirements.

Can subcontractors use Plane without seeing the prime's complete program?

Plane can separate work through Workspaces, Projects, memberships, and role-based access. A subcontractor can be limited to the Projects assigned to it.

The prime must design and test the access model against the program's authorization requirements. Application permissions do not replace network or classification boundaries.

Does Plane replace an earned value management system?

No. Plane manages project execution and exposes structured data through its API and webhooks. A program can build an integration that maps selected Plane data into its EVM or reporting system.

The organization must validate that integration and retain the approved EVM system as the authoritative source for contractual reporting.

Does Plane offer a cloud-hosted option?

Yes. Plane Cloud is managed by Plane and is how most teams run Plane. For a defense program, Plane Cloud fits the parts of the work that don't carry CUI, export-controlled data, or a network-isolation requirement. Programs typically pair Plane Cloud for unrestricted work with Plane Self-hosted Commercial or Air-gapped Edition for the parts that do.

Can Plane's AI work without an external model provider?

A fully air-gapped deployment requires an approved model endpoint inside the authorized environment. Plane Self-hosted Commercial may use an approved external provider when the organization permits that connection.

Teams should confirm supported model configurations and data flows for their Plane deployment before enabling AI.