The complete guide to air-gapped project management

A product can support air-gapped deployment and still leave an enterprise team with a long list of unanswered questions. What matters is how the environment behaves after deployment, when updates need to be applied, identities change, integrations fail, infrastructure needs recovery, and security asks for evidence.

This guide looks at Plane Airgapped from that point of view. It is written for teams evaluating whether the deployment can hold up under the operating conditions they actually have.

What does a Plane Airgapped deployment actually look like?

Plane's Airgapped Edition runs in an isolated network environment with no external internet connectivity. Application services, databases, storage, and supported internal integrations can operate entirely within that network.

Once the required images have been imported:

• Plane does not require external network connectivity to operate
• Application data stays within the environment
• Analytics, crash reports, usage metrics, and telemetry do not leave the cluster
• Service-to-service communication remains internal

Airgapped Edition is available exclusively to Enterprise Grid customers with a minimum commitment of 100 seats. Sales can also discuss trials and exceptions to the seat requirement.

The deployment boundary extends beyond the Plane application. It includes Plane's infrastructure dependencies and the enterprise services that need to remain available inside the isolated environment.

Inside the environment

A production deployment can include:

• Plane services: The application, API, background workers, and supporting services
• Database: PostgreSQL for application data
• Cache and session state: Redis or Valkey
• Message queue: RabbitMQ for asynchronous processing
• Object storage: MinIO or another S3-compatible storage system for files and attachments
• Search: OpenSearch when advanced search or Plane AI is enabled
• Identity: Internally reachable authentication and directory infrastructure
• Integrations: Internal source-control systems and other approved endpoints
• Operations: Logging, monitoring, and backup systems
• AI infrastructure: Locally reachable model infrastructure when Plane AI is enabled

PostgreSQL, Redis or Valkey, RabbitMQ, and S3-compatible object storage are core infrastructure dependencies. OpenSearch is optional for basic Plane functionality and is required when advanced search or Plane AI is enabled.

Across the boundary

A disconnected environment still needs a controlled way to bring approved software and supporting artifacts into the network.

Plane-related artifacts can include:

• Plane container images
• Helm charts or Docker configuration
• Plane license files
• Release artifacts and security fixes

The surrounding environment may also need:

• Operating-system or container-runtime packages
• Vulnerability-scanner signatures or other security-tooling data
• Certificates or trust material required by the organization's PKI process
• Model artifacts when locally hosted AI models are used

For Kubernetes deployments, Plane images and Helm charts can be pulled in a connected staging environment, verified, and mirrored into an internal registry. Once the required artifacts are available inside the isolated environment, production does not need direct access to public registries or Plane's release infrastructure.

The NIST CSRC glossary includes a strict definition of an air gap, sourced to CNSSI 4009-2022, where systems have no physical connection and logical transfer across the interface is performed manually under human control.

Organizations may also use the term for disconnected or zero-egress environments. The surrounding network and transfer architecture ultimately determine whether the complete deployment meets a stricter physical air-gap requirement.

What can teams do with Plane inside the air gap?

Once Plane is deployed inside the approved boundary, teams can continue to use its core work management and collaboration capabilities without moving project data outside the environment.

Teams can:

• Plan and track work across Projects, Work Items, Cycles, and Modules
• Document knowledge using Pages and Wiki
• Control access through Workspace and Project roles, custom roles, and Granular Access Control
• Monitor work and activity through Dashboards and Audit logs
• Use Plane AI with approved model infrastructure hosted inside the environment

The exact setup depends on the features the organization enables and the supporting services available inside the network, but the working environment remains centered on the same Plane system teams use to plan, execute, document, and govern their work.

What infrastructure does your team need to run Plane in an airgapped environment?

An airgapped deployment keeps Plane and its data within customer-operated infrastructure, which brings the surrounding deployment stack under the customer's operational responsibility.

Airgapped Edition supports both Docker and Kubernetes. In either case, the application and its stateful dependencies need to remain available inside the isolated environment.

For Kubernetes deployments, the environment also needs:

