New flow for Airgapped Kubernetes installation and added an Overview …

mint.json

@@ -83,8 +83,10 @@
         {
           "group": "Airgapped Edition",
           "pages": [
+              "self-hosting/methods/airgapped-considerations",
               "self-hosting/methods/airgapped-edition",
-              "self-hosting/methods/airgapped-edition-kubernetes"
+              "self-hosting/methods/airgapped-edition-kubernetes",
+              "self-hosting/methods/clone-docker-images"
             ]
         },
         {

self-hosting/methods/airgapped-considerations.mdx

@@ -0,0 +1,158 @@
+---
+title: Airgapped deployment architecture
+sidebarTitle: Overview
+---
+
+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).
+
+## What is an airgapped deployment?
+
+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.
+
+Plane supports fully airgapped deployments where all components—application services, databases, storage, and integrations—operate entirely within your isolated network perimeter.
+
+## Plane architecture overview
+
+Plane consists of multiple services working together to provide project management capabilities.
+
+![Plane architecture](/images/airgapped/plane-architecture.webp)
+
+### Frontend services
+
+**Web**  
+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.
+
+**Space**  
+Public project spaces that can be shared externally. This allows teams to publish project information without requiring authentication.
+
+**Admin**  
+Instance administration interface for workspace owners and administrators. Manages billing, licensing, workspace settings, and user permissions.
+
+### API server
+
+**API**  
+The core REST API that handles all data operations. All frontend services communicate with this API for creating, reading, updating, and deleting data.
+
+**Worker**  
+Background job processor that handles async operations like file processing, notification dispatch, and data imports. Workers pull jobs from RabbitMQ and execute them independently.
+
+**Beat worker**  
+Scheduled task executor that runs periodic jobs like data cleanup, report generation, and reminder notifications. Uses a cron-like scheduling system.
+
+**Migrator**  
+Database schema management service that runs on deployment to apply schema changes and data migrations. Runs once during upgrades then exits.
+
+### Supporting services
+
+**Live**  
+Real-time collaboration service powered by WebSockets. Handles cursor positions, live updates, and presence indicators for multiple users working simultaneously.
+
+**Silo**  
+Integration backend that manages connections to GitHub, GitLab, and Slack. Handles OAuth flows, webhook processing, and API communication with external systems.
+
+**Intake**  
+Email ingestion service that converts incoming emails into work items or comments. Requires SMTP configuration and DNS setup.
+
+### Infrastructure dependencies
+
+**PostgreSQL**  
+Primary relational database storing all application data including projects, work items, users, and configuration. Plane requires PostgreSQL 15.7+ or 16.x.
+
+**Redis/Valkey**  
+In-memory cache and session store. Used for caching frequently accessed data, storing user sessions, and managing real-time collaboration state.
+
+**RabbitMQ**  
+Message queue for asynchronous task processing. Workers pull jobs from queues for background operations like imports, exports, and notifications.
+
+**MinIO/S3**  
+Object storage for file uploads, attachments, and generated exports. Can be replaced with any S3-compatible storage system.
+
+**OpenSearch**  
+Optional search indexing service for enhanced search capabilities. Not required for basic Plane functionality.
+
+## Airgapped cluster architecture
+
+Here's how Plane operates in an airgapped environment with internal enterprise applications:
+
+![Airgapped cluster architecture](/images/airgapped/airgapped-cluster.webp)
+
+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.
+
+## Connectivity and telemetry
+
+**Critical guarantees for airgapped environments**
+
+- **No telemetry**  
+Plane does not send application data, usage metrics, or telemetry outside the cluster. No analytics, crash reports, or usage statistics leave your network.
+
+- **Offline licensing**  
+License validation happens through uploaded license files downloaded from the Prime portal. No internet connection required after initial license file transfer.
+
+- **Zero external dependencies**  
+After initial image import, no external network connectivity is required for Plane to operate. All features work entirely within your isolated environment.
+
+- **Internal-only communication**  
+All service-to-service communication stays within your cluster. Services never attempt to reach external APIs, CDNs, or third-party services.
+
+### How integrations stay internal
+
+The airgapped cluster diagram above shows the complete data flow. Key points:
+
+- **OAuth providers** - Your internal GitHub Enterprise or GitLab instance acts as the OAuth provider
+- **Authorization endpoints** - All OAuth URLs point to internal systems, never external SaaS services
+- **API communication** - Plane makes API calls only to your internal instances
+- **Webhook delivery** - Internal systems send webhooks to Plane's internal endpoints
+- **No SaaS fallback** - Plane never attempts to reach github.com, gitlab.com, or slack.com APIs
+
+This architecture ensures complete network isolation while maintaining full integration functionality.
+
+---
+
+## Kubernetes-specific requirements
+
+### Base environment
+
+Deploying airgapped Plane via Kubernetes requires preparing all dependencies to operate without any external network access.
+
+#### Container images and artifacts
+
+- Maintain an internal OCI or container registry to host all Plane service images
+- Prepare a controlled process to pull, verify, and mirror Plane container images and Helm charts from an online staging environment into the airgapped registry
+
+#### Kubernetes environment
+
+**Supported versions:** Kubernetes 1.31 – 1.33
+
+**Required components:**
+- IngressClass configured
+- StorageClass available
+- cert-manager configured with an internal CA
+
+**Node requirements:**
+- Ensure node OS dependencies and container runtime packages are available from mirrored package repositories like apt, yum, or offline bundles
+
+### Scaling
+
+Horizontal scaling is handled via replica counts configurable in `values.yaml`.
+
+Plane avoids using StatefulSets where possible due to the complexity of scaling stateful workloads in Kubernetes. The `monitor` service uses a StatefulSet.
+
+**For airgapped clusters:**
+- Ensure metrics-server images are mirrored if using HPA
+- If using node autoscaling, ensure node images are pre-loaded and registries accessible on bootstrap
+
+### Secrets management
+
+Plane supports using existing external secret stores, provided they are reachable within the airgapped environment:
+
+- AWS Secrets Manager for private VPC with no internet
+- HashiCorp Vault
+- Self-hosted Bitwarden
+- Kubernetes Secrets
+- SOPS, sealed-secrets, if preferred
+
+### Additional considerations
+
+- Ensure all secret providers can function without external network access
+- cert-manager must use an internal certificate authority
+- Keys and secret rotation policies should be part of the airgap operational procedures