Plane (makeplane/plane): self-hosted project management under AGPL-3.0

The problem Plane targets, and the teams it fits

Plane is a project management platform that tracks issues, runs cycles, and manages product roadmaps. The README describes it as an alternative to Jira, Linear, Monday and ClickUp, and the pitch is that you get the tracking without the overhead of managing the tool itself. That framing matters: the product is aimed at teams who already know what a sprint board should look like and do not want to rebuild their process around a new vocabulary.

The audience is narrower than the tagline suggests. Plane suits engineering and product teams that want their issue data on servers they control, and organizations whose procurement rules push them toward software they can inspect and modify. It does not suit a five-person team that just wants a hosted board by Friday, because the self-hosted path asks you to run a multi-service stack. The README offers Plane Cloud as the fast path for exactly that case, and self-hosting for teams that want full control over data and infrastructure.

How Plane is put together: services, data stores and background work

The repository is a pnpm and Turbo monorepo. The root package.json declares version 1.4.2, marks the package private, and requires Node >= 22.22.0 with [email protected]. Build, dev, start, lint and type-check tasks all route through turbo, so the apps and packages under apps/ and packages/ are built as one workspace.

The deployment shape is visible in docker-compose.yml. There are three front-end containers: web, admin and space, each built from its own Dockerfile under apps/web, apps/admin and apps/space. The API container builds from apps/api and starts through ./bin/docker-entrypoint-api.sh. Two more containers reuse the same API image with different entrypoints: worker runs ./bin/docker-entrypoint-worker.sh for background jobs, and beat-worker runs ./bin/docker-entrypoint-beat.sh for scheduled work. A separate migrator container runs ./bin/docker-entrypoint-migrator.sh and is marked restart: no, which tells you migrations are a one-shot step rather than a long-running process.

Behind those services sit PostgreSQL, Redis and RabbitMQ. The .env.example names the hosts plane-db, plane-redis and plane-mq, with PostgreSQL credentials POSTGRES_USER, POSTGRES_PASSWORD and POSTGRES_DB all defaulting to plane. File uploads go to S3-compatible storage: AWS_S3_BUCKET_NAME defaults to uploads, AWS_S3_ENDPOINT_URL points at http://plane-minio:9000, and USE_MINIO=1 selects the bundled MinIO setup. The comment next to AWS_S3_BUCKET_NAME warns that changing the bucket name also requires a change in the proxy config for uploads. That is a real coupling between app configuration and reverse-proxy behaviour, and it is the kind of detail that turns a routine rename into a debugging session.

The front end is React Router and Node on the client side, with Django on the API side, according to the README's built-with section. Because the API is Django, the migrator container and the worker containers are not optional decoration: they are part of how the application starts and stays consistent.

Installing Plane with Docker Compose

The README points at developers.plane.so for self-hosting, and lists Docker and Kubernetes as the two documented installation methods. The repository ships docker-compose.yml, docker-compose-local.yml and docker-compose-test.yml at the top level, plus .env.example, so the Compose route is the one you can trace from the files themselves.

Start by copying the example environment file. Every value below appears in .env.example; the defaults are development credentials and should be changed before the instance is reachable from a network.

cp .env.example .env

The database and queue settings in that file are what the API containers read at startup. The API service loads its own env_file from ./apps/api/.env, so the environment you edit at the repository root and the environment the API process reads are two different files. Confirm both exist before you bring anything up.

The Compose file builds images locally rather than pulling published ones, so the first run compiles the web, admin, space and api images. Bring the stack up with the Compose file in the repository root.

docker compose up -d

After the containers report healthy, the web container serves the application. The .env.example controls the listening ports through LISTEN_HTTP_PORT=80 and LISTEN_HTTPS_PORT=443, and SITE_ADDRESS=:80 sets the address the proxy binds. If you set CERT_EMAIL, the stack can request certificates from the ACME directory named in CERT_ACME_CA. Instance-level settings are then handled through what the README calls God mode, documented at developers.plane.so/self-hosting/govern/instance-admin.

