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

> Master Plane deployment strategy with Docker Compose, Docker Swarm, and Kubernetes. Self-host effectively using our comprehensive guide and versioned container images for seamless orchestration.

- Repository: [Plane/plane](https://github.com/makeplane/plane)
- Tags: how-to-guide
- Published: 2026-08-25

---

**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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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:

```yaml
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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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:

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

```

Executing [`./setup.sh`](https://github.com/makeplane/plane/blob/main/./setup.sh) presents an interactive menu where you select the target platform:

1. **Docker Compose**: Select "Install" to generate [`plane-app/docker-compose.yaml`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/deployments/cli/community/docker-compose.yml) and use identical environment variable patterns.
- The [`setup.sh`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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`](https://github.com/makeplane/plane/blob/main/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.