Plane

Last reviewed Aug 26, 2026 · 995 words

Self-hosting Plane trades a per-seat bill of about $8 a user a month (Linear or Jira at last check) for a dozen containers and 2 GB of RAM. For a team of 5 that is roughly $480 a year back, for a team of 25 it is $2,400, and the box that runs it costs less than one month of either. The interface is the closest thing to Linear you can run yourself: fast, keyboard-driven, modern. The costs are the ones the catalogue lists, resource-heavy and some features still maturing, and this guide is about keeping those two from surprising you.

The install script is the supported path, and it is fine

Plane ships as a Docker Compose stack driven by a setup script. Do not hand-assemble the compose file from the repository; the script fetches the versions that match.

mkdir -p /opt/plane && cd /opt/plane
curl -fsSL -o setup.sh https://raw.githubusercontent.com/makeplane/plane/master/deploy/selfhost/install.sh
chmod +x setup.sh
./setup.sh

You get a numbered menu: install, start, stop, restart, upgrade, view logs. Install downloads docker-compose.yaml and plane.env into the folder and pulls the images. The stack that comes up is the web app, the public "space" app for shared boards, the admin app, the Django API, a background worker, a beat scheduler, a one-shot migrator, a live collaboration service, Postgres, Redis, a message broker, MinIO for attachments, and an nginx proxy tying them together. That is why 2 GB is the floor and not a suggestion.

Set WEB_URL before the first start

Open plane.env before choosing "start". The values that bite later:

WEB_URL must be the exact public URL, scheme included, such as https://plane.example.com. Links in notification emails, OAuth callbacks, and invite links are all built from it, and a wrong value produces an instance that loads but where every link points somewhere else. CORS_ALLOWED_ORIGINS should match. NGINX_PORT (default 80) is where the proxy container listens; set it to something like 8080 and put Caddy in front for certificates rather than terminating TLS inside the stack. SECRET_KEY should be a fresh random string, not the placeholder. If you already have an S3 bucket, the AWS_* variables point attachments there instead of the bundled MinIO, which is one fewer container to back up.

Changing WEB_URL afterwards is possible (edit, restart), but signed URLs on existing attachments and old invite links will be stale.

What you actually get: work items, cycles, modules, pages

Plane's vocabulary maps cleanly to what a software team already does. Projects hold work items (the term the project moved to from "issues"), each with state, priority, assignees, labels, estimates, and sub-items. Cycles are sprints with a start and end date and a burndown. Modules group work items into feature-sized chunks across cycles, filling the role of epics. Views are saved filters, and every list can be shown as list, kanban, calendar, spreadsheet, or gantt. Pages is a block editor for specs and meeting notes that lives beside the work rather than in a separate wiki. Intake is the triage queue where requests land before they become work items.

The Community Edition is AGPL-3.0 and covers all of that. The company sells Pro and higher tiers with extra workflow features on top, and the exact line between free and paid has moved more than once, so check the current pricing page before promising a feature to your team.

2 GB runs it, 4 GB runs it without complaint

Idle, the stack sits at roughly 1.5 GB between Postgres, Redis, MinIO, and the Node and Python services, and climbs during a busy afternoon. A Raspberry Pi 4 will boot it and then swap; a used mini PC with 8 GB or a 4 GB VPS is the sane floor. CPU is a non-issue for teams under 50.

Backups are two things: a pg_dump from the Postgres container and a copy of the MinIO data volume (or your S3 bucket) for attachments. Put both on a nightly schedule before you invite the team. Upgrades go through ./setup.sh and the upgrade option, which pulls new images and runs the migrator; take the database dump first, and read the release notes, because migrations across several versions at once are where self-hosters get stuck.

Where it is still maturing

The catalogue's "some features still maturing" is fair. Importers from Jira and GitHub exist and have been rebuilt more than once, so test one on a throwaway workspace before migrating 3,000 tickets. Notifications and email digests are functional but less configurable than Jira's. The REST API and workspace API tokens work well for automation, and I would build integrations on those rather than on the importers. None of this argues against adopting it for a team that needs a fast tracker with sprints and a roadmap; it argues for keeping the old system read-only for a month.

If what you want is classic project management with time tracking, budgets, and long gantt charts, OpenProject is the heavier, older, more complete tool. If you are a 2-person team that needs a to-do board, Vikunja runs in a tenth of the RAM. The Jira alternatives page covers the full field.

What I'd do

A 4 GB VPS or a mini PC, the install script into /opt/plane, WEB_URL and SECRET_KEY set before the first start, Caddy in front on port 443 with the proxy on 8080. Nightly pg_dump and volume backup, upgrades once a month after a dump, the old tracker left read-only for 30 days. For a product team of 3 to 30 that wants Linear's feel without Linear's invoice, that is the setup I would run, and I would not run it on anything with less than 4 GB.