Skip to content

Commit fb8b23f

Browse files
committed
New flow for Airgapped Kubernetes installation and added an Overview page
1 parent b3f2961 commit fb8b23f

File tree

8 files changed

+672
-130
lines changed

8 files changed

+672
-130
lines changed
35.3 KB
Loading
65.2 KB
Loading
31.3 KB
Loading

mint.json

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -83,8 +83,10 @@
8383
{
8484
"group": "Airgapped Edition",
8585
"pages": [
86+
"self-hosting/methods/airgapped-considerations",
8687
"self-hosting/methods/airgapped-edition",
87-
"self-hosting/methods/airgapped-edition-kubernetes"
88+
"self-hosting/methods/airgapped-edition-kubernetes",
89+
"self-hosting/methods/clone-docker-images"
8890
]
8991
},
9092
{
Lines changed: 158 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,158 @@
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+
![Plane architecture](/images/airgapped/plane-architecture.webp)
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+
![Airgapped cluster architecture](/images/airgapped/airgapped-cluster.webp)
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

Comments
 (0)