Plane Deployment Strategy: A Complete Guide to Self-Hosting with Docker and Kubernetes

Plane offers a container-first deployment strategy supporting Docker Compose for local development, Docker Swarm for multi-node orchestration, and Kubernetes Helm for production clusters, all converging on the same set of versioned container images and standardized environment configurations.

The deployment strategy for Plane centers on a self-hosted, containerized architecture defined in the makeplane/plane repository. Whether you are testing locally or scaling to production, Plane provides three distinct orchestration paths that share identical container images and configuration patterns, ensuring consistency across environments.

Understanding Plane's Container-First Architecture

Plane is packaged as a suite of specialized container images published under the makeplane namespace: plane-frontend, plane-backend, plane-space, plane-admin, plane-live, and plane-proxy. All deployment strategies reference these images using the APP_RELEASE environment variable, which defaults to stable for production-ready versions.

The architecture relies on YAML anchors within the Docker Compose specification to maintain a single source of truth for environment variables. In deployments/cli/community/docker-compose.yml, shared configuration blocks like x-db-env, x-redis-env, x-minio-env, and x-app-env are defined once (lines 1-63) and merged into individual services using the <<: [*block1, *block2] syntax. This pattern ensures that database credentials, Redis connection strings, and MinIO settings remain consistent across the api, worker, beat-worker, and live services.

Docker Compose Deployment (Simplest Single-Host Setup)

Docker Compose provides the most straightforward path for single-host deployments, ideal for local development or small teams.

The canonical service definition resides in deployments/cli/community/docker-compose.yml. This file declares all necessary services including the frontend, backend API, background workers, PostgreSQL, Redis, RabbitMQ, and MinIO object storage.

Service Composition and Environment Blocks

Each service inherits shared environment variables through YAML anchors. The api service configuration demonstrates this pattern:

api:
  image: makeplane/plane-backend:${APP_RELEASE:-stable}
  command: ./bin/docker-entrypoint-api.sh
  deploy:
    replicas: ${API_REPLICAS:-1}
    restart_policy:
      condition: any
  volumes:
    - logs_api:/code/plane/logs
  environment:
    <<: [*app-env, *db-env, *redis-env, *minio-env, *aws-s3-env, *proxy-env]
  depends_on:
    - plane-db
    - plane-redis
    - plane-mq

Persistent Storage Configuration

Data persistence is handled through named volumes declared in the volumes: section (lines 47-58). The configuration mounts separate volumes for PostgreSQL data (pgdata), Redis (redisdata), file uploads (uploads), and service-specific log directories. This ensures state survives container restarts while keeping the application layer stateless.

An optional reverse proxy service runs Nginx (makeplane/plane-proxy) to expose the application on configurable host ports defined by LISTEN_HTTP_PORT and LISTEN_HTTPS_PORT (lines 20-34).

Docker Swarm Deployment (Multi-Node Orchestration)

For teams requiring multi-node clustering without the complexity of Kubernetes, Docker Swarm offers a middle path using the same Compose file specification.

The deployment leverages deployments/swarm/community/swarm.sh, an interactive bash script that wraps docker stack deploy. This script provides menu-driven actions for installation, startup, shutdown, redeployment, and upgrades. When you select "Deploy Stack," the script executes docker stack deploy using the identical docker-compose.yml file from the CLI deployment, allowing seamless migration from single-host to clustered environments.

Kubernetes Helm Deployment (Production-Grade Clusters)

For cloud-native production environments, Plane distributes an official Helm chart published on Artifact Hub. This approach targets organizations running Kubernetes clusters requiring horizontal scaling, rolling updates, and advanced scheduling.

The Helm chart pulls the same container images (makeplane/plane-*) and injects configuration through Helm values rather than environment files. The chart structure is documented in deployments/kubernetes/community/README.md, which provides installation instructions for deploying Plane into existing Kubernetes namespaces with configurable replica counts, resource limits, and ingress controllers.

Shared Configuration Model

All three deployment strategies converge on a unified configuration interface. The setup.sh script (downloaded at runtime from GitHub releases) bootstraps the deployment by creating a plane-app/ directory containing either the Compose file or Swarm configuration, alongside a plane.env file (also referenced as variables.env).

This environment file centralizes critical settings including:

• Security secrets: SECRET_KEY and LIVE_SERVER_SECRET_KEY
• Network binding: LISTEN_HTTP_PORT and LISTEN_HTTPS_PORT
• External integrations: S3-compatible storage endpoints and SMTP email settings

By maintaining this configuration parity, Plane ensures that migrating from Docker Compose to Kubernetes requires only translating environment variables into Helm values, without changing application code or container tags.

Deployment Workflow

The standard deployment workflow begins with the bootstrap script:

curl -fsSL -o setup.sh https://github.com/makeplane/plane/releases/latest/download/setup.sh && chmod +x setup.sh

Executing ./setup.sh presents an interactive menu where you select the target platform:

1. Docker Compose: Select "Install" to generate plane-app/docker-compose.yaml and plane.env, then run docker compose up -d
2. Docker Swarm: Select "Deploy Stack" to initialize the Swarm and deploy the stack across nodes
3. Kubernetes: Follow the Helm installation instructions from the chart repository to install Plane into your cluster namespace

Summary

• Plane employs a container-first deployment strategy using standardized images for frontend, backend, and auxiliary services.
• Three orchestration options are available: Docker Compose for single hosts, Docker Swarm for multi-node clusters, and Kubernetes Helm for production cloud environments.
• All strategies share the same source of truth for service definitions in deployments/cli/community/docker-compose.yml and use identical environment variable patterns.
• The setup.sh bootstrap script provides an interactive interface for installing and managing deployments across all three platforms.
• Persistent data is handled through Docker volumes for PostgreSQL, Redis, uploads, and logs, ensuring state persistence in stateless containers.

Frequently Asked Questions

What is the easiest way to deploy Plane for local testing?

Docker Compose is the recommended method for local testing. Download the setup.sh script from the latest release, execute it, and select the "Install" option for Docker Compose. This creates a plane-app/ directory with pre-configured docker-compose.yaml and plane.env files, allowing you to start the entire stack locally with a single command.

How does Plane handle environment variables across different deployment methods?

Plane uses YAML anchors in the Docker Compose file to define shared environment blocks (such as x-db-env and x-redis-env) that are merged into each service definition. For Kubernetes deployments, these same variables are mapped to Helm values. This design ensures consistency whether you are deploying via Compose, Swarm, or Helm, with all strategies ultimately consuming the same set of configuration keys.

Can I deploy Plane on Kubernetes using Helm?

Yes, Plane provides an official Helm chart documented in deployments/kubernetes/community/README.md. The chart is published on Artifact Hub and packages the same container images used in Docker deployments. You can install it using standard Helm commands, configuring the deployment through values.yaml rather than environment files.

What container images does Plane use for deployment?

Plane utilizes six primary images from the makeplane Docker Hub namespace: plane-frontend (web UI), plane-backend (API server), plane-space (collaboration interface), plane-admin (administration panel), plane-live (real-time updates), and plane-proxy (Nginx reverse proxy). All images are version-tagged via the APP_RELEASE environment variable, defaulting to stable for production deployments.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}