• An internal OCI or container registry for Plane images
• A configured IngressClass
• An available StorageClass
• Cert-manager configured with an internal certificate authority
• Mirrored node operating-system dependencies and container-runtime packages when public repositories are unavailable

The required Plane and infrastructure images also need to remain reachable during scaling, node replacement, and bootstrap. If the cluster uses HPA, the metrics-server images need to be mirrored as well. Node autoscaling also requires new nodes to have access to the internal registry or the necessary images to be preloaded.

Network and security infrastructure

Several supporting services need to function entirely inside the approved network boundary.

• DNS and time synchronization: Internal name resolution and reliable time synchronization support authentication, certificates, logging, and distributed services.
• Certificates and PKI: Kubernetes deployments using cert-manager require an internal certificate authority. Certificate issuance, renewal, trust distribution, and rotation become part of the operating procedure.
• Secrets management: Supported options include HashiCorp Vault, self-hosted Bitwarden, Kubernetes Secrets, SOPS, sealed-secrets, and AWS Secrets Manager in a private VPC without internet access. The selected secret provider must remain reachable from the airgapped environment.

Operational infrastructure

The infrastructure team also needs processes for monitoring and alerting, log collection, SIEM ingestion, vulnerability scanning, backups, restore testing, capacity monitoring, registry management, certificate renewal, and secret rotation.

For Kubernetes deployments using the plane-enterprise Helm chart version 3.3.0 or later, Plane includes built-in OpenTelemetry instrumentation. It is disabled by default and requires an OTLP endpoint that Plane's workloads can reach when enabled, typically an OpenTelemetry Collector. Optional browser tracing also requires an OTLP/HTTP endpoint reachable from users' browsers.

The infrastructure review should therefore cover the complete operating environment, including how every required service is deployed, monitored, updated, recovered, and kept reachable without introducing a network path that conflicts with the approved isolation model.

How do identity, integrations, and AI work with Plane Airgapped?

Identity, source control, automation, and AI all introduce their own communication paths. In an Airgapped deployment, each path needs to fit within the approved network boundary.

Identity and access

Plane supports SAML and OIDC SSO. Enterprise Grid adds LDAP authentication, IdP Group Sync, SCIM, and Granular Access Control (GAC). LDAP can connect Plane to directories such as Active Directory, OpenLDAP, FreeIPA, and other LDAP-compatible systems.

For an Airgapped deployment, the identity architecture should account for:

• Where the SAML, OIDC, or LDAP service runs
• Which authentication endpoints Plane needs to reach
• How identity-provider certificates and keys are rotated
• How users are provisioned and deprovisioned
• Where MFA is enforced
• How privileged access is reviewed
• How group membership changes affect access

IdP Group Sync can connect identity-provider groups to Workspace roles, Project access and roles, and private Wiki collection access. Membership changes can then update access through the configured identity provider instead of relying entirely on manual administration.

Granular Access Control lets Enterprise Grid teams create custom roles from reusable permission schemes. SCIM supports automated user provisioning and deprovisioning. In a disconnected environment, the SCIM provisioning path also needs to operate within the approved network architecture.

Which integrations can stay inside?

Airgapped deployments support internal integration with GitHub Enterprise Server and GitLab Self-managed. When those systems are hosted inside the same approved network, OAuth flows, API calls, and webhook delivery can remain within the environment.

The same architecture can support:

• REST API communication between internal systems
• Internal webhooks
• Internal SMTP
• Internally hosted automation services
• Internally hosted observability systems

Integrations that depend on public SaaS endpoints require external connectivity. GitHub.com, public Slack, hosted monitoring platforms, and external APIs therefore do not fit a fully disconnected production environment unless the network model itself changes.

Teams should identify these dependencies before migration. Workflows built around public SaaS may need an internal replacement or may need to be disabled in the Airgapped deployment.

What about MCP?

Plane's MCP server supports the stdio transport for self-hosted instances. A local configuration can run:

uvx plane-mcp-server stdio

For a self-hosted Plane instance, PLANE_BASE_URL should point to the internal Plane API URL, for example:

https://plane.example.com/api

If PLANE_BASE_URL is left unset, it defaults to https://api.plane.so, which cannot serve a fully disconnected deployment.

