Why so many teams are quietly failing at security and reliability and why we decided to think open source differently.
Installing open source software has never been the hard part. Any competent engineer can get a cluster running, a server provisioned, a pipeline green, in an afternoon. The hard part starts the moment something real comes to depend on what you built, and it stays hard for as long as that dependency exists.
Most people never do the math on what that actually requires. So they don't realise how big a task they've taken on, or how far short of it they're quietly falling. Here's the math.
When you rely on something, you need to be able to bring it back if it breaks, ideally fast, because downtime gets expensive in a hurry. So you document how you built it: the steps, the versions, the configuration choices. That documentation is meant to be your insurance policy.
The trouble is, the world doesn't hold still long enough for that policy to stay valid. Every open source project you depend on ships new releases. Defaults change. APIs change. The way you'd build something today rarely matches the way you built it a year ago. Your documentation drifts quietly out of sync with reality, and there's no alarm bell for it; the only thing that would actually reveal the gap is trying to use that documentation to recover, which is exactly the moment you've been trying to avoid. Your system "still works," so nobody looks closer. The gap only becomes visible when you actually need to rebuild, at which point it's no longer a documentation problem; it's an incident.
One way to insulate yourself from this constant drift is to stop depending on the internet being exactly as you remember it. You keep a complete, working copy of everything you need, every package, every image, every dependency, inside your own production environment. This is an airgapped setup: recovery that doesn't require anything outside your own walls to still be there, unchanged, the day you need it.
Plenty of teams attempt this. Very few get it fully right, because "everything you need" is a longer, more specific list than it looks like on day one, and it grows every time you add a component. The teams that get it wrong rarely find out in a calm planning meeting. They find out mid-incident, scrambling for a workaround while the clock runs.
Then there's the data itself. Backups exist so you can actually recover, once you've worked out how the world has changed since you last installed everything, or, if your airgap actually holds, simply repeat the install as it was. Either path runs into the same complication: the constant, public stream of newly disclosed vulnerabilities (CVEs) forces you to patch and upgrade components, quietly and piecemeal, usually under deadline pressure, without anyone circling back to update the documentation or the recovery plan to match. Even a technically sound backup strategy still leaves you reverse-engineering what changed before you can use it.
To get ahead of this, many teams back up entire environments and tools like Velero for Kubernetes make that practical. It's a real improvement. But it solves only half the problem if nobody tests it. Backups fail for dozens of unglamorous reasons: a misconfigured snapshot policy, a quietly broken cron job, a permissions change nobody noticed. Very few organisations run regular, randomised recovery drills to catch this before it becomes a problem. Hence, the backup sits there, trusted and untested, and the one time its failure gets discovered is the one time you actually needed it.
Security follows the same pattern of false confidence. When you get attacked, it's through something accessible: a service exposed to the internet, or more often than most people assume, a service reachable from inside your own network. By many estimates, roughly two-thirds of attacks don't come through the services you've deliberately exposed at all. They arrive from inside, through a laptop compromised by a phishing email or a careless click, already sitting on a network you trusted.
Once an attacker has a foothold anywhere, they use it to reach the next thing, and the next. That's exactly why every exposed service, public or internal, needs to be firewalled down to the principle of least privilege: able to do only what it strictly needs to do, on the network and on the host it runs on, and nothing more. Doing this properly for even a handful of services is already complex. Almost nobody does it for all of them.
None of this is exotic. Documentation that stays true. An environment that doesn't depend on the internet behaving itself. Backups you've actually tested. Services are locked down to the minimum required privilege. These aren't bureaucratic checkboxes; they're the literal layers of defence that frameworks like ISO 27001:2022 are asking you to put in place, alongside CIS18, GDPR, NIS2, and the rest of the compliance landscape that's grown so quickly in recent years. Taken seriously, compliance isn't a binder you produce once a year for an auditor. It's the ongoing, unglamorous discipline of actually having these layers and maintaining them continuously, while everything around them keeps changing.
Here's what makes all of this so expensive: none of it is delivered by any open source project you can simply download. It lives entirely in the implementation, in the thousand specific decisions about how everything gets wired together. And because there's no shared answer, everyone builds their own.
Take something as ordinary as running PostgreSQL on Kubernetes. There are more than eight popular operators to choose from, each with its own opinions about backup, failover, and upgrades. Multiply that choice across every other piece of the stack: ingress, secrets, certificates, monitoring, and identity. You get an entire industry independently assembling its own unique combination, and therefore independently solving the same security and reliability problems everyone else is also solving, alone, usually for the first time, usually under pressure.
This is why even large, well-resourced companies fail at this constantly, not occasionally. Smaller companies often don't even know they're exposed, because nothing has gone wrong yet. And it's a meaningful part of why ransomware and crypto-locker attacks succeed as often as they do, not because attackers have gotten unusually sophisticated, but because almost everyone is quietly carrying this work alone, underestimating exactly how much there is to get right.
Open source has already solved half of this problem, brilliantly. Nobody has to write their own database engine, container runtime, or ingress controller from scratch; the code is shared, maintained collaboratively, and the whole industry is better for it.
The other half, knowing, in granular detail, what it actually takes to run that code securely, reliably, and defensibly, has stayed stubbornly private. Every company has been left to rediscover it on its own, the hard way, usually after something has already gone wrong. The same lessons, learned and re-learned, company by company, behind closed doors, for decades.
That's the half we decided to stop treating as a private problem. The implementation details for security, reliability, and compliance are the same hard work no matter who's doing them, so there's no real reason they can't be solved once, collaboratively, and maintained on an ongoing basis, the same way the open source projects underneath them already are. That's what we mean when we say think open source differently: not just sharing the software, but sharing the operational maturity it takes to run it responsibly.
This is the idea behind KubeAid for Kubernetes and LinuxAid for Linux servers and VMs wherever they run. Both are open source. Both exist to take the parts of running infrastructure that everyone needs. Almost nobody wants to solve alone: single sign-on, zero trust, least-privilege configuration at the network and OS level, and a working, continuously maintained mapping to ISO 27001:2022, CIS18, GDPR, NIS2, and beyond. Instead, turn them into shared, collaboratively maintained work rather than a thousand private reinventions.
KubeAid does this through GitOps: your cluster configuration lives in Git, changes are reviewed before they ship, drift is detected automatically, and the relentless churn of upstream updates and security patches arrives as something you deliberately pull in, instead of something you scramble to chase. LinuxAid carries the same philosophy to Linux servers and VMs. Neither locks you in. Everything runs on your own infrastructure, under your own control, exactly the way open source is supposed to work.
The goal was never to replace the open source ecosystem everyone already relies on. It's to stop everyone from separately, expensively, and incompletely solving the part of the job that was never really about the software in the first place.
I've spent thirty years building and operating infrastructure for organisations where getting it wrong simply wasn't an option. The lesson that's followed me the whole way has always been the same one: installing the software was never what kept me up at night. It was everything that came after: the documentation nobody had time to update, the backup nobody had tested, the service nobody had gotten around to locking down yet.
I watched good teams at good companies quietly carry that same risk for years, simply because nobody had ever framed it as a shared problem rather than a private one. Open source taught this entire industry that we didn't need to reinvent the database or the operating system alone. I don't see why we should still be reinventing the work of running them safely, alone, either.
That's the whole idea behind Obmondo, KubeAid, and LinuxAid. Solve it once. Maintain it together. Everyone benefits.
— Klavs Klavsen, Founder & CEO, Obmondo
If this is a problem you're tired of solving alone, the code and the collaboration are open.
Obmondo · KubeAid on GitHub · Obmondo on GitHub
We built KubeAid and LinuxAid because we believe that operational maturity should be shared, not hoarded. But every environment is different, and the implementation details matter.
If you're wondering how this fits your specific stack, or if you'd simply like to talk through how we approach the layers of least-privilege, airgapped recovery, and continuous compliance, we’re happy to have that conversation. No sales pitch—just a discussion about the hardest part of IT.
Talk to us when you're ready.