Enterprise Kubernetes distribution
Bahriya Kubernetes Engine. A distribution that makes exactly two decisions.
The network fabric and the Kubernetes version, pinned to the exact patch. Everything above them is yours to choose — which is the difference between a cluster you own and a platform you rent.
self-service · no sales call · no payment details · one command per node
The engine behind bahriya.cloud — our own public cloud, in production across multiple regions.
$ ./install.sh --version 2.0.0 --commit
network fabric pinned
kubernetes pinned
✓ control plane up — 1 of 3
$
The argument
Most distributions are platforms wearing a distribution's name.
OpenShift, Rancher and Tanzu decide your storage, your ingress, your mesh and your monitoring before you arrive. Each of those decisions is one you still operate and still pay for, whether or not it suits your estate — and when it does not, you run a second ingress beside the one you were given and investigate every failed request twice.
BKE does not put you there, because it never makes that choice on your behalf. It decides the network fabric and the Kubernetes version. It decides nothing else.
The two decisions
Both pinned. Both fixed for the life of the cluster.
Decision I
The network fabric
Calico, at an exact patch we have tested against everything else in the release. The fabric is the one layer nothing above can route around, so it is the one layer a distribution must own.
Decision II
The Kubernetes version
Upstream Kubernetes, no fork, no proprietary CRDs — pinned to the exact patch. Upgrades move one version at a time; a non-adjacent jump is refused, not warned about.
Everything above them is enabled, not endured.
components.<name>.settings.enabled: true — one line eachThe licence gates BKE, not parts of it.
Determinism
The same version installs the same cluster. Twice.
A release is a set of promises about which versions work together. BKE keeps those promises mechanical rather than aspirational.
exact-patch pinning
Nothing floats.
Two installs of one BKE version, two months apart, produce the same cluster — not whatever upstream happened to publish that morning.
mirrored artefacts
Every chart and image, held by us.
A release installs from artefacts we mirror and serve. An upstream registry outage, rename or retag cannot change what your cluster runs.
blast radius
Upgrades are classified before they run.
Every upgrade declares what it will touch. A patch never drains a node; anything that would is named as such before you commit to it.
configuration you own
Your values are a file, and the diff waits for you.
Every component's configuration is a file you own and may edit; upgrades show you the difference between yours and ours, and wait for you to agree.
The platform step
A cluster when you want a cluster. A platform when you want more.
BKE is deliberately not a platform — that is the point of it. But a platform is one pairing away, and it is a pairing we run ourselves.
BKE
The engine.
Two decisions, pinned to the exact patch: the network fabric and the Kubernetes version.
your components
A production cluster.
Storage, ingress, certificates, mesh and observability — enabled one line each, only the ones you want.
Enterprise Helm Charts
A platform.
Production-ready MySQL, Valkey and message brokers, with replication, backups and upgrade paths already decided.
That pairing is what runs bahriya.cloud — the ground OpenShift occupies, assembled from parts you can name, version and keep. How the platform step works →
Ownership
Nothing of ours sits in your data path.
The licence gates install and upgrade. Nothing else.
A running cluster keeps serving if the licence lapses or we are unreachable. There is no callback in the request path, no agent that production waits on.
Reporting is declared, small, and gates nothing.
What a cluster reports is a short, published list of fields. It exists so your console can show you your own estate — it is telemetry, never permission. Every field, listed →
Support by ticket, wherever you run.
Support is ticket-based with a 24/7 tier available — and because nothing in production ever waits on us, a ticket is about progress, not permission. Delivered by Mamluk, the engineering practice that builds BKE.
BKE is not a product we assembled to sell. It is the engine our own public cloud runs on, licensed for your data centre.
in production at bahriya.cloud
Pricing
One flat fee per cluster. The end of the arithmetic.
OpenShift and Tanzu are licensed per core, which is why their quotes grow every time your cluster does. BKE is licensed per cluster, whatever its size — add capacity and the licence does not move.
Put in the unit your other quotes arrive in: on an eleven-node reference cluster, the flat fee works out to US $83.33 per worker core. Substitute the rate from the quote in front of you and compare.
GET mamluk.net/data/bke-pricing.json
US $12,000/ cluster / year
Flat. Irrespective of node count, CPU or memory. Support & maintenance contracts on request.
The field
Named comparisons, not a feature matrix.
Each of these is good engineering. Each is also a different answer to the question of who owns your cluster's decisions.
Red Hat OpenShift
The complete platform — every layer decided, integrated and licensed per core. The ground BKE occupies with parts you can name, version and keep.
BKE vs OpenShift →SUSE Rancher
A manager of many clusters with RKE2 underneath — strongest where the fleet is the problem, not the distribution.
BKE vs Rancher →VMware Tanzu
Kubernetes shaped to the vSphere estate, licensed accordingly. Compelling exactly as far as that estate extends.
BKE vs Tanzu →Sidero Talos
An immutable, minimal OS-up distribution — a serious and different philosophy about what you should own, starting below the operating system.
BKE vs Talos →Documentation
The documentation, before you buy.
Everything an engineer needs to evaluate BKE is public — the same pages our customers operate from. Release notes and exact version pins accompany the licence, in the console.
01How a cluster fits together
Control planes, workers, and what each BKE command does on which machine. Start here if Kubernetes is new to you.
02Before you begin
What each machine needs, what BKE reaches over the network, and the three decisions you cannot change afterwards.
03Register your cluster
Binding a licence to the machine that will be your first control-plane node, before anything is installed.
04The first control-plane node
kubeadm init through install.sh, and the arguments that are fixed for the life of the cluster.
05Adding nodes
Provisioning the remaining control-plane and worker nodes, and joining them to the cluster.
06config.yaml
The one file that describes your cluster, key by key, and what each one's absence costs.
Fourteen days, no sales motion
Evaluate it the way you would evaluate open source.
Create an account in the console, issue yourself a trial licence, and paste the registration command onto your first node. Nobody will call you — and the engine you evaluate is the one serving bahriya.cloud today.