The MCP package, uv or uvx runtime, and any other required software dependencies therefore need to be available inside the approved software supply chain before the MCP server is used.

Can Plane AI run inside the air gap?

Plane AI can connect to OpenAI-compatible model endpoints, including locally hosted models served through runtimes such as Ollama. Keeping model inference inside the air gap also requires the rest of the Plane AI stack to run within the environment.

That includes:

• The model-serving runtime
• Required model and embedding artifacts
• A dedicated Plane AI database
• OpenSearch
• Read access to the primary Plane database
• Compute for the selected models and AI services
• A process for bringing model updates into the environment

AI features that depend on external AI providers are unavailable by default in Airgapped deployments. A fully disconnected deployment therefore uses model endpoints and supporting services available within its approved network boundary.

For a deeper look at the architecture and governance considerations, see our guide to running AI agents in self-hosted project management.

How do licensing, installation, and updates work with Plane Airgapped?

Airgapped deployments use a controlled import process for licensing, installation, and updates. The production environment can remain disconnected while approved release artifacts move through the organization's software supply chain.

Plane uses offline license activation

Airgapped Edition uses a version-specific license file rather than online license validation.

For Enterprise Grid, an administrator:

1. Downloads the license file for the required Plane version from the Prime portal on a connected system.
2. Transfers the file into the airgapped environment through the approved transfer process.
3. Signs in to the Plane instance through God Mode.
4. Opens Billing and uploads the license file to activate the instance.

Licensing should also be included in the deployment's operating procedures, including renewal, expiry, seat changes, backup and recovery scenarios, and version upgrades.

Updates follow an offline transfer path

The exact update steps depend on whether Plane runs on Docker or Kubernetes.

For Docker:

1. Pull the target Plane images on a connected machine and copy them to the internal registry.
2. Download the updated docker-compose.yml and environment template.
3. Transfer the configuration files into the airgapped environment.
4. Bring existing configuration values into the new environment template.
5. Download and transfer the license file for the target Plane version.
6. Restart Plane with the updated images and configuration.
7. Check the running Plane version after the upgrade.

For Kubernetes:

1. Pull the target Plane images and copy them to the internal registry.
2. Download the target Plane Enterprise Helm chart on a connected machine.
3. Transfer the chart into the environment.
4. Bring the existing configuration into the new chart values and update planeVersion to the target release.
5. Redeploy the Helm release.
6. Check the running Plane version after the upgrade.

This keeps the production environment independent of public registries during the upgrade itself.

Add the organization's security controls around the update path

Plane's update process covers how release artifacts reach and update the deployment. The organization can place its own software supply-chain controls around that process, such as:

1. Release review
2. Artifact integrity checks
3. Image or package scanning
4. SBOM review, where available
5. Change approval
6. Controlled transfer
7. Staging validation
8. Production deployment
9. Post-deployment health checks
10. Rollback preparation

The transfer mechanism depends on the environment's security policy. Organizations may use approved removable media, transfer stations, one-way mechanisms, or cross-domain solutions based on the controls governing the system.

Plan for critical patches before they are needed

Airgapped updates add transfer and approval steps between a released fix and the production environment. The patch process should therefore define:

• How security teams receive notice of critical Plane vulnerabilities
• Which Plane version the organization will move to
• How quickly updated artifacts can reach the connected acquisition environment
• Which scanning and approval steps apply to emergency changes
• How artifacts cross the controlled boundary
• How the team will recover if an update causes a regression

For self-hosted and Airgapped deployments, the customer is responsible for applying updates and patches supplied by Plane. A workable emergency update path therefore needs to be part of the operating model before production rollout.

What does Plane provide, and what does your team own?

Airgapped Edition runs on customer-operated infrastructure. Plane provides the software, supported deployment paths, and product support, while the customer owns the surrounding infrastructure, backups, updates, security, and availability of the environment.

High availability needs particular attention

Plane Commercial Edition uses a single-region HA model on Kubernetes. The architecture is designed to keep Plane serving traffic through the loss of a node or availability zone, rather than provide active-active operation across independent regions.

