|
| 1 | +--- |
| 2 | +title: Airgapped deployment architecture |
| 3 | +sidebarTitle: Overview |
| 4 | +--- |
| 5 | + |
| 6 | +This document explains Plane's architecture and specific requirements for airgapped deployments. Review this before beginning your airgapped installation on [Docker](/self-hosting/methods/airgapped-edition) or [Kubernetes](/self-hosting/methods/airgapped-edition-kubernetes). |
| 7 | + |
| 8 | +## What is an airgapped deployment? |
| 9 | + |
| 10 | +An airgapped deployment operates in a completely isolated network environment with no external internet connectivity. This isolation is common in highly regulated industries, government facilities, and organizations with strict security requirements. |
| 11 | + |
| 12 | +Plane supports fully airgapped deployments where all components—application services, databases, storage, and integrations—operate entirely within your isolated network perimeter. |
| 13 | + |
| 14 | +## Plane architecture overview |
| 15 | + |
| 16 | +Plane consists of multiple services working together to provide project management capabilities. |
| 17 | + |
| 18 | + |
| 19 | + |
| 20 | +### Frontend services |
| 21 | + |
| 22 | +**Web** |
| 23 | +The main application interface where users interact with projects, work items, and pages. This service serves the React-based UI and handles client-side routing. |
| 24 | + |
| 25 | +**Space** |
| 26 | +Public project spaces that can be shared externally. This allows teams to publish project information without requiring authentication. |
| 27 | + |
| 28 | +**Admin** |
| 29 | +Instance administration interface for workspace owners and administrators. Manages billing, licensing, workspace settings, and user permissions. |
| 30 | + |
| 31 | +### API server |
| 32 | + |
| 33 | +**API** |
| 34 | +The core REST API that handles all data operations. All frontend services communicate with this API for creating, reading, updating, and deleting data. |
| 35 | + |
| 36 | +**Worker** |
| 37 | +Background job processor that handles async operations like file processing, notification dispatch, and data imports. Workers pull jobs from RabbitMQ and execute them independently. |
| 38 | + |
| 39 | +**Beat worker** |
| 40 | +Scheduled task executor that runs periodic jobs like data cleanup, report generation, and reminder notifications. Uses a cron-like scheduling system. |
| 41 | + |
| 42 | +**Migrator** |
| 43 | +Database schema management service that runs on deployment to apply schema changes and data migrations. Runs once during upgrades then exits. |
| 44 | + |
| 45 | +### Supporting services |
| 46 | + |
| 47 | +**Live** |
| 48 | +Real-time collaboration service powered by WebSockets. Handles cursor positions, live updates, and presence indicators for multiple users working simultaneously. |
| 49 | + |
| 50 | +**Silo** |
| 51 | +Integration backend that manages connections to GitHub, GitLab, and Slack. Handles OAuth flows, webhook processing, and API communication with external systems. |
| 52 | + |
| 53 | +**Intake** |
| 54 | +Email ingestion service that converts incoming emails into work items or comments. Requires SMTP configuration and DNS setup. |
| 55 | + |
| 56 | +### Infrastructure dependencies |
| 57 | + |
| 58 | +**PostgreSQL** |
| 59 | +Primary relational database storing all application data including projects, work items, users, and configuration. Plane requires PostgreSQL 15.7+ or 16.x. |
| 60 | + |
| 61 | +**Redis/Valkey** |
| 62 | +In-memory cache and session store. Used for caching frequently accessed data, storing user sessions, and managing real-time collaboration state. |
| 63 | + |
| 64 | +**RabbitMQ** |
| 65 | +Message queue for asynchronous task processing. Workers pull jobs from queues for background operations like imports, exports, and notifications. |
| 66 | + |
| 67 | +**MinIO/S3** |
| 68 | +Object storage for file uploads, attachments, and generated exports. Can be replaced with any S3-compatible storage system. |
| 69 | + |
| 70 | +**OpenSearch** |
| 71 | +Optional search indexing service for enhanced search capabilities. Not required for basic Plane functionality. |
| 72 | + |
| 73 | +## Airgapped cluster architecture |
| 74 | + |
| 75 | +Here's how Plane operates in an airgapped environment with internal enterprise applications: |
| 76 | + |
| 77 | + |
| 78 | + |
| 79 | +This diagram illustrates a critical principle: **all OAuth flows and API communication remain internal to the airgapped cluster**. When integrating with self-hosted GitHub Enterprise, GitLab, or other internal services, the entire authentication and data exchange happens within your isolated network — no internet access required. |
| 80 | + |
| 81 | +## Connectivity and telemetry |
| 82 | + |
| 83 | +**Critical guarantees for airgapped environments** |
| 84 | + |
| 85 | +- **No telemetry** |
| 86 | +Plane does not send application data, usage metrics, or telemetry outside the cluster. No analytics, crash reports, or usage statistics leave your network. |
| 87 | + |
| 88 | +- **Offline licensing** |
| 89 | +License validation happens through uploaded license files downloaded from the Prime portal. No internet connection required after initial license file transfer. |
| 90 | + |
| 91 | +- **Zero external dependencies** |
| 92 | +After initial image import, no external network connectivity is required for Plane to operate. All features work entirely within your isolated environment. |
| 93 | + |
| 94 | +- **Internal-only communication** |
| 95 | +All service-to-service communication stays within your cluster. Services never attempt to reach external APIs, CDNs, or third-party services. |
| 96 | + |
| 97 | +### How integrations stay internal |
| 98 | + |
| 99 | +The airgapped cluster diagram above shows the complete data flow. Key points: |
| 100 | + |
| 101 | +- **OAuth providers** - Your internal GitHub Enterprise or GitLab instance acts as the OAuth provider |
| 102 | +- **Authorization endpoints** - All OAuth URLs point to internal systems, never external SaaS services |
| 103 | +- **API communication** - Plane makes API calls only to your internal instances |
| 104 | +- **Webhook delivery** - Internal systems send webhooks to Plane's internal endpoints |
| 105 | +- **No SaaS fallback** - Plane never attempts to reach github.com, gitlab.com, or slack.com APIs |
| 106 | + |
| 107 | +This architecture ensures complete network isolation while maintaining full integration functionality. |
| 108 | + |
| 109 | +--- |
| 110 | + |
| 111 | +## Kubernetes-specific requirements |
| 112 | + |
| 113 | +### Base environment |
| 114 | + |
| 115 | +Deploying airgapped Plane via Kubernetes requires preparing all dependencies to operate without any external network access. |
| 116 | + |
| 117 | +#### Container images and artifacts |
| 118 | + |
| 119 | +- Maintain an internal OCI or container registry to host all Plane service images |
| 120 | +- Prepare a controlled process to pull, verify, and mirror Plane container images and Helm charts from an online staging environment into the airgapped registry |
| 121 | + |
| 122 | +#### Kubernetes environment |
| 123 | + |
| 124 | +**Supported versions:** Kubernetes 1.31 – 1.33 |
| 125 | + |
| 126 | +**Required components:** |
| 127 | +- IngressClass configured |
| 128 | +- StorageClass available |
| 129 | +- cert-manager configured with an internal CA |
| 130 | + |
| 131 | +**Node requirements:** |
| 132 | +- Ensure node OS dependencies and container runtime packages are available from mirrored package repositories like apt, yum, or offline bundles |
| 133 | + |
| 134 | +### Scaling |
| 135 | + |
| 136 | +Horizontal scaling is handled via replica counts configurable in `values.yaml`. |
| 137 | + |
| 138 | +Plane avoids using StatefulSets where possible due to the complexity of scaling stateful workloads in Kubernetes. The `monitor` service uses a StatefulSet. |
| 139 | + |
| 140 | +**For airgapped clusters:** |
| 141 | +- Ensure metrics-server images are mirrored if using HPA |
| 142 | +- If using node autoscaling, ensure node images are pre-loaded and registries accessible on bootstrap |
| 143 | + |
| 144 | +### Secrets management |
| 145 | + |
| 146 | +Plane supports using existing external secret stores, provided they are reachable within the airgapped environment: |
| 147 | + |
| 148 | +- AWS Secrets Manager for private VPC with no internet |
| 149 | +- HashiCorp Vault |
| 150 | +- Self-hosted Bitwarden |
| 151 | +- Kubernetes Secrets |
| 152 | +- SOPS, sealed-secrets, if preferred |
| 153 | + |
| 154 | +### Additional considerations |
| 155 | + |
| 156 | +- Ensure all secret providers can function without external network access |
| 157 | +- cert-manager must use an internal certificate authority |
| 158 | +- Keys and secret rotation policies should be part of the airgap operational procedures |
0 commit comments