viharkurama

Hi HN — I work on Plane.

Our mobile app has to connect to Plane Cloud (always latest), self-hosted instances that can lag by weeks/months, and some fully air‑gapped deployments with no outbound internet.

We ended up making the app assume nothing about the server: after login it does a single "instance discovery" call to fetch metadata (including backend version + deployment flags), then routes everything through a small compatibility engine:

- hard minimum supported backend version (blocked below it) - a central feature registry (feature → minimum backend version) - version-aware API behavior (pick endpoints/request shapes based on what the server supports)

Air‑gapped support mostly became "use the same mechanism, but enforce no external network calls/telemetry."

Would love feedback / other patterns folks have used for mobile + self-hosted version skew.

Our engineering team is super excited for this, can't wait to try this out.

Hi, I’m Vihar, co‑founder of Plane (we’re building Plane, an open‑core Jira alternative). Atlassian is sunsetting its self‑hosted Jira/Data Center products and pushing everyone to the cloud. Over the last months we’ve seen a surprising amount of inbound from partners and enterprises who can’t or don’t want to go all‑in on Atlassian Cloud.

This post is our honest take on what Atlassian’s move really means for self‑hosting, what happens to Jira+Confluence heavy installs, and how to treat this as a rare opportunity to clean up workflows and possibly move to a lighter, more modern stack (including, but not only, Plane).

I have an obvious conflict of interest, so feedback/pushback is very welcome.

Hey HN,

Vihar from Plane here. For the last two years, we've been on a journey building Plane, an AI-native alternative to Jira. Our goal has always been to create a project management tool that is both powerful and flexible, which is why we offer a cloud version and a self-hosted option designed to work even in air-gapped environments.

When we started, we were just trying to build a tool we wanted to use. We launched here on HN and, thanks to this community, the project took off, eventually hitting ~39.3k GitHub stars.

Along the way, we've had to face the really tough questions about how to build a sustainable business around an open-source project without compromising our principles. This post is our attempt to share what we've learned about our framework for balancing community needs with commercial realities.

We cover our biggest mistakes, the things that worked, and how we think about the future of OSS sustainability.

Happy to answer any questions you have about our journey, the tech stack, or the challenges of building in this space!

+1. We already work with a few healthcare teams, and self-hosted is almost always their go-to. Our air-gapped edition has been in beta for a bit, and we’re seeing more use cases pop up—especially in places where HIPAA and data isolation matter a lot.

We already support this. We pack all our products in one single offering.

This includes Projects + Wiki. More here: https://docs.plane.so/core-concepts/pages/wiki

Here's a blog on how you can switch between products within Plane, https://plane.so/blog/introducing-apprail-plane-new-navigati...

You'll find all the docs here: https://developers.plane.so/self-hosting/methods/airgapped-e...

If you want air-gapped it's on Business tier, please look at our pricing page.

That being said, we don't recommend the air-gapped version for personal use. Instead, you can use our open-source Community Edition here: https://github.com/makeplane/plane — you can self-host it and disable telemetry entirely.

It's a subscription license. We offer air-gapped deployments under the Business plan. As part of compliance, we request customers to share license logs quarterly-no PII involved. Also, the license enforces seat limits, so you can't exceed the number of users you've purchased. https://plane.so/pricing

We took a different approach with Plane's air-gapped offering. No minimum user requirements at all. We evaluate based on your use case and domain requirements, not team size.

After a U.S. federal contractor told us they loved Plane but couldn't use it due to ITAR requirements, we spent 6 months building a truly air-gapped version. No external connections, no license pings, no telemetry, everything runs in complete isolation.

The interesting part: our air-gapped deployment actually runs faster than our SaaS version. Turns out when you eliminate all network latency, things get snappy.

This post covers the technical challenges we solved (supply chain trust, 2GB bundle size, offline licensing) and why regulated industries need alternatives to cloud-only tools like Jira.

surprised you haven't yet heard of Plane---we need to do something special for NGOs, :-)---, but do give us a try. https://git.new/project

what you are looking for and more's already available.