Plane's stateless workloads can run across multiple nodes and availability zones, while stateful services require their own resilience strategy. The PostgreSQL, Redis, RabbitMQ, OpenSearch, and MinIO services that can run inside the Helm chart are single-replica services and are not highly available.

For an HA deployment, the infrastructure team therefore needs to address two layers:

• Plane workloads: distribute the required application services across nodes and availability zones
• Stateful services: provide resilient PostgreSQL, Redis, RabbitMQ, object storage, and OpenSearch infrastructure appropriate to the deployment

Backup is only useful after a successful restore

The customer owns backup and recovery for Airgapped deployments. The recovery plan should cover the application data and configuration needed to restore the environment, along with the dependencies required to make that restored system usable.

The plan should define:

• Backup frequency
• Encryption and access controls
• Retention
• RPO and RTO
• Restore procedures
• Identity dependencies
• Certificate and secret recovery
• Recovery-environment readiness

A successful restore test provides stronger evidence of recoverability than the existence of backups alone.

Availability belongs to the customer-operated environment

Plane's Cloud SLA applies only to Plane Cloud. Self-hosted and Airgapped deployments run on customer infrastructure, so Plane's Cloud uptime commitments and service credits do not apply.

Availability targets for an Airgapped deployment therefore depend on the customer's architecture, redundancy, backup and recovery strategy, internal SLOs, and operational staffing.

What should your security and compliance team verify before approving Plane?

By this stage, the security review should focus on how the proposed deployment behaves inside the organization's actual network, identity, logging, support, and compliance model.

What outbound connectivity does Plane Airgapped require?

Plane Airgapped is designed to run with zero connectivity to Plane's servers. Once the required images have been imported:

• Application data remains inside the environment
• Licensing uses an offline file-based process
• Plane does not require external network connectivity to operate
• Analytics, crash reports, usage metrics, and telemetry do not leave the cluster
• Supported internal integrations can communicate with services hosted inside the approved network

During a proof of concept, firewall and DNS logs can be used to confirm that the deployed environment behaves as expected under the organization's final network policy.

Can the identity architecture work inside the boundary?

The security review should cover the complete authentication and access lifecycle:

• SAML or OIDC endpoint reachability
• LDAP or Active Directory connectivity
• MFA enforcement
• User provisioning and deprovisioning
• IdP Group Sync
• Role mapping and privileged access
• Identity certificate and key rotation
• Audit log coverage for access and administrative changes

The final identity design depends on where the organization's IdP, directory services, and provisioning systems run and how those services connect to Plane.

What happens to existing integrations?

Inventory the workflows that currently depend on external systems and classify each one:

• operates entirely inside the boundary
• can move to an internally hosted service
• can be disabled
• requires an approved external connection
• becomes unavailable in a fully disconnected environment

This is particularly important for engineering and collaboration workflows built around public SaaS. Source control, notifications, automation, monitoring, or AI can behave differently once the production network no longer has public internet access.

Where do logs and audit records go?

Application observability and security auditing should be reviewed separately.

The logging design should cover:

• Application logs
• Authentication and session activity
• Administrative events
• Role and settings changes
• API and integration activity
• Infrastructure logs
• Metrics and traces

Audit logs are available on self-hosted Plane and provide a filterable, exportable record across Workspaces and Projects. Current coverage includes sign-ins, role changes, settings changes, integration activity, sessions, and administrative surfaces. Audit records are append-only and tamper-evident.

If OpenTelemetry is enabled, its OTLP endpoint also needs to fit the isolated network design. Optional browser tracing requires an OTLP/HTTP endpoint reachable from users' browsers.

Can support work without inbound vendor access?

Airgapped support can use alternative communication channels agreed between Plane and the customer. The operating model should define how diagnostic information can leave the environment when support is required.

That process should cover:

• which logs and diagnostics can be exported
• how sensitive information is reviewed or sanitized
• how screenshots and configuration fragments are handled
• how larger diagnostic bundles cross the boundary
• how high-severity incidents are escalated
• whether issues can be reproduced in a less restricted environment

Defining this process before production gives both teams a workable support path during an incident.

What does airgapped mean for compliance?

