The Plane Self-Hosting Guide: Run Plane on Infrastructure You Control
The Plane Self-Hosting Guide
How to run Plane on infrastructure you control. Product fit, architecture, deployment, high availability, security, air-gapped operation, governance, and economics, including a dedicated track for Jira Data Center customers.
For CIOs, CISOs, platform teams, and Jira administrators
Editions Commercial and Airgapped
Reading time About 25 minutes
1.1 Executive summary
The context
Plane is a work management platform that combines projects and work items, a workspace wiki, intake, workflows, approvals, automation, analytics, and AI in one product. It runs as a managed cloud service, a connected self-hosted deployment, or a fully disconnected air-gapped deployment.
This guide is about running Plane yourself, and running it well.
It is written for organizations that must control where their work system runs, how it connects, and when it changes.
It covers the full lifecycle of a self-hosted Plane deployment: product fit, architecture, deployment models, high availability, day-two operations, air-gapped supply chains, identity, network and AI boundaries, compliance, and economics.
The guide makes four claims.
- Self-hosting is a product requirement, not a packaging option. The Commercial Edition is designed to run on customer infrastructure with the same product model as Plane Cloud, and the Airgapped Edition runs with no runtime egress at all.
- The architecture is conventional enough to operate. Plane runs on containers, PostgreSQL, Redis or Valkey, RabbitMQ, S3-compatible object storage, and optional OpenSearch.
- The platform is complete. Projects, work items, portfolio planning, documentation, intake, approvals, automation, analytics, and extensibility live in one system, under one identity and governance model.
- The economics rest on control and consolidation. A self-hosted buyer pays for the product and owns the infrastructure and operations.
1.2 Control boundary and editions
Define the deployment control boundary
| Model | Where Plane runs | Required external path | Best for |
|---|---|---|---|
| Connected self-hosted | Your servers, VPC, or Kubernetes cluster | License and seat synchronization | Private infrastructure with governed egress |
| Air-gapped | A disconnected or sealed environment | None at runtime | Classified, regulated, sovereign, or zero-egress networks |
Select the edition and commercial plan
| Edition | Purpose | Important boundary |
|---|---|---|
| Community | Open-source evaluation, audit, customization | Feature-equivalent to the Free tier; not the enterprise governance product |
| Commercial | Supported self-hosting with access to paid plans | Connected licensing; full Cloud feature parity by plan |
| Airgapped | Commercial capabilities in a disconnected environment | Offline licensing and internal artifact distribution |
1.3 Product fit and proof criteria
An enterprise work platform is not “issues plus a board.”
| Enterprise outcome | Plane capability |
|---|---|
| Plan and execute work | Projects, work items, states, cycles, modules, epics, milestones, releases |
| Coordinate portfolios | Initiatives, dashboards, project updates, workspace views |
| Model different work | Workspace and project work-item types, custom properties, custom relations |
| Control process | Workflows, approvals, pre-validation, post-actions, automations |
| Capture demand | In-app intake, forms, email intake, customers, custom SLAs |
| Keep knowledge with work | Project Pages, workspace Wiki, collections, nested pages, templates |
| Govern access | Workspace and project roles, custom roles, permission schemes, granular access control |
| Integrate systems | REST API, webhooks, native integrations, Plane apps, SDKs, MCP |
| Use AI under policy | OpenAI, Anthropic, Bedrock, Ollama, or OpenAI-compatible endpoints |
Define proof criteria before deploying
A credible evaluation is run against your own work, not against a feature checklist.
- Name the top 20 workflows the organization cannot operate without, and the outcome each one must produce.
- Define acceptance criteria per workflow.
- Run those workflows end to end in a pilot workspace with real teams and real work.
- Record every gap with an owner and a decision: reproduce, redesign, or retire.
2.1 Platform architecture
Plane is a multi-service application with stateless application workloads and stateful backing services. The stack is built from familiar infrastructure rather than a proprietary runtime.
The principal services
| Service | Responsibility | Scaling model |
|---|---|---|
web |
Primary application interface | Stateless, horizontal |
space |
Published projects, views, and pages | Stateless, horizontal |
admin |
Instance administration | Stateless, horizontal |
api |
Core REST API and data operations | Stateless, horizontal |
worker |
Imports, notifications, file processing and background jobs | Stateless, horizontal |
beatworker |
Periodic job scheduling | Singleton |
migrator |
Schema and data migrations during release | Run-once job |
live |
Real-time collaboration and presence | Stateless, horizontal |
monitor |
Licensing and activation | Stateful singleton |
silo |
GitHub, GitLab, Slack, and other integrations | Stateless, horizontal |
intake |
Email-to-work-item processing | Stateless, horizontal |
| Plane AI services | Search, duplicate detection, and AI interaction | Horizontally scalable workers plus dedicated state |
2.2 Deployment models and capacity
Plane publishes multiple installation methods, including Docker Compose, Kubernetes with Helm, Docker Swarm. Choose a method that matches the stage.
| Stage | Recommended shape | Why |
|---|---|---|
| Local evaluation | All-in-one or Docker Compose | Fastest path to a working instance |
| Department pilot | Docker Compose with external Postgres and object storage | Simple operations with durable state outside the host |
| Enterprise production | Kubernetes with external managed state | Horizontal scaling, controlled upgrades, node and AZ fault tolerance |
| Sealed environment | Airgapped Docker or Kubernetes | Zero public-internet dependency |
High availability and resilience
The documented Kubernetes high-availability model is single-region, multi-availability-zone. It is designed to survive a node or availability-zone failure.
| Tier | Workloads | Production pattern |
|---|---|---|
| 1. Stateless | api, web, space, admin, live, worker, silo, intake | At least two replicas, spread across nodes and AZs, scaled horizontally |
| 2. Singleton and coordinator | Beat workers, monitor, migrators | Exactly one replica, or one run per release |
| 3. Stateful | PostgreSQL, Redis or Valkey, RabbitMQ | Disable local setup; use replicated, multi-AZ services |
Day-two operations
For Docker installations, the CLI handles common lifecycle tasks. Minimum operating model includes service health and traffic management, data protection and recovery, observability, and operational telemetry.
Air-gapped supply chain
An air gap is a controlled process for moving software, licenses, updates, and evidence across a trust boundary.
3.1 Identity, access, and governance
The security advantage of self-hosting is control. Plane supports SAML and OIDC for single sign-on. Define identity and access management models. Store roles and permissions.
4.1 Jira Data Center transition
Transition for organizations that run Jira Data Center. Evaluate Plane as a successor to Jira Data Center.
| Date | What changes | Enterprise implication |
|---|---|---|
| 30 Mar 2026 | New Data Center sales end | New on-prem Atlassian standardization is closed |
| 30 Mar 2028 | Expansions and renewals end for existing customers | Seat growth and Marketplace planning constrained |
| 28 Mar 2029 | Affected subscriptions and apps reach end of life and become read-only | Migration, exception, or loss of an operational system of record |
5.1 Enterprise operating model
Standardizing on a work platform is an opportunity to consolidate operations into a coherent platform.
A common work model
Enterprise Grid
└── Workspaces
├── Teamspaces
├── Initiatives
│ └── Projects and epics
└── Projects
├── Work-item types
├── Work items and sub-work items
├── Cycles
├── Modules
├── Milestones and releases
└── Pages
Integrated knowledge and execution
Plane includes project Pages and workspace Wiki for cross-project knowledge and inline collaboration.
Extensibility and automation
Plane offers several layers of extensibility. More than 180 REST endpoints are documented for internal applications and system integration.
5.3 Economics
The Plane self-hosted cost model includes the plan, infrastructure, operations, and adoption. Calculate based on real estate rather than generic predictions.
5.4 90-day validation program
\nRun in five stages to move from interest to a defensible decision:
Days 0–15
- Confirm connected or air-gapped. Select edition and plan. Define security owners.
Days 16–30
- Deploy non-production Plane. Establish roles and permission schemes.
Days 31–60
- Map types, properties, states, users, cycles, and modules. Capture every exception.
Days 61–75
- Run readiness and liveness behavior tests. Test an upgrade.
Days 76–90
- Run real work with pilot teams and finalize migration wave plan.
\nValidate deployment specifics, edition boundaries, and importer behavior. All evidence should be defensible to ensure control over each aspect of the enterprise migration.