thanks for the mention. it's not great to hear we are a rip-off of Linear, but i get why you are saying that. there are quite a few differences between Linear and Plane starting with how unopinionated Plane is compared to Linear, but we need to do a better UX job to call that out in the product.

work's ongoing. expect changes soon.

We also offer a one-time perpetual license for growing teams (Plane One: https://plane.so/one), while the Pro and other plans (which come with AI) are designed for large companies; we follow the same pricing model as GitLab.

Additionally, there's always a free community edition available, which doesn't restrict the number of users.

GitHub imposes numerous limitations on custom fields, issue automation, dashboards, workflow rules, and more. Being open-source, Plane offers significant advantages to our customers by providing opportunities for learning and by striving to develop a tool that caters to the diverse needs of individuals and teams, facilitating progress.

Just as an example, while GitHub projects is great, tools like Plane (with bi-directional sync)/ZenHub still are trying to do a better job.

Linear is an opinionated tool for product teams. At Plane, we strive to develop a versatile tool that accommodates teams of all sizes and types.

For example, Linear begins with the creation of a team, whereas we initiate with the creation of a project, subsequently integrating teams as needed. Currently, Plane is being utilized by a spectrum of users, ranging from small indie game developers to large enterprises. In Linear, the starting point always revolves around forming a team.

Thanks for sharing.

Hi HN,

Vihar here, one of the maintainers at Plane (https://github.com/makeplane/plane).

Last time, we shared how we reached 15K stars on GitHub in less than a year, pushing Plane to the top spot in #project-management. The post received great feedback from the HN community, and we noticed comments about lapses in self-hosting.

We took on the challenge, rethought the entire Docker setup, made it single-click, and provided a maintenance script.

Now, we share our journey to over 100K+ Docker pulls and 44K+ K8 deploys in this blog. Please let us know what we could improve.

Hope you enjoy the article. Feedback welcome!

Thanks,

Open source has often been a lose-lose proposition by many metrics since shortly after its inception. Here's our plan to change that and make it sustainable and affordable.

Plane's Gantt Chart component is completely built from scratch and is open-source. Still in early stages, but we expect a stable version by mid-june.

https://github.com/makeplane/plane/tree/develop/apps/app/com...

Plane will also support Real-time, shipping soon :)

We greatly appreciate the meticulous design and user-friendly approach taken by Linear. Their work serves as a true inspiration to us. However, Plane have implemented all the concepts of Linear in a simpler terminology, making it more accessible to a wider range of users. Additionally, we are proud to make Plane an open-source project, which fosters collaboration within the community.

Hey, Our philosophy behind Plane is based on the concept of "Tasks meets Method." We have specifically designed this product to accommodate various project management practices such as Agile or Waterfall, allowing you to seamlessly implement the framework of your choice. The core idea behind Plane is to provide a solution that is both simple to use and highly extensible. Unlike other tools such as Focalboard, which solely focuses on Kanban, or Taiga, which strictly adheres to Agile principles, and Redmine, which serves as a more general project management tool, Plane aims to offer a versatile platform that combines simplicity with flexibility.

We used Joe and Pedro on some of our screenshots. Discussion is all about that :)

Height is a very general tool with it's focus on various kinds of teams. With Plane you do that as well. But it's focus is more on the Method. Method or the framework of choice that the team wants to use to manage their projects.

Our page speeds are currently standing at ~350ms at this point. we are trying hard to make it < 100ms. Feedback helps.

Hey, we do have a feature of nested issues as part of Plane. You can go n-levels. You can have different type of issues via labelling.

I agree to the idea of not ignoring Indian names. We do have India names as well on certain screenshots. To distribute well we used all kinds of names. We tried our best to globalize.

We have a singular focus working only on Plane and making it big for everyone. We are still in early stages, so had to rush on few decisions, but we treat every user the same.

Youtrack is great but complicated with it's UX. Code level extensibility with Project management tools is near zero. We are working on our extensibility framework called Propel, it gives you the ability to write code with React to extend Plane. Open-sourcing in Q3 2023.