Network isolation can support a broader security and compliance architecture by reducing external communication paths and keeping application data, infrastructure, identity, and integrations under customer control. Compliance still depends on the complete system, the data it handles, the controls implemented around it, and the assessment or authorization process that applies to the organization.

These frameworks still depend on the organization's complete system, policies, supporting infrastructure, implemented controls, and required assessment process. Plane Airgapped can support the architecture, but it does not establish compliance on its own.

How should federal teams think about FedRAMP?

FedRAMP applies to cloud computing products and services based on the federal agency's intended use. Current FedRAMP scope guidance places software delivered for installation on agency systems outside FedRAMP scope in cases where the software is not operated as a shared-responsibility cloud service.

• Plane Airgapped is customer-operated software deployed inside the customer's own environment. A federal agency therefore evaluates FedRAMP applicability based on its specific deployment and use case.
• FIPS-compliant images address a separate requirement. They support deployments that need FIPS-aligned cryptography, while FedRAMP scope and agency authorization follow their own assessment processes.

For security review, the useful question is which controls the Plane architecture can support and which controls remain part of the organization's surrounding system.

What evidence should you request from Plane during security review?

A security review should leave reviewers with enough evidence to understand the deployment boundary, software supply chain, access model, operating responsibilities, and support process.

Architecture and networking

Review the material needed to map how Plane communicates inside the environment:

• Deployment and system-boundary diagrams
• Data-flow diagrams
• Required ports and protocols
• External endpoint requirements
• DNS and certificate requirements
• Internal service dependencies
• Supported deployment methods and versions

The resulting architecture should make it clear which systems Plane communicates with, where those systems run, and which connections cross the security boundary.

Software supply chain

Review how Plane releases move from the vendor into the isolated environment:

• Release and image inventory
• Version identifiers
• Image or artifact integrity checks
• Available checksums or signatures
• SBOM availability
• Vulnerability-management process
• Release notes
• Security advisories
• Emergency patch process
• Supported-version policy

This evidence should support the organization's own scanning, approval, transfer, and change-management process before artifacts reach production.

Identity and security

Review the controls that govern access to Plane:

• SAML and OIDC architecture
• LDAP configuration
• User provisioning and deprovisioning
• IdP Group Sync
• Roles and permission schemes
• Privileged-access controls
• Encryption architecture
• Secret handling
• Audit logs
• Audit export and retention requirements

The review should show how identity, authorization, and audit controls work together across the intended Airgapped deployment.

Operations and recovery

The operating model should cover:

• Installation
• Offline updates
• Rollback
• Backup and restore
• High availability
• Disaster recovery
• Monitoring and alerting
• Capacity planning
• Certificate renewal
• Secret rotation

For each area, capture who owns the process, what evidence shows that it works, and how it will be tested before production.

Commercial and support

Confirm the terms and processes that affect the deployment over its lifetime:

• Airgapped Edition commercial requirements
• Seat commitments and any applicable exceptions
• Offline license lifecycle
• Renewal and expiry behavior
• Security-response channels
• Support escalation
• Diagnostic-sharing process
• Available security assurance material

Plane currently positions Airgapped Edition under Enterprise Grid with a 100-seat minimum commitment, while smaller regulated deployments can be discussed with Sales.

A useful evidence register can capture each requirement alongside its owner, supporting artifact, applicable Plane version, review status, and any action needed before production approval.

What should block or delay approval?

Define approval criteria before the proof of concept begins. That gives security and infrastructure teams a clear way to distinguish a genuine architecture conflict from an issue that needs more evidence or a controlled design change.

Block approval when a requirement conflicts with the isolation model

The evaluation should stop if a required part of the deployment cannot satisfy a non-negotiable security requirement.

These gates should be evaluated against the final production architecture, including the integrations and optional capabilities the organization plans to enable.

Delay approval when evidence is incomplete

Some findings call for resolution before sign-off without creating an immediate architecture conflict. Examples include:

• unclear license renewal or expiry behavior
• incomplete dependency or network-flow evidence
• a required workflow that has not been validated in the disconnected environment
• unresolved Audit log, retention, or export requirements
• incomplete restore or rollback procedures
• unresolved version or compatibility requirements
• an untested support and diagnostic-sharing process

