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.
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.
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!
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.