Open source

We maintain it once. Everyone running it benefits, including you.

Kubernetes patches a release for about fourteen months, and a new release lands three times a year. Every chart on top of it moves too. Obmondo does that work once, in the open, for everyone running the same stack, which includes you whether or not you pay us.

128charts maintained for everyone
3 a yearKubernetes releases to keep up with
~14 monthsof security patches per release
AGPL-3.0the platform licence
The arithmetic

Going your own way costs the same as everyone else, paid alone.

Follow the community and your upgrades are ones somebody else already survived. Go your own way and every one of them is yours alone. So KubeAid vendors the chart each community publishes and diffs every update against upstream instead of keeping a fork of its own. LinuxAid shares the same bargain on the server side: the patching and re-testing lands once, for everyone running it.

What that buys you

Upgrades someone already hit

A breaking change reaches us on the first cluster that sees it, and the fix lands once for every cluster running that chart.

Fixes that go back upstream

We report what we find and work it out with the project, so a local patch stays the exception rather than the plan.

No private fork to feed

Standard Kubernetes, standard charts, your own Git repository. Leaving means keeping the repository you already have.

Implementation

The community picks the tool. It does not tell you how to run it safely.

We follow the community on which solution to use, and best practice on how to implement it. Almost every backup ends up in an S3 bucket, and choosing S3 tells you nothing about noticing when the backup quietly stops. The job fails, the schedule is deleted, and the bucket keeps serving last month. Turn on the KubeAid backup exporter with your S3 credentials and it alerts on each of those, including a backup older than the RPO you set, so the gap surfaces before a restore does.

Curation

Ingress can be done ten ways. That is the problem, not the feature.

Combine a dozen defensible picks and you own a combination nobody else runs, with every seam between them yours to debug. What decades of this buys is knowing which combination survives.

How a choice gets made
01

Features first, then the community

Many options tie on features. The tie goes to the larger and more active community, because that decides how fast the next problem gets solved.

02

Ship several where only taste differs

Graylog, Loki, OpenObserve and OpenSearch all ship for log monitoring. Picking a winner there would buy nobody anything.

03

Change it when it turns out wrong

We ran the Zalando PostgreSQL operator and are moving to CloudNativePG. Writing the choice down is what made the change explainable.

The document

Decades of experience, with the reasoning left in.

Why GitOps with Argo CD rather than Terraform, Ansible or Pulumi. Why Helm despite its faults. What we got wrong and changed. Written for people making the same calls.

Bring us the stack you are tired of maintaining.

A 30-minute call with an engineer who runs this in production. Come with the upgrade you have been putting off.