These items should remain open until the responsible team has evidence that the production design can meet the requirement.

Approve design changes explicitly

Some gaps can be resolved through an approved change to the deployment design, such as:

• disabling an optional SaaS integration
• replacing an external service with an internally hosted alternative
• removing a nonessential feature that depends on external connectivity
• approving a restricted external connection where the organization's security policy permits one

Record the resulting architecture as it will actually operate in production. If an external connection becomes part of the approved design, the deployment should be described according to that network model rather than as fully disconnected.

How should you validate Plane before production approval?

A pre-production acceptance test should reproduce the network, identity, integration, recovery, and support constraints that the production environment will enforce. Each test should have an expected result and evidence that can be reviewed before sign-off.

1. Test the network boundary

Apply the outbound firewall and DNS policies planned for production, then monitor connection attempts.

Verify that:

• Users can access Plane
• Application services remain healthy
• Files and attachments continue to work
• Required internal integrations remain operational
• No unexpected external connection attempts appear

2. Perform a cold start

Restart Plane and the infrastructure services the deployment depends on while external connectivity remains blocked.

Confirm that the environment can start using its internal images, registries, certificates, licensing, and service dependencies. For Kubernetes deployments, test node replacement or restart scenarios where they form part of the production design.

This can expose dependencies that remain hidden while an already-running environment is healthy.

3. Test the identity lifecycle

Test the complete access lifecycle:

• Authentication
• MFA, where applicable
• User provisioning
• Deprovisioning
• Role changes
• IdP Group Sync
• Privileged access
• Break-glass access, where the organization uses it

Access changes should behave according to the organization's policy under the same network conditions planned for production.

4. Test required integrations

Exercise every integration and internal workflow the production deployment will depend on, such as:

• GitHub Enterprise Server or GitLab Self-managed
• REST APIs
• Webhooks
• SMTP
• Internal automation
• Monitoring and SIEM export

Record any optional SaaS integrations that are intentionally disabled or replaced in the Airgapped design.

5. Test Plane AI under the final network policy

If Plane AI is included in the approved architecture, exercise the enabled AI capabilities with public internet access blocked.

Confirm that:

• Inference uses the configured internal model endpoint
• OpenSearch remains reachable
• The dedicated Plane AI database remains reachable
• Plane AI can read the required data from the primary Plane database
• The local model service and required model artifacts remain available
• Prompts and work data follow the approved internal data path
• AI failures do not disrupt unrelated Plane functionality

6. Exercise licensing and updates

Test the offline operating lifecycle rather than stopping at initial activation.

Cover:

• Offline license activation
• Image mirroring into the internal registry
• Transfer of Docker configuration or Helm artifacts
• Deployment of a target Plane version
• Application health after the update
• Rollback or recovery procedures defined by the organization

For Docker deployments, the update process also includes transferring the license file for the target Plane version. Renewal and expiry behavior should be understood before production sign-off.

7. Test backup and restore

Create a real backup and restore it into an approved test environment.

Confirm that:

• Plane application data is recovered
• Files and attachments are available
• Environment configuration is restored
• Required secrets and external service connections can be re-established
• The restored deployment is usable within the organization's recovery objective

For Kubernetes deployments and other installation methods, include PostgreSQL, object storage, and the configuration required to rebuild the environment in the recovery plan.

8. Test HA and DR where required

For Kubernetes deployments with high-availability requirements, simulate the failures the architecture is designed to tolerate, including relevant node or availability-zone failures.

Plane's Kubernetes HA model is single-region. Stateless workloads can be distributed across nodes and availability zones, while PostgreSQL, Redis, RabbitMQ, OpenSearch, and MinIO need their own resilient architecture for an HA deployment.

Disaster-recovery testing should then validate the customer's recovery design, including the infrastructure, data, configuration, and recovery objectives required to rebuild service after a larger failure.

9. Simulate a support incident

Run a realistic high-severity support scenario under the same security restrictions that production will enforce.

Test the process for:

