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.
I don’t get it, the dependencies are either needed or not. If needed that are either pulled from a project or written. So how are dependencies evil , is the rage against feature bloat pulling in dependencies ? Then the issue is the bloat
Functionality is either needed or it isn't, but it doesn't need to come from an external dependency. When it does, it probably comes with functionality you didn't need too. And as soon as you have a compile/runtime dependency on external code, your compile/execution environment needs to always have access to third party code. So that's bloat and complexity. You also give up control. Hopefully it ends up saving a bunch of time over developing it internally.
Hopefully an upgrade to an external library doesn't end up including another dependancy that happens to include some backdoor that steals all the credit card information in your database. Or a crypto miner in frontend code. Or introduces a bug that stops people from being able to checkout. Or the money package starts calculating slightly differently than your payments provider... Etc. etc.
instead of CI/CD pipelines and a million dependances, why don't we just put all of the containers, like, on one single VM? and just make it a linux box or whatever?
The usual way to deploy such things is actually to create 1 VM for that application, install podman, and then run all those tons of containers in that VM. Because you cannot trust software vendors to not do or require stupid shit like requiring the docker socket, mounting overly broad volumes from the hosts filesystem, provide working and non-stupid compose/helm/...-files and things like that. Often the support contract also requires a specific version of a specific OS, a specific kubernetes distro or something like puppet/chef/... for deployment. Since for the multitude of software vendors and requirements, we couldn't easily fulfill all those at the same time on the same kubernetes cluster or infra, we just split it up into VMs.
- it is not at all surprising that when you remove cruft, code performs batter
- it is not at all surprising that this is not common enough amongst software engineers to even consider these things (competing business interests probably cause this often)
Not being connected to the work VPN already slows down my Windows to a near halt since a few unreachable network drives is all it takes to make Explorer go unresponsive.
Seems like engineers forget to test these things nowadays.
Totally agree. Why pick the one negative thing to say instead of saying “this should be done more often” for example. Just aggravating, as a behaviour.
Once again going full-circle with the industry reinventing self-hosted software. Excuse my cynicism, I'm going back to minding my own business (reinventing design systems / component libraries, lol)
> Turns out when you eliminate all network latency, things get snappy.
Same experience with JIRA. I read all these negative comments here and elsewhere about how slow and clunky JIRA was, and I couldn't relate at all.
Then I realized all those who complained was using JIRA Cloud and we were using on-prem, and it all made sense.
We've since moved to JIRA Cloud ourselves, and I understand now.
We moved and none of the new places had any viable computer room, so literally had to put the rack in a closet And well, that ain't cutting it for physical access control these days. Thankfully we have very simple flows without any BS, so not too many 1-5 second clicks to get things done.
I contracted with a company that used an on-prem version of Jira. Their instance was painfully slow over VPN and I often wondered why they didn't add more resources thinking that this was the experience for everyone. Then I went on-site for a few days and the performance was night and day. On-prem, their Jira instance was the fastest I've ever seen, faster than the cloud version and felt snappier than Trello.
On-prem is great if everyone is coming into the office, but I think orgs should pay more attention to the "remote experience" of their on-prem tools.
Just open the network tab and refresh a page in Jira and you will understand. It isn’t too noticeable on a LAN. Stick the internet in there and it is painful. The worst I have seen is self hosted and accessed over Netskope ZTNA. Truly an abomination.
It's not the refresh that screws you. It's the four goddamn dozen asyncrhonous calls it has to make after that refresh has completed to actually fill out the content of the page and let you click through stuff.
I have to load half a dozen tabs of new tickets and then cycle through them triaging and defining fields in a collated manner to make it so my time isn't hugely dominated by waiting.
We used to have on-prem and it was probably about an order of magnitude better, but still nowhere near "XP in a VM accessing a site on localhost" level snappy.
I have had the opposite experience with Jira at a relatively large corporation (years ago). Our local Jira was probably just configured weird or on underpowered hardware though.
Having adopted a number of development tools, including Jira and Confluence, it’s amazing people let them sit there chugging away on underpowered machines with hundreds of users quietly complaining about the speed. Throwing some extra CPU cores and memory is so cheap for the quality of life improvement, let alone the productivity gain.
The concurrent (human) user counts at even large companies is probably a couple dozen at most.
Usually with these tools, the performance problems magically vanish if you disable all the integrations people have set up. My company is constantly denial of service attacking Jira with Github updates, for example.
I delivered a complex, highly customized enterprise back-office system for a large Fortune 500 some time back. It involved a handful of servers (all as VM's), x3 to accommodate DEV/QA/PROD staging.
It worked great in volume testing in our environment. Their IT department installed it on high end servers (hundreds of cores, incredibly expensive storage subsystems, etc) but users complained of latency, random slowness, etc. IT spent weeks investigating and swore up and down it wasn't their end and must be a software issue. We replicated and completely sanitized production volumes of data to try and recreate locally and couldn't.
Finally I flew down and hosted their entire infrastructure off my laptop for a day (I'll skip all the security safeguards, contract assurances, secure wipes, etc). It flew like a thoroughbread at a racetrack. No latency, instant responsiveness, no timeouts, no hiccups. Their entire staff raved about the difference. The results gave the business unit VP what she needed to bypass the usual, convoluted channels, and someone must have lit a fire under their IT VP - by the end of that day their internal techs identified a misconfiguration on their storage arrays and solved the problem. I can only guess how many other apps were silently suffering for weeks or months on the same array. I joked I'd be happy to sell them a laptop or two for a fraction of their mainframe cost.
I had the experience for a few years of having to run all of the self-hosted development and project management tooling for a government project about a decade back, and the integrations part holds up strong to that experience. The CI system that had been put in place was probably the most sophisticated I've ever seen, but that had some unfortunate side effects like Jenkins jobs being kicked off automatically thousands of times an hour, blasting all of the Atlassian tools with network requests, or Nessus remote logging into and spawning 40,000 simultaneous processes on the servers actually hosting the Atlassian tools.
People complaining about JIRA has become enough of a trope that it mostly gets ignored.
Also big enough corps give underpowered machines to the mass of employees (anyone not a dev, designer or lead of something) so latency is just life to them.
My company self hosts most things, which is bad for remote employees and employees in offices other than the primary because the VPN server (or possibly their network connection) is underpowered for the number of remote users. I sometimes need to wait 45 minutes for a like 1GB clone.
> We've since moved to JIRA Cloud ourselves, and I understand now.
Jira on-prem was dog slow, yes, especially if it didn't live on the same server as the database. But Jira Cloud? It isn't much faster than that! It's a piece of hot mess. Loading placeholders everywhere. Really I have absolutely zero idea what Atlassian is doing, but I know for sure optimizing for performance is not amongst the things they are doing.
Yeah, this whole pattern of loading a million placeholders and then watching the page awkwardly snap into layout is just sad. Especially when you know that you could have shown just as much information in a "server side rendered" piece of PHP in 2005 with less latency.
The other thing, every pm wants a custom field just for their project, a field they’ll forget they asked for a day later. TLDR, put a governance board that’s fine saying no especially when someone inevitably pulls rank.
Myself included, JIRA is used far too much out of the box and few people ever learn what it can actually do.
Out of the box it is pretty generic. When I learned what it could actually do, it revealed itself as a sponge that can uniquely absorb complexity. Having someone familiar with JIRA show the ropes went a long way.
Some of these new development tools are pretty nice though. Variety is good, especially with the changes from Pivotal Tracker, etc going away.
We run an airgapped version of JIRA (but we are a very big company, globally distributed). Performance is in the gutter.
The annoying part is the amount of garbage fixes in JIRA's UI. For example, because of the loading speed, and me losing patience with it, if I don't wait for the page to finally finish loading and click on the "create" button, then instead of the modal dialog for issue creation, I get a whole new page for issue creation. Both options are atrocious from UX perspective (because usually I need to copy text from the issue I was reading into the issue I'm creating), but at least when it's a modal window, I can pop open the developer tools and delete the modal part that prevents me from copying the text from the issue otherwise blocked from interaction.
Also, it looks like due to speed, some queries simply don't finish on time, and randomly, searches don't find all the issues they should. Especially searches that ask for "s.t. parent issue has such-and-such properties".
Ultimately, JIRA isn't built to scale (ironically, since it's written in Java, which was always defended as being slow for small problems but scaled well). The code has a lot of assumptions about some operations being fast enough to not require buffering / incremental implementation. And sometimes you hit the combos of such unoptimized operations and have to wait minutes for the program to respond.
Our org used Jira on-prem for 2k engineers and 3k additional staff and it was slow as molasses.
The dialogues and context menus took forever to show and page navigation was beyond painful.
We had dedicated engineering for maintaining our Jira and Bitbucket, and they still fell over. We eventually moved back to GitHub. (Our usage went from GitHub on-prem pre-MS -> Bitbucket on-prem -> GitHub cloud post-MS.)
I hate Jira regardless of where it's deployed. It's a beast.
They've removed it from their pricing page now, but when they announced the discontinuation of the regular on-prem server the minimum for datacenter was like 500 licensed users or something along those lines.
In any case it was clear it's not for small shops like us.
That said, air-gapped is a hefty requirement, so perhaps those customers are predominantly large?
> That said, air-gapped is a hefty requirement, so perhaps those customers are predominantly large?
There are lots of very small classified networks out there with only a few dozen users.
There are a lot more user communities course that aren’t necessarily airgapped, but where they have special compliance requirements that pretty much mandate self hosting (or at least bring-your-own cloud.)
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.
We do the similar with our B2B product (in an entirely different niche). We have everything from single-person companies up to very large ones. Similarly we set price based on use-case and requirements.
I still run an old version on an air gapped network and will continue to do so until we're forced to change for some reason. It's not a hefty requirement; we run it for a team of < 10 developers on a small VM and it just works.
It might as well be for the vast majority of companies, since I believe the smallest number of users you can buy support for is 500.
To be more specific, they killed off the legacy Jira Server and now only offer these enterprise versions of Jira and the rest of the suite if you won't move to the cloud.
How do you handle compliance in confirming that the product is only used for the license duration? (Or is it more of a one time purchase plus recurring fee for updates?)
At this level (govt, 6 figure+ deals) I would at least consider if this problem should have a non-tech solution, and instead have a legal/lawyer solution. In my experience (not US based though) the govt contracts are under compliance programmes as well so the govt agency’s legal/contract mgmt team would probably follow up internally on expiring contracts (ie licences) and require the owning stakeholder to either renew the contract or abandon the software. Meaning the customer would supervise itself regarding licence. But even if you don’t want to rely on self-supervision then having your lawyer spend 1 hour reaching out with a “do you need to renew your licence” at the end of a licence term would probably be much cheaper than building and maintaining an air-gapped licence solution.
Usually you do have recourse via procurement channels and reps. If you file a complaint with that agency stating that they’re using a license without paying for it, it will result in at least an investigation.
If you got to hire the cops to investigate your own mistakes, would you hire competent, motivated folks who'd leave no stone unturned and get access to every classified, air-gapped network in search of license infringements?
I wouldn't. I'd hire some Peter Gibbons type, who only does about 15 minutes of real, actual work in a typical week. Then I'd tell them they can finish early if all their pending cases are closed.
Largely agree but I want to challenge this bit at the end.
> probably be much cheaper than building and maintaining an air-gapped licence solution
I think this is an unwise attitude to take. There's something to be said for a simple picket fence. Even though someone could easily hop it if they wanted to, they lose plausible deniability and in most cases that's all that really matters at the end of the day.
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
Phrabricator lives on in Phorge, which is seeing active contributions.
I haven't used Phorge, but Phrabricator is easily my favourite tool among the source code portals. The code review system actually works and does not make me tear my hair out. I am completely at a loss why the commercial side of it seemingly failed after all those years, when products such as Bitbucket and Gitlab seem to do well.
I think we have different definitions of the term "air-gapped". Users still very much connect to it using a network. This just doesn't phone home (or elsewhere).
A truly airgapped Jira-alternative would be somewhat impractical.
There is no price anywhere. I would be interested to use that for either my job or for private projects, but where and how much do I pay?
Edit: I looked again and even your pricing pages have no price. I understand that you may want to restrict yourself to rich companies, but I don't understand the point of posting on HN if that's the case.
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.
Air-gapped probably adds a zero or two to the highest tier Enterprise price. You wouldn't buy an Enterprise license for a personal project, why would you buy an Enterprise++ license (which is essentially what AG is)?
Running software in an airgapped environment is difficult, but the hardest thing is the install, packaging and shipping updates. I have used https://zarf.dev/ to do this for a government client, and it was an amazing experience. I highly recommend it. K8s seems heavy, but if you want to run datastores with backups (k8s operators), or highly customised environments, and automate all of that, instead of loads of bash and custom code, it shines.
I just learned air-gapped includes private networks. I was under the impression this strictly meant isolated non-networked computers. Was this always the case or has the term diluted over time?
Strictly speaking, air-gapped originally meant physically isolated, no network connections at all. But in practice, the definition has broadened a bit, especially in enterprise and defense settings.
Today, it may include closed private networks with no internet access, still isolated, but with internal connectivity for practical reasons (like backups, logging, or internal auth).
I think it just depends on the context you're talking about. Air gapped just means there's no connection between two things so it could be talking about networks or individual computers.
I work on an air-gapped network. The most important thing that the words "air gap" communicate is that there is no connection, nothing at all, to anything outside the network. The only way to move anything on or off are using disc drives (no USB for security reasons). The word "private network" does not really communicate that there is a physical gap of no wires at all from the computers on the network and everything else on the internet.
This also makes it infinitely more useful for healthcare. Not healthcare software specifically. Lots of use cases in logistics, irl maintenance, etc. Patient data creates hipaa challenges and tends to overflow into any system.
Nothing in HIPAA mandates air gaps. In the context of HIPAA that's really overkill.
In fact, self-hosting might even do you wrong when things go bad, because AWS is probably better managed and more secure. And they have all their certs, which is legally important.
+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.
Why would a health care org care about air-gapped deployments? Most (really, almost all) health care data is stored on cloud SAAS databases already; for people who care, this vendor already had an on-prem version.
What you say makes sense, but I think there can be reasons. For our military customers we offer an air-gapped version of our app early on because it was easier for customers than getting an ATO. Also as a bootstrapped company it was a lot cheaper than FedRAMP. I'm guessing I'd lean on a similar strategy if I had a health care startup.
Yes, absolutely, in a way, we’re just bringing back the old-school model — full package, zero dependencies, runs on your own infra — but with modern tooling and UX.
Doesn't seem to be a lot of options for self-hosted/open-core project management software. The existing ones looks pretty bad, and don't come anywhere close to Jira level functionality.
> don't come anywhere close to Jira level functionality.
In my experience that's probably a good thing. I've moved from a company using Phabricator to one using Jira. Phabricator had exactly everything we needed and was very nicely designed and worked really nicely.
Jira has everything you need plus loads of other stuff that project managers feel like they need to add. Oh and they'll never clear anything up or fix any config bugs because they don't actually have to ever use the "report bug" form so who cares if there are 100 fields and half of the mandatory ones are hidden in "More fields"? 5 different states for "TODO"? Eh who cares. 3 different ways to say which team a bug is in? Better fill them all in for every bug.
It's better to be missing features than to have features that project managers can configure.
I've used both as well, I found Phabricator fine for lightweight kanban-style team work tracking, but once we had PMs it was doomed because it would never do what they wanted (they didn't seem to be able to understand that it was not a Scrum system and would never match well).
These days I'd be using Github instead, issues there are also nice and simple. I imagine it would ultimately suffer the same fate in a similar situation though (not that I intend to get there ever again).
The problem with Jira is that it's so customisable and always ends up being customised by "process people" who think all problems can be solved by adding just one more field - but simultaneously it's never possible to customise your bit to work the way you want.
We wanted to host on prem a few years ago. Plane was around at the time but didn't look like a mature enough solution. On the other hand, our Redmine instance was far too "mature." We went with YouTrack since it had a highly customizable import plugin for Redmine.
> Even with our robust self-hosted option, we kept hearing the same feedback from legal and compliance teams: "Private cloud" solutions that still require Virtual Private Network (VPN) tunnels don't meet their stringent requirements.
If it has a VPN tunnel to some outside server, you shouldn't really call it "self-hosted*
When you add features such as telemetry, curl calls in install scripts, and in general build on public cloud infra, everything assumes you have internet connectivity. That assumption is so crucial that it is embedded in everything and touches most software components. When you already have an established product, I imagine changing it to remove the assumption without a full rewrite can be tricky.
Yes, agreed, if you build with air-gapped in mind from day one, it should just work.
In our case, we had to unwind a bunch of assumptions baked into modern SaaS: license checks, analytics, image pulls, update pings… even small things like font hosting or third-party embeds needed rethinking.
Not hard in principle, just a lot of invisible cleanup to make it truly self-contained. Learned a ton doing it.
from Google: "Atlassian has sunsetted its Server product line, including Jira Server, meaning they are no longer supported and users need to migrate to Cloud or Data Center versions. Specifically, support for Atlassian Server products ended on February 15, 2024. This includes the end of new license sales, renewals, and security updates for Jira Server. "
You'll pay through your nose for a Data Center license though, and it doesn't change the fact that Jira is a mess so slow that SAP can appear fast in comparison.
You can have an air gap between two physical items - it doesn't matter if those physical items are air tight or not. Air gapped doesn't mean the items are prohibited to intake air (i.e. air tight), it just means they're prohibited to intake things _apart_ from air.
Historically, we did not have wifi and other radio based new fangled data communications. Data connectivity required wires, physical connections. If there was a gap between the two devices that had no wire, just air, that was air gapped. No comms could happen between the two. It is physically isolated. it used to be called "physically isolated" when we used it in the 80's (?). Some say, we stole it from plumbers but that is hogwash (pun intended, you know the backflow prevention thing). I vaguely recall start seeing it late 1990's to 2K in the public?
Mission Impossible 1996 the computer in the room where tom cruise is lowered into the room. That was an example of 90's air-gapped system.
The name stuck because it sounds cool. In my opinion, there is no such thing as true "air-gapped network" any more. There are too many ways to snoop on systems that are isolated, without "physical" and radio connections in the traditional sense (e.g., listen to the "electricity", sounds, power fluctuation, ground vibration, squirrel squeeks).
Airgapped systems have an air gap between the system and the wider world. The only way to move data to and from them is for someone to walk across the gap with physical media.
There are no communication cables between the host system and the wider world.
* air-gap malware can be designed to communicate secure information acoustically, at frequencies near or beyond the limit of human hearing.
* In 2014, researchers introduced ″AirHopper″, a bifurcated attack pattern showing the feasibility of data exfiltration from an isolated computer to a nearby mobile phone, using FM frequency signals.
* In 2015, "HELLONE", a covert signaling channel between air-gapped computers using thermal manipulations, was introduced. "BitWhisper" supports bidirectional communication and requires no additional dedicated peripheral hardware.
* Later in 2015, researchers introduced "GSMem", a method for exfiltrating data from air-gapped computers over cellular frequencies. The transmission - generated by a standard internal bus - renders the computer into a small cellular transmitter antenna.
Any more details about the offline patch/upgrade process? When I looked at gitlab years ago, it handled that fine but the documentation seemed "nervous" about it.
I struggle to think why that would be any drama, unless the setup is trying to use "bare" gitlab (e.g. running the puppet commands manually versus $(docker save -o airgapped_gitlab.tar gitlab/gitlab-ce:18.2.0-ce && cp ./*.tar /dev/disk/usb-whatever/goodluck/))
Most self-hosted apps, including jira, can be airgapped. Yeah maybe it's not made super easy like Plane, but any org that requires this is going to have an IT department that can handle it.
> This post explores the journey of building this specialized deployment option for regulated industries where data sovereignty isn't just preferred—it's mandatory.
This is an AI writing tell: "It's not just x—it's y."
Buy-and-forget perpetual pricing for internal networks, please.
Don’t want to pick up annual subscriptions, and don’t want any dependency on a third party company that might not last or will start doubling prices in the future after an acquisition - been burned heaps by that.
A week into installation, your cube mate will be complaining that the arrow keys do not work as used to and cannot use alt-tab on the fields, or the color orange and green make their eye hurt. So a ticket is opened, a software update is made, and then the patch is generated. That is 12 month on a good day because all the back track, re-validation, scope creep, auditing, re-validation, third party review, committee blessings, and good idea fairies.
Then you have to get the patch into the environment. Now you need a blood oath from the entire chain of command up to Katie A. where she swears she is going to beat you if you whine about the color scheme again. ;) Three years past, and the changes are implemented. It does not matter because your monitor which had to be TAA compliant and could not be brought in without you soldering everything together is now running off of a hercules video card, yes that green only hercules card. You see only shades of green in the app...
Really appreciate that — and totally agree.
We’ve been surprised by how many teams in defense, healthcare, and critical infrastructure are still stuck choosing between bloated legacy tools or cloud-only products that don’t check the right boxes.
We built the air-gapped edition of Plane exactly for this.
This is just shipping a docker container for people to run the app on their own infrastructure. Retool does the same thing for companies which don’t want to expose internal resources and databases to the cloud.
TBH, if I were working in such a highly regulated industry, I'd be very hesitant about buying software from a company with a .so domain and basically beholden to the whims of the government of Somalia.
If they said "implement a backdoor for us or all your non-airgapped customers lose access tomorrow", are you sure the company would be able and willing to say no?
.so is widely used by software companies as a domain availability solution - think Notion. For regulated environments, the domain doesn’t matter, the architecture does.
With air-gapped deployments, Plane doesn’t rely on any external DNS or domains — .so or otherwise. No license pings, no telemetry, no outbound calls. Everything runs in complete isolation, and customers have full control over the environment.
Also worth noting: Plane’s open-source core (AGPLv3) allows for full transparency and auditability. So any notion of a backdoor is counter to how we operate — and how our users deploy us.
That's a very odd thing to bring up in the context of self-hosting, since you would not interact with their .so domain whatsoever; ensure that the AGPLv3 aligns with your needs, git clone -b v0.27.1 https://github.com/makeplane/plane.git and be happy
Given their customer base, I wonder why they bothered with any license enforcement for the pure on-prem. Just do the "license enforcement" implicitly when customers want to update: they need to log in to get the new image.
(Your regular annoying notice that FIPS-compliant crypto is, if anything, marginally less secure than non-FIPS crypto; not that it matters in any material way, just, it's not a flex.)
We ran our company on a whiteboard, until we couldn't, so I get it.
And honestly it does beat a lot of bloated tools out there. But when you need permissioning, history, workflows, audit logs—and your infra lives in a bunker—we try to be the next best thing.
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.
> The interesting part: our air-gapped deployment actually runs faster than our SaaS version.
This is the least surprising thing I’ve read all day.
If they also realize that having less dependencies makes deployment easier we have gone full circle.
I can't believe how many devs think dependancies are completely cost free...
Dependencies and code are both liabilities with maintenance costs. Devs chronically underestimate the cost of both, myself included.
I don’t get it, the dependencies are either needed or not. If needed that are either pulled from a project or written. So how are dependencies evil , is the rage against feature bloat pulling in dependencies ? Then the issue is the bloat
Functionality is either needed or it isn't, but it doesn't need to come from an external dependency. When it does, it probably comes with functionality you didn't need too. And as soon as you have a compile/runtime dependency on external code, your compile/execution environment needs to always have access to third party code. So that's bloat and complexity. You also give up control. Hopefully it ends up saving a bunch of time over developing it internally.
Hopefully an upgrade to an external library doesn't end up including another dependancy that happens to include some backdoor that steals all the credit card information in your database. Or a crypto miner in frontend code. Or introduces a bug that stops people from being able to checkout. Or the money package starts calculating slightly differently than your payments provider... Etc. etc.
Or even just plain remove the API you were using in yet another redesign.
> I don’t get it, the dependencies are either needed or not.
Some developers' judgement about needed dependencies can be suspect though: https://news.ycombinator.com/item?id=29241943
This topic is beaten to death in Philosophy of Software Design - I really, really do recommend it.
instead of CI/CD pipelines and a million dependances, why don't we just put all of the containers, like, on one single VM? and just make it a linux box or whatever?
(presumably read in Adam Something's voice)
The usual way to deploy such things is actually to create 1 VM for that application, install podman, and then run all those tons of containers in that VM. Because you cannot trust software vendors to not do or require stupid shit like requiring the docker socket, mounting overly broad volumes from the hosts filesystem, provide working and non-stupid compose/helm/...-files and things like that. Often the support contract also requires a specific version of a specific OS, a specific kubernetes distro or something like puppet/chef/... for deployment. Since for the multitude of software vendors and requirements, we couldn't easily fulfill all those at the same time on the same kubernetes cluster or infra, we just split it up into VMs.
Indeed. For multiple reasons:
- it is not at all surprising that when you remove cruft, code performs batter
- it is not at all surprising that this is not common enough amongst software engineers to even consider these things (competing business interests probably cause this often)
Not being connected to the work VPN already slows down my Windows to a near halt since a few unreachable network drives is all it takes to make Explorer go unresponsive.
Seems like engineers forget to test these things nowadays.
If by ”nowadays” you mean the past 30 years. Slow network drives making Explorer go completely unresponsive has been a thing since Windows 95.
I’m more surprised to hear that bug still hasn’t been fixed. Luckily I don’t use Windows myself since many years ago.
HN negativity strikes again.
Can't we just read this as "there are 2 wins here: security and performance"?
Which is not surprising, but still a GoodThing(TM) right?
Totally agree. Why pick the one negative thing to say instead of saying “this should be done more often” for example. Just aggravating, as a behaviour.
All year maybe?
Once again going full-circle with the industry reinventing self-hosted software. Excuse my cynicism, I'm going back to minding my own business (reinventing design systems / component libraries, lol)
Yeah lol no shit.
> Turns out when you eliminate all network latency, things get snappy.
Same experience with JIRA. I read all these negative comments here and elsewhere about how slow and clunky JIRA was, and I couldn't relate at all.
Then I realized all those who complained was using JIRA Cloud and we were using on-prem, and it all made sense.
We've since moved to JIRA Cloud ourselves, and I understand now.
We moved and none of the new places had any viable computer room, so literally had to put the rack in a closet And well, that ain't cutting it for physical access control these days. Thankfully we have very simple flows without any BS, so not too many 1-5 second clicks to get things done.
I contracted with a company that used an on-prem version of Jira. Their instance was painfully slow over VPN and I often wondered why they didn't add more resources thinking that this was the experience for everyone. Then I went on-site for a few days and the performance was night and day. On-prem, their Jira instance was the fastest I've ever seen, faster than the cloud version and felt snappier than Trello.
On-prem is great if everyone is coming into the office, but I think orgs should pay more attention to the "remote experience" of their on-prem tools.
Just open the network tab and refresh a page in Jira and you will understand. It isn’t too noticeable on a LAN. Stick the internet in there and it is painful. The worst I have seen is self hosted and accessed over Netskope ZTNA. Truly an abomination.
It's not the refresh that screws you. It's the four goddamn dozen asyncrhonous calls it has to make after that refresh has completed to actually fill out the content of the page and let you click through stuff.
I have to load half a dozen tabs of new tickets and then cycle through them triaging and defining fields in a collated manner to make it so my time isn't hugely dominated by waiting.
We used to have on-prem and it was probably about an order of magnitude better, but still nowhere near "XP in a VM accessing a site on localhost" level snappy.
LAN? What about WFH?
I have had the opposite experience with Jira at a relatively large corporation (years ago). Our local Jira was probably just configured weird or on underpowered hardware though.
Having adopted a number of development tools, including Jira and Confluence, it’s amazing people let them sit there chugging away on underpowered machines with hundreds of users quietly complaining about the speed. Throwing some extra CPU cores and memory is so cheap for the quality of life improvement, let alone the productivity gain.
The concurrent (human) user counts at even large companies is probably a couple dozen at most.
Usually with these tools, the performance problems magically vanish if you disable all the integrations people have set up. My company is constantly denial of service attacking Jira with Github updates, for example.
Edit: typo
I delivered a complex, highly customized enterprise back-office system for a large Fortune 500 some time back. It involved a handful of servers (all as VM's), x3 to accommodate DEV/QA/PROD staging.
It worked great in volume testing in our environment. Their IT department installed it on high end servers (hundreds of cores, incredibly expensive storage subsystems, etc) but users complained of latency, random slowness, etc. IT spent weeks investigating and swore up and down it wasn't their end and must be a software issue. We replicated and completely sanitized production volumes of data to try and recreate locally and couldn't.
Finally I flew down and hosted their entire infrastructure off my laptop for a day (I'll skip all the security safeguards, contract assurances, secure wipes, etc). It flew like a thoroughbread at a racetrack. No latency, instant responsiveness, no timeouts, no hiccups. Their entire staff raved about the difference. The results gave the business unit VP what she needed to bypass the usual, convoluted channels, and someone must have lit a fire under their IT VP - by the end of that day their internal techs identified a misconfiguration on their storage arrays and solved the problem. I can only guess how many other apps were silently suffering for weeks or months on the same array. I joked I'd be happy to sell them a laptop or two for a fraction of their mainframe cost.
I had the experience for a few years of having to run all of the self-hosted development and project management tooling for a government project about a decade back, and the integrations part holds up strong to that experience. The CI system that had been put in place was probably the most sophisticated I've ever seen, but that had some unfortunate side effects like Jenkins jobs being kicked off automatically thousands of times an hour, blasting all of the Atlassian tools with network requests, or Nessus remote logging into and spawning 40,000 simultaneous processes on the servers actually hosting the Atlassian tools.
Self-DOSing is exactly what it was.
People complaining about JIRA has become enough of a trope that it mostly gets ignored.
Also big enough corps give underpowered machines to the mass of employees (anyone not a dev, designer or lead of something) so latency is just life to them.
Also that Jira is one of these mutants, between SPA and pages, doing neither well.
My company self hosts most things, which is bad for remote employees and employees in offices other than the primary because the VPN server (or possibly their network connection) is underpowered for the number of remote users. I sometimes need to wait 45 minutes for a like 1GB clone.
> Then I realized all those who complained was using JIRA Cloud and we were using on-prem, and it all made sense.
Even Atlassian doesn't use Jira cloud. Btw it's not "JIRA".
> Even Atlassian doesn't use Jira cloud.
That would explain a lot.
> Btw it's not "JIRA".
When did they change this? I'm fairly certain[1] it used to be JIRA.
[1]: https://confluence.atlassian.com/jira061
In 2013, to be specific.
Atlassian very much do use Jira cloud. Source: I worked there for 10 years. Not apologising for it's performance however.
Any inights why the performance often varies between a Model T Ford and a glacial boulder?
I mean, presumably it's subject to the two curses of modern software:-
1. Unless major customers are actively closing their accounts due to the poor performance, improving performance isn't a priority.
2. The people who pay for it aren't the people who use it, so the performance can get very, very bad before customers start closing their accounts.
Case in point: https://jira.atlassian.com/projects/ Look how snappy it is!
What a weird time to enforce British rules for acronyms.
JIRA stands for JIRA Isn't Really Awesome.
I always say Janky Irritating React App.
My chucklebone made a guffaw. Thanks!
But what does the “JIRA” in “JIRA Isn’t Really Awesome” stand for?
Same thing as the “GNU” in “GNU’s Not Unix” — it’s a recursive acronym
JIRA Is Really Awful.
True, but I try to stay positive.
That's no longer the case - a large portion of teams are now using cloud variants of Confluence/Jira.
Everytime I'm using JIRA and I type JIRA and it automatically corrects it to Jira, I hit Ctrl+Z to undo the autocorrect.
> We've since moved to JIRA Cloud ourselves, and I understand now.
Jira on-prem was dog slow, yes, especially if it didn't live on the same server as the database. But Jira Cloud? It isn't much faster than that! It's a piece of hot mess. Loading placeholders everywhere. Really I have absolutely zero idea what Atlassian is doing, but I know for sure optimizing for performance is not amongst the things they are doing.
Yeah, this whole pattern of loading a million placeholders and then watching the page awkwardly snap into layout is just sad. Especially when you know that you could have shown just as much information in a "server side rendered" piece of PHP in 2005 with less latency.
That would be Redmine.
The other thing, every pm wants a custom field just for their project, a field they’ll forget they asked for a day later. TLDR, put a governance board that’s fine saying no especially when someone inevitably pulls rank.
Myself included, JIRA is used far too much out of the box and few people ever learn what it can actually do.
Out of the box it is pretty generic. When I learned what it could actually do, it revealed itself as a sponge that can uniquely absorb complexity. Having someone familiar with JIRA show the ropes went a long way.
Some of these new development tools are pretty nice though. Variety is good, especially with the changes from Pivotal Tracker, etc going away.
We run an airgapped version of JIRA (but we are a very big company, globally distributed). Performance is in the gutter.
The annoying part is the amount of garbage fixes in JIRA's UI. For example, because of the loading speed, and me losing patience with it, if I don't wait for the page to finally finish loading and click on the "create" button, then instead of the modal dialog for issue creation, I get a whole new page for issue creation. Both options are atrocious from UX perspective (because usually I need to copy text from the issue I was reading into the issue I'm creating), but at least when it's a modal window, I can pop open the developer tools and delete the modal part that prevents me from copying the text from the issue otherwise blocked from interaction.
Also, it looks like due to speed, some queries simply don't finish on time, and randomly, searches don't find all the issues they should. Especially searches that ask for "s.t. parent issue has such-and-such properties".
Ultimately, JIRA isn't built to scale (ironically, since it's written in Java, which was always defended as being slow for small problems but scaled well). The code has a lot of assumptions about some operations being fast enough to not require buffering / incremental implementation. And sometimes you hit the combos of such unoptimized operations and have to wait minutes for the program to respond.
Our org used Jira on-prem for 2k engineers and 3k additional staff and it was slow as molasses.
The dialogues and context menus took forever to show and page navigation was beyond painful.
We had dedicated engineering for maintaining our Jira and Bitbucket, and they still fell over. We eventually moved back to GitHub. (Our usage went from GitHub on-prem pre-MS -> Bitbucket on-prem -> GitHub cloud post-MS.)
I hate Jira regardless of where it's deployed. It's a beast.
We run a full Atlassian suite on prem for 5k users and it works really well
Well except Bamboo. It’s terrible
> cloud-only tools like Jira.
But Jira is not cloud-only?
https://www.atlassian.com/enterprise/data-center
They've removed it from their pricing page now, but when they announced the discontinuation of the regular on-prem server the minimum for datacenter was like 500 licensed users or something along those lines.
In any case it was clear it's not for small shops like us.
That said, air-gapped is a hefty requirement, so perhaps those customers are predominantly large?
> That said, air-gapped is a hefty requirement, so perhaps those customers are predominantly large?
There are lots of very small classified networks out there with only a few dozen users.
There are a lot more user communities course that aren’t necessarily airgapped, but where they have special compliance requirements that pretty much mandate self hosting (or at least bring-your-own cloud.)
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.
Good approach IMHO.
We do the similar with our B2B product (in an entirely different niche). We have everything from single-person companies up to very large ones. Similarly we set price based on use-case and requirements.
It's still on this page: https://www.atlassian.com/enterprise/data-center/jira
$51k for the smallest license they offer.
I still run an old version on an air gapped network and will continue to do so until we're forced to change for some reason. It's not a hefty requirement; we run it for a team of < 10 developers on a small VM and it just works.
Blind as a bat, thanks. Was looking for a pricing page or similar, totally scrolled by that box which looked like marketing fluff.
$$$$ Very expensive
Atlassian actually threatened to sue our company if we didn't move from on-prem to cloud. I imagine they're doing the same to others
Sure if you commit to a 500 user minimum.
It might as well be for the vast majority of companies, since I believe the smallest number of users you can buy support for is 500.
To be more specific, they killed off the legacy Jira Server and now only offer these enterprise versions of Jira and the rest of the suite if you won't move to the cloud.
How do you handle compliance in confirming that the product is only used for the license duration? (Or is it more of a one time purchase plus recurring fee for updates?)
At this level (govt, 6 figure+ deals) I would at least consider if this problem should have a non-tech solution, and instead have a legal/lawyer solution. In my experience (not US based though) the govt contracts are under compliance programmes as well so the govt agency’s legal/contract mgmt team would probably follow up internally on expiring contracts (ie licences) and require the owning stakeholder to either renew the contract or abandon the software. Meaning the customer would supervise itself regarding licence. But even if you don’t want to rely on self-supervision then having your lawyer spend 1 hour reaching out with a “do you need to renew your licence” at the end of a licence term would probably be much cheaper than building and maintaining an air-gapped licence solution.
Years back a friend of mine's startup failed when USAF pirated their software and the original customer org stopped paying for it.
Feds are DMCA immune, so no real recourse.
This seems very suspect.
Usually you do have recourse via procurement channels and reps. If you file a complaint with that agency stating that they’re using a license without paying for it, it will result in at least an investigation.
If you got to hire the cops to investigate your own mistakes, would you hire competent, motivated folks who'd leave no stone unturned and get access to every classified, air-gapped network in search of license infringements?
I wouldn't. I'd hire some Peter Gibbons type, who only does about 15 minutes of real, actual work in a typical week. Then I'd tell them they can finish early if all their pending cases are closed.
Practically the federal government shouted, Neener neener neener! Rules for thee but not for meeeeeee!
https://arstechnica.com/tech-policy/2008/08/air-force-cracks...
https://arstechnica.com/tech-policy/2008/08/air-force-cracks...
Hopefully this was fixed, but this was the standing precedent at the time.
As soon as I saw that he put it on the employer machines at his own work before locking down a sale, they'd screw him whether he deserved it or not.
Sounds like having only one paying customer was the real cause of the business’s failure.
They've mentioned that was a valuable lesson.
Surely that would fail any kind of security or compliance audit?
Largely agree but I want to challenge this bit at the end.
> probably be much cheaper than building and maintaining an air-gapped licence solution
I think this is an unwise attitude to take. There's something to be said for a simple picket fence. Even though someone could easily hop it if they wanted to, they lose plausible deniability and in most cases that's all that really matters at the end of the day.
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
But you didn't tell us how many orders of magnitude more expensive it is to operate :)
Itar ruins all the fun
>our air-gapped deployment actually runs faster than our SaaS version. Turns out when you eliminate all network latency, things get snappy.
Notion, take notes
"air-gapped" self hosted app.
It used to be the default that self hosted apps didn't telemetry and call home.
I feel there's more than one self hosted foss jira alternative around already, that of course wouldn't telemtry or call home.
Some I used in the past:
https://www.redmine.org/
https://phacility.com/phabricator/ no longer maintained :-(
Phrabricator lives on in Phorge, which is seeing active contributions.
I haven't used Phorge, but Phrabricator is easily my favourite tool among the source code portals. The code review system actually works and does not make me tear my hair out. I am completely at a loss why the commercial side of it seemingly failed after all those years, when products such as Bitbucket and Gitlab seem to do well.
I think we have different definitions of the term "air-gapped". Users still very much connect to it using a network. This just doesn't phone home (or elsewhere).
A truly airgapped Jira-alternative would be somewhat impractical.
I am also building https://docmost.com, a self-hostable Confluence alternative that can run fully air-gapped.
It has support for spaces, real-time collaboration, a rich-text editor, built-in diagrams support and more.
We launched on HN 1 year ago: https://news.ycombinator.com/item?id=40832146
What does your enterprise pricing look like?
There is no price anywhere. I would be interested to use that for either my job or for private projects, but where and how much do I pay?
Edit: I looked again and even your pricing pages have no price. I understand that you may want to restrict yourself to rich companies, but I don't understand the point of posting on HN if that's the case.
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.
Air-gapped probably adds a zero or two to the highest tier Enterprise price. You wouldn't buy an Enterprise license for a personal project, why would you buy an Enterprise++ license (which is essentially what AG is)?
It's part of the Business tier on the pricing page here: https://plane.so/pricing
A version of JIRA that nobody can access sounds pretty good
Running software in an airgapped environment is difficult, but the hardest thing is the install, packaging and shipping updates. I have used https://zarf.dev/ to do this for a government client, and it was an amazing experience. I highly recommend it. K8s seems heavy, but if you want to run datastores with backups (k8s operators), or highly customised environments, and automate all of that, instead of loads of bash and custom code, it shines.
I just learned air-gapped includes private networks. I was under the impression this strictly meant isolated non-networked computers. Was this always the case or has the term diluted over time?
Strictly speaking, air-gapped originally meant physically isolated, no network connections at all. But in practice, the definition has broadened a bit, especially in enterprise and defense settings.
Today, it may include closed private networks with no internet access, still isolated, but with internal connectivity for practical reasons (like backups, logging, or internal auth).
Pfft! Truly air-gapped would be each key on the keyboard physically unconnected to anything else. True security.
I think it just depends on the context you're talking about. Air gapped just means there's no connection between two things so it could be talking about networks or individual computers.
In my circles we include private networks going back at least 15 years. So maybe diluted, but if diluted, at least not new.
I work on an air-gapped network. The most important thing that the words "air gap" communicate is that there is no connection, nothing at all, to anything outside the network. The only way to move anything on or off are using disc drives (no USB for security reasons). The word "private network" does not really communicate that there is a physical gap of no wires at all from the computers on the network and everything else on the internet.
AGPL continues to be the future of F/OSS
https://vadosware.io/post/the-future-of-free-and-open-source...
Dread it, run from it, AGPL still arrives. Sustainable F/OSS is the most likely to-still-be-active-5-years-from-now kind of F/OSS.
This also makes it infinitely more useful for healthcare. Not healthcare software specifically. Lots of use cases in logistics, irl maintenance, etc. Patient data creates hipaa challenges and tends to overflow into any system.
Nothing in HIPAA mandates air gaps. In the context of HIPAA that's really overkill.
In fact, self-hosting might even do you wrong when things go bad, because AWS is probably better managed and more secure. And they have all their certs, which is legally important.
+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.
Why would a health care org care about air-gapped deployments? Most (really, almost all) health care data is stored on cloud SAAS databases already; for people who care, this vendor already had an on-prem version.
What you say makes sense, but I think there can be reasons. For our military customers we offer an air-gapped version of our app early on because it was easier for customers than getting an ATO. Also as a bootstrapped company it was a lot cheaper than FedRAMP. I'm guessing I'd lean on a similar strategy if I had a health care startup.
Most health care companies get along just fine in AWS, just for what it's worth.
They make it seem like a big deal. It’s pretty much how all software used to ship :)
Both those things can be true at the same time: all software used to ship like that, and shipping like that in the current era _is a big deal_.
Spoken as someone who's core differentiator is "self hosted" [0]
[0] https://www.bugsink.com/
Yes, absolutely, in a way, we’re just bringing back the old-school model — full package, zero dependencies, runs on your own infra — but with modern tooling and UX.
I've heard they're planning to ship it with printed documentation some time soon!!
Big fan of Plane since it's open-core.
Doesn't seem to be a lot of options for self-hosted/open-core project management software. The existing ones looks pretty bad, and don't come anywhere close to Jira level functionality.
> don't come anywhere close to Jira level functionality.
In my experience that's probably a good thing. I've moved from a company using Phabricator to one using Jira. Phabricator had exactly everything we needed and was very nicely designed and worked really nicely.
Jira has everything you need plus loads of other stuff that project managers feel like they need to add. Oh and they'll never clear anything up or fix any config bugs because they don't actually have to ever use the "report bug" form so who cares if there are 100 fields and half of the mandatory ones are hidden in "More fields"? 5 different states for "TODO"? Eh who cares. 3 different ways to say which team a bug is in? Better fill them all in for every bug.
It's better to be missing features than to have features that project managers can configure.
I've used both as well, I found Phabricator fine for lightweight kanban-style team work tracking, but once we had PMs it was doomed because it would never do what they wanted (they didn't seem to be able to understand that it was not a Scrum system and would never match well).
These days I'd be using Github instead, issues there are also nice and simple. I imagine it would ultimately suffer the same fate in a similar situation though (not that I intend to get there ever again).
The problem with Jira is that it's so customisable and always ends up being customised by "process people" who think all problems can be solved by adding just one more field - but simultaneously it's never possible to customise your bit to work the way you want.
The first bug you should log is that the bug logging page has unnecessary fields.
Redmine is awesome
We wanted to host on prem a few years ago. Plane was around at the time but didn't look like a mature enough solution. On the other hand, our Redmine instance was far too "mature." We went with YouTrack since it had a highly customizable import plugin for Redmine.
> Even with our robust self-hosted option, we kept hearing the same feedback from legal and compliance teams: "Private cloud" solutions that still require Virtual Private Network (VPN) tunnels don't meet their stringent requirements.
If it has a VPN tunnel to some outside server, you shouldn't really call it "self-hosted*
Self-hosting implies the software runs on the customer's own servers, but phone-home license checks (or analytics, or whatnot) is not unheard of.
I think it’s hilarious that this is something they specifically had to do, and was apparently hard?
All my software works fine in completely air-gapped environments.
When you add features such as telemetry, curl calls in install scripts, and in general build on public cloud infra, everything assumes you have internet connectivity. That assumption is so crucial that it is embedded in everything and touches most software components. When you already have an established product, I imagine changing it to remove the assumption without a full rewrite can be tricky.
Yes, agreed, if you build with air-gapped in mind from day one, it should just work. In our case, we had to unwind a bunch of assumptions baked into modern SaaS: license checks, analytics, image pulls, update pings… even small things like font hosting or third-party embeds needed rethinking.
Not hard in principle, just a lot of invisible cleanup to make it truly self-contained. Learned a ton doing it.
Ehm, fairly sure you can use Jira in an air-gapped environment.
from Google: "Atlassian has sunsetted its Server product line, including Jira Server, meaning they are no longer supported and users need to migrate to Cloud or Data Center versions. Specifically, support for Atlassian Server products ended on February 15, 2024. This includes the end of new license sales, renewals, and security updates for Jira Server. "
There's the self-hosted Atlassian Data Center product.
https://www.atlassian.com/enterprise/data-center
They also offer Government Cloud.
https://www.atlassian.com/government
You'll pay through your nose for a Data Center license though, and it doesn't change the fact that Jira is a mess so slow that SAP can appear fast in comparison.
Data center version is available. I use it.
Looks like they only support single node deployment at the moment.
Having worked with airdropped software packaging, next step is a multi node setup.
We use Plane. It's acceptable. Not great, not terrible. Jira wanting 26k per year, per customer we have was unacceptable.
I wish their docker deployment was normal (only docker-compose.yml), not a shell script that launches docker.
It needs ldap auth and better search capability (fts, boolean, filtering).
UI is clunky; everything is editable all the time, so you might end up accidently editing the ticket contents.
This is totally a tangential point. Why do they call it "air gapped" instead of "air tight" ? Are these supposed to mean different things ?
You can have an air gap between two physical items - it doesn't matter if those physical items are air tight or not. Air gapped doesn't mean the items are prohibited to intake air (i.e. air tight), it just means they're prohibited to intake things _apart_ from air.
Old man talking about both ways up hill:
Historically, we did not have wifi and other radio based new fangled data communications. Data connectivity required wires, physical connections. If there was a gap between the two devices that had no wire, just air, that was air gapped. No comms could happen between the two. It is physically isolated. it used to be called "physically isolated" when we used it in the 80's (?). Some say, we stole it from plumbers but that is hogwash (pun intended, you know the backflow prevention thing). I vaguely recall start seeing it late 1990's to 2K in the public?
Mission Impossible 1996 the computer in the room where tom cruise is lowered into the room. That was an example of 90's air-gapped system.
The name stuck because it sounds cool. In my opinion, there is no such thing as true "air-gapped network" any more. There are too many ways to snoop on systems that are isolated, without "physical" and radio connections in the traditional sense (e.g., listen to the "electricity", sounds, power fluctuation, ground vibration, squirrel squeeks).
Airgapped systems have an air gap between the system and the wider world. The only way to move data to and from them is for someone to walk across the gap with physical media.
There are no communication cables between the host system and the wider world.
There are other ways, of course.
* air-gap malware can be designed to communicate secure information acoustically, at frequencies near or beyond the limit of human hearing.
* In 2014, researchers introduced ″AirHopper″, a bifurcated attack pattern showing the feasibility of data exfiltration from an isolated computer to a nearby mobile phone, using FM frequency signals.
* In 2015, "HELLONE", a covert signaling channel between air-gapped computers using thermal manipulations, was introduced. "BitWhisper" supports bidirectional communication and requires no additional dedicated peripheral hardware.
* Later in 2015, researchers introduced "GSMem", a method for exfiltrating data from air-gapped computers over cellular frequencies. The transmission - generated by a standard internal bus - renders the computer into a small cellular transmitter antenna.
https://en.wikipedia.org/wiki/Air-gap_malware
Don't forget Stuxnet which crossed the airgap via infecting USB Devices.
https://en.wikipedia.org/wiki/Stuxnet
Any more details about the offline patch/upgrade process? When I looked at gitlab years ago, it handled that fine but the documentation seemed "nervous" about it.
You'll find all the docs here: https://developers.plane.so/self-hosting/methods/airgapped-e...
I struggle to think why that would be any drama, unless the setup is trying to use "bare" gitlab (e.g. running the puppet commands manually versus $(docker save -o airgapped_gitlab.tar gitlab/gitlab-ce:18.2.0-ce && cp ./*.tar /dev/disk/usb-whatever/goodluck/))
just a fyi for anyone looking for a neat little kanban board, gitea has kanban built-in into the projects feature.
(obviously lacks really fine-grain customization that would be found in other jira alternatives)
And the gitea fork, forgejo does too.
HCSB in the image? Copyright dodging?
From the table:
> Component: Telemetry
> Cloud / Self-Hosted: Opt-in analytics
> Air-Gapped: Disabled by default
What's the difference?
I guess my mental model is all wrong but those air-gapped choices - they seemed kind of what is natural to do …
Most self-hosted apps, including jira, can be airgapped. Yeah maybe it's not made super easy like Plane, but any org that requires this is going to have an IT department that can handle it.
> This post explores the journey of building this specialized deployment option for regulated industries where data sovereignty isn't just preferred—it's mandatory.
This is an AI writing tell: "It's not just x—it's y."
https://youtu.be/9Ch4a6ffPZY
It's an AI writing tell that was copied from so many of us who use it.
I loathe every cheap throwaway comment like this.
Know who else uses punctuation? People who write. In fact, that's where the AI got the idea.
To be fair, “not just X—it’s Y” showed up in product marketing way before AI started parroting it. Just saying. :)
Buy-and-forget perpetual pricing for internal networks, please.
Don’t want to pick up annual subscriptions, and don’t want any dependency on a third party company that might not last or will start doubling prices in the future after an acquisition - been burned heaps by that.
As a DoD employee, it would be amazing if more companies took this seriously (I'm looking at you health tech bros).
No, no you do not.
A week into installation, your cube mate will be complaining that the arrow keys do not work as used to and cannot use alt-tab on the fields, or the color orange and green make their eye hurt. So a ticket is opened, a software update is made, and then the patch is generated. That is 12 month on a good day because all the back track, re-validation, scope creep, auditing, re-validation, third party review, committee blessings, and good idea fairies.
Then you have to get the patch into the environment. Now you need a blood oath from the entire chain of command up to Katie A. where she swears she is going to beat you if you whine about the color scheme again. ;) Three years past, and the changes are implemented. It does not matter because your monitor which had to be TAA compliant and could not be brought in without you soldering everything together is now running off of a hercules video card, yes that green only hercules card. You see only shades of green in the app...
Really appreciate that — and totally agree. We’ve been surprised by how many teams in defense, healthcare, and critical infrastructure are still stuck choosing between bloated legacy tools or cloud-only products that don’t check the right boxes.
We built the air-gapped edition of Plane exactly for this.
I do take this seriously (see link in my profile), but have to admit that doing so isn't an automatic entry tickets to places like the DoD
It was shocking, talking to the Jira rep. They basically said they didn't want this sector's business.
This is just shipping a docker container for people to run the app on their own infrastructure. Retool does the same thing for companies which don’t want to expose internal resources and databases to the cloud.
Jira has a self-hosting option. It already is air gap ready. See Jira Data Center.
1. https://www.atlassian.com/enterprise/data-center/jira
TBH, if I were working in such a highly regulated industry, I'd be very hesitant about buying software from a company with a .so domain and basically beholden to the whims of the government of Somalia.
If they said "implement a backdoor for us or all your non-airgapped customers lose access tomorrow", are you sure the company would be able and willing to say no?
Totally fair to ask.
.so is widely used by software companies as a domain availability solution - think Notion. For regulated environments, the domain doesn’t matter, the architecture does.
With air-gapped deployments, Plane doesn’t rely on any external DNS or domains — .so or otherwise. No license pings, no telemetry, no outbound calls. Everything runs in complete isolation, and customers have full control over the environment.
Also worth noting: Plane’s open-source core (AGPLv3) allows for full transparency and auditability. So any notion of a backdoor is counter to how we operate — and how our users deploy us.
That's a very odd thing to bring up in the context of self-hosting, since you would not interact with their .so domain whatsoever; ensure that the AGPLv3 aligns with your needs, git clone -b v0.27.1 https://github.com/makeplane/plane.git and be happy
Given their customer base, I wonder why they bothered with any license enforcement for the pure on-prem. Just do the "license enforcement" implicitly when customers want to update: they need to log in to get the new image.
(Your regular annoying notice that FIPS-compliant crypto is, if anything, marginally less secure than non-FIPS crypto; not that it matters in any material way, just, it's not a flex.)
the air gapped Jira alternative for regulated industries is a big white board
We ran our company on a whiteboard, until we couldn't, so I get it.
And honestly it does beat a lot of bloated tools out there. But when you need permissioning, history, workflows, audit logs—and your infra lives in a bunker—we try to be the next best thing.
Air-gapped, fast, and without the Jira bloat.
HCSB?
Now do an air-gapped Confluence killer, please.
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...
https://github.com/docmost/docmost