Install self-hosted Plane on Kubernetes with Helm: one chart, one values file

On Kubernetes, self-hosted Plane installs from one Helm chart, plane-enterprise, and each service runs as its own workload.

One values file sets the version, the domain, the certificates, the data stores, and each service's replicas.

You need a working cluster, and kubectl and helm on the machine you install from.

1. Add Plane's chart repository with helm repo add plane https://helm.plane.so/.

2. One command, helm upgrade --install, creates the plane namespace and a release named plane-app.

   helm upgrade --install plane-app plane/plane-enterprise \
     --create-namespace \
     --namespace plane \
     --set license.licenseDomain=<your-domain> \
     --set license.licenseServer=https://prime.plane.so \
     --set planeVersion=<release-tag> \
     --set ingress.enabled=true \
     --set ingress.ingressClass=nginx \
     --set env.storageClass=<storage-class> \
     --timeout 10m \
     --wait \
     --wait-for-jobs
   

3. In that command, set license.licenseDomain to the address your team will open. The license is bound to it, and the ingress serves Plane there.

4. license.licenseServer is prime.plane.so, and planeVersion takes the latest release tag from there. Never set it to stable.

5. Turn on the ingress with your cluster's ingress class, such as nginx, and name the storage class for Plane's volumes.

6. The command then waits, for up to ten minutes, until the pods are ready and the migration job is done.

Most services come up as Deployments, monitor as a StatefulSet, and the migrator as a Job that runs once per release.

Kubernetes probes each API pod at /api/live/ every thirty seconds, and restarts the container if it stops answering. /api/ready/ checks the database and cache every ten seconds. After about ninety seconds a new pod passes, and Plane answers at your domain.

For production, keep your settings in a values file.

1. helm show values plane/plane-enterprise > values.yaml writes out the chart's defaults to start from.
2. Apply it, after every change, with the same command and -f values.yaml.
3. To upgrade, back up the database, object storage, values file, and Secrets. Then run helm repo update plane, set the new tag in planeVersion, and apply again.

The chart supports three HTTPS modes:

• To bring your own certificate, store it in a TLS Secret and point ssl.tls_secret_name at it.
• Or let cert-manager get one from Let's Encrypt. Set ssl.createIssuer and ssl.generateCerts to true, and add your email.
• Or, when a load balancer or Cloudflare terminates TLS in front of the cluster, set ssl.externalTermination to true.

The quick setup runs Postgres, Redis, RabbitMQ, and MinIO in the cluster. For production, run them as managed services instead.

• For Postgres, Redis, and RabbitMQ, set local_setup to false, and give the chart each one's connection URL.
• Turn off MinIO the same way, and name the S3 bucket for uploads and its region.
• On EKS, leave the S3 keys unset, and give Plane's service account an IAM role through Pod Identity or IRSA.

Set the secret key to a random value of your own, and keep it. Plane hashes and encrypts data with it.

To keep credentials out of the values file, put them in Kubernetes Secrets, each named in its *_existingSecret key. The chart loads each Secret with envFrom, so every key becomes an environment variable. Keep only the keys Plane reads.

High availability means Plane keeps serving when one zone or one node fails. The bundled data stores cannot do that, so use managed ones.

1. A fresh install runs one replica of everything, and the chart adds no autoscalers. Give each stateless service at least two, and api, web, and worker three.
2. Monitor, the beat workers, and the migration jobs stay at one, or they would do the same work twice.
3. You need nodes in three zones, a storage class that waits for the first consumer, a cross-zone load balancer, and two ingress replicas.
4. The live service keeps WebSockets open. On AWS, an NLB's 350-second idle timeout is fine, but raise an ALB's 60 seconds.
5. To keep replicas apart, give each scaled service topologySpreadConstraints on hostname and zone. The chart fills in the selector.
6. Then turn on podDisruptionBudget with one key, from chart 3.8.0, so a node drain takes one replica at a time. The chart skips services at one replica and refuses budgets on singletons. Budgets cover drains, not crashes or rolling updates.
7. Check them with kubectl get pdb -n plane. Each budget should allow at least one disruption.

To run without root, set securityContext.enabled to true. Every Plane pod then runs as UID 1000, the plane user. The bundled data stores run as their own users, and the restricted profile rejects them, so point Plane at external ones.

On OpenShift, restricted-v2 assigns the user ID. Set every ID to null, including the email service's runAsUser.

One Helm chart installs Plane, and one values file sets its version, HTTPS, data stores, high availability, and non-root pods.