• Collecting logs and diagnostics
• Reviewing and sanitizing sensitive information
• Approving material for export
• Transferring diagnostic material to Plane support
• Receiving remediation guidance
• Applying the remediation inside the isolated environment

This confirms that the support path works before an actual production incident depends on it.

A simple acceptance record can capture the final result:

Is Plane Airgapped the right fit for your environment?

Plane Airgapped is designed for organizations that need to keep project management inside a controlled network while retaining enterprise work management, identity controls, internal integrations, and approved AI infrastructure. The deciding factor is whether the organization can operate that environment reliably throughout its lifecycle.

It is a good fit when the organization can:

• Operate and recover customer-managed infrastructure
• Keep required identity, integrations, and supporting services inside the approved network
• Move software updates, license files, and other approved artifacts through a controlled transfer process
• Monitor, patch, back up, and secure the environment throughout its lifecycle
• Provide approved local model infrastructure when Plane AI is in scope

The main constraints appear when essential workflows depend on public SaaS services, internet-based updates, external AI providers, vendor-managed infrastructure, or support paths that the organization cannot permit across its network boundary.

Plane provides and supports the Airgapped software, deployment paths, offline licensing, update artifacts, and supported configurations. The customer operates the surrounding infrastructure and remains responsible for its availability, backups, application of supplied updates and patches, and environment security. Plane Cloud uptime commitments and service credits apply to Plane Cloud rather than customer-operated Airgapped deployments.

Before moving to a proof of concept, the evaluation team should be able to answer five questions:

1. Can Plane and every required dependency operate inside the approved boundary?
2. Can the infrastructure team operate the surrounding services throughout the deployment lifecycle?
3. Can required workflows run without prohibited external dependencies?
4. Does the security review have the technical evidence it needs?
5. Are the ownership and operational requirements acceptable for the organization?

A technical evaluation should then test the target production architecture itself, including the network boundary, identity model, required integrations, recovery design, update path, and the Plane capabilities the organization plans to enable.

Bottom line

An air-gapped project management platform has to fit both the organization's security boundary and its operating model. For Plane, that means validating the full deployment lifecycle, including identity, integrations, offline licensing and updates, observability, recovery, support, and any AI capabilities the organization plans to enable.

By the end of the evaluation, security and infrastructure teams should have evidence that Plane can operate within the approved network, that required workflows remain functional, and that the organization can operate and recover the environment over time.

If Plane Airgapped fits your security and infrastructure requirements, the next step is to evaluate it against your target production architecture.

Talk to Sales to review your deployment requirements, security constraints, and integration needs, or book a demo to see how Plane Airgapped would work for your organization.

FAQs

Q1. Does Plane Airgapped require internet access at runtime?

No. Once the required images and deployment artifacts are available inside the environment, Plane can operate without external network connectivity. Application data, analytics, crash reports, usage metrics, and telemetry remain inside the isolated environment. Any customer-configured integrations or supporting services also need to fit the approved network architecture.

Q2. How does Plane Airgapped licensing work?

Airgapped Edition uses offline file-based licensing. An administrator downloads the license file for the required Plane version from the Prime portal on a connected system, transfers it through the organization's approved process, then signs in to God Mode and uploads the file under Billing to activate the instance.

Q3. Can Plane use SAML, OIDC, LDAP, and Active Directory in an airgapped environment?

Yes. Plane supports SAML and OIDC SSO, while Enterprise Grid supports LDAP authentication with directories such as Active Directory and other LDAP-compatible systems. The required identity services and authentication endpoints need to be reachable within the approved network architecture.

Q4. Can GitHub Enterprise Server and GitLab Self-managed work with Plane Airgapped?

Yes. Internally hosted GitHub Enterprise Server and GitLab Self-managed can integrate with Plane inside the isolated network. OAuth flows, API communication, and webhook delivery can remain within the approved environment when both systems are internally hosted and reachable.

Q5. Can Plane AI run without external internet access?

Yes. Plane AI supports OpenAI-compatible model endpoints, including locally hosted models served through runtimes such as Ollama. A disconnected Plane AI deployment also needs OpenSearch, a dedicated Plane AI database, read access to the primary Plane database, and the required model infrastructure inside the environment.