Plane - "The open source project management tool"

[niels]

https://plane.so/

"P L A N E
Project Planning tool you will fall in love with.
Plane helps you track your issues, epics, and product roadmaps in the simplest way possible."

"Plane is an open-source software development tool to manage issues, sprints, and product roadmaps with peace of mind 🧘‍️."

It is rather reminiscent of JIRA (also see https://forum.cloudron.io/topic/1654/atlassian-jira-the-1-software-development-tool-used-by-agile-teams).

Self-hosting instructions can be found on https://docs.plane.so/self-hosting.

The source code lives at https://github.com/makeplane/plane.

[LoudLemur]

@niels I tried to see if this supports Gantt charts but couldn't find anything.

[niels]

@LoudLemur Gantt charts just got merged and should be available in the next release: https://github.com/makeplane/plane/pull/1062

[marcusquinn]

Looks cool. Could do with some screenshots:

[plan-a]

I would love to have Plane on Cloudron. I am currently using the Plane cloud, but I would instantly switch to Cloudron, if it was available there.

[david.opalia]

We are currently running it self-hosted in Docker on our NAS, but we would migrate to Cloudron if it becomes available.

Can we help ?

[robi]

@david.opalia Yes, you can make a custom package and submit it to the Cloudron App store.

[miednr]

Will plane come to Cloudron? I am also interested in using plane self-hosted.

[LoudLemur]

It looks like Plane have given up on Gantt charts.

Epics fits into the Plane hierarchy like this:

Hierarchy: Issues → Epics → Initiatives (Initiatives group multiple Epics for even larger scopes).

[LoudLemur]

This post is deleted!

[LoudLemur]

What Cloudron fights you on for Plane: the single-container model.

It is probably better to just use Plane's Docker Compose and run it on its own little VPS.

Plane is not a monolithic app with a database bolted on. It is a distributed system with nine services, a message broker, and an object store. Cramming all of that into one container with supervisord is not how any of those components were designed to run. It works (Outline, Cal.com, Seafile, and Zoneminder have all been packaged this way), but the result is fragile in ways that a Docker Compose deployment is not. If the Celery worker crashes and supervisord restarts it, that is fine. If LavinMQ crashes and takes in-flight messages with it while the API is still accepting requests, you get silent failures that are hard to diagnose. The failure modes multiply with the number of co-located services.