Two operational details are worth pinning down before you call the install finished. The migrator container is configured with restart: no, so a failed migration leaves a stopped container rather than a retry loop; check its logs. And FILE_SIZE_LIMIT=5242880 caps uploads at roughly five megabytes by default, which is small for design attachments and will surface as a user complaint rather than an admin error.

Where Plane is the wrong tool

The self-hosted path is heavy. A working instance means PostgreSQL, Redis, RabbitMQ, an S3-compatible object store, three front-end containers, an API, a worker, a beat worker and a migrator. For a small team, that is more infrastructure than the problem justifies, and the README's own recommendation for a quick start is Plane Cloud rather than a local install.

Upgrades carry the same weight. The repository publishes release candidates before final tags, and v1.4.2 followed v1.4.2-rc1 by four days, with v1.4.1 two weeks before that. A team that wants to stay on tagged releases needs a migration rehearsal step, because the migrator container runs database migrations on its own schedule and the README does not document rollback. If your organization cannot tolerate a maintenance window for schema changes, this is a poor fit regardless of features.

The licence is the other boundary. Plane is AGPL-3.0. If you embed Plane in a product you distribute, or expose a modified version over a network, the network-copyleft terms reach further than a permissive licence would. Teams building internal tooling that never leaves the organization are usually comfortable here; teams building a commercial derivative are not, and that is a decision for your legal review, not for this article.

Finally, the README's feature list is broad but shallow on specifics. Pages are described as having AI capabilities, and the .env.example marks OPENAI_API_BASE, OPENAI_API_KEY and GPT_ENGINE as deprecated while still listing GPT_ENGINE="gpt-3.5-turbo". Anyone evaluating the AI features should treat that section as stale configuration rather than a description of current behaviour.

Plane against a hosted tracker like Linear

The honest comparison is not feature-by-feature, because Plane and a hosted tracker like Linear solve different constraints. Linear is a managed service: you sign up, the vendor runs the database, and your issue data lives on their infrastructure. Plane's self-hosted mode inverts that. You run the containers, you own the PostgreSQL volume, and you decide who can reach the network.

That inversion buys you control over data residency, the ability to patch the code, and no per-seat bill tied to the vendor's pricing page. It costs you an operations budget. Someone has to watch the worker and beat-worker containers, rotate the PostgreSQL and RabbitMQ credentials that .env.example ships as plane/plane, and handle the migrator on every upgrade. A hosted tracker has no equivalent line item in your calendar.

There is a middle path worth naming. Plane Cloud exists, so choosing Plane does not force you to self-host on day one. You can start on the hosted instance, learn whether cycles and modules match how your team actually plans, and move to the Compose stack later if the data-control requirement becomes real. The migration direction is the thing to check before you commit, because the README describes both options without describing movement between them.

Maintenance, releases and what the licence asks of you

The repository is not archived, and the last push was on 2026-08-23, the same day v1.4.2 was tagged. Recent releases arrive on a roughly two-week cadence, with a release candidate published a few days before the final tag. That cadence is useful for planning: you can pin to a final tag, watch the next rc, and schedule the migrator run deliberately rather than reactively.

The upgrade cost is dominated by the database, not the images. Because migrations run in a dedicated container that exits after the job, an upgrade is a sequence: pull the new code, rebuild images, run the migrator, then restart the API and workers. The repository provides docker-compose.yml for the standard stack and docker-compose-test.yml for a test configuration, which gives you a place to rehearse the sequence before touching production.

On licensing, AGPL-3.0 is a copyleft licence with a network clause. The practical question for most teams is whether they modify Plane and let users interact with it over a network, and whether they distribute it. Those are fact-specific determinations, and the repository's LICENSE.txt is the document that governs, not this summary. There is no separate commercial licence mentioned in the README, so if AGPL-3.0 does not fit your model, the documentation offers no alternative path.

Editorial conclusion

Adopt Plane if you need issue tracking, cycles and roadmap views on infrastructure you control, and if AGPL-3.0 fits your distribution model. Skip it if you need a hosted SaaS with a negotiated support contract, or if your legal review cannot accept the network-copyleft terms. Before committing, verify three things: that your server meets the Compose stack's requirements, that your storage and email settings in apps/api/.env are correct, and that you have a tested database backup and restore path, because the README does not document rollback.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes