Bahriya Kubernetes Engine

Bahriya Kubernetes Engine is the only enterprise Kubernetes distribution built, owned and supported from within the GCC region itself — and it is a deliberately different kind of distribution.

Most distributions decide everything for you, which is what makes them a platform you rent rather than a cluster you own. Each of those decisions remains yours to operate and to pay for, whether or not it suits your estate.

Ingress is the clearest example. OpenShift ships its own HAProxy-based router as the way into the cluster, and it is perfectly good at what it does — terminating TLS and routing a request to a service. But that is frequently not what a production estate actually needs. There is no plugin model, and no first-class rate limiting, authentication, request transformation or response caching. So teams do the only thing left to them: they install a second ingress in front of, or beside, the one they were given — NGINX, Kong, an API gateway — and run both. That leaves two ingress paths, two certificate configurations, two places to investigate a failed request, and a licence that still includes the router they no longer use.

BKE does not put you there, because it never makes that choice on your behalf. It makes exactly two decisions: the network fabric and the Kubernetes version. Both are pinned to an exact patch, so the same BKE version installed twice, two months apart, produces the same cluster — not whatever upstream happened to publish that morning.

Everything above those two decisions is yours to choose. A cluster becomes capable of carrying production by enabling the components you actually want, one line each: Longhorn for replicated block storage, Kong for the gateway, cert-manager for certificates, Kuma for the service mesh, Fluent Bit for logs, Netdata for monitoring and metrics-server for autoscaling signals. Enable what you need and leave out what you do not. There are no editions and no feature flags: the licence gates BKE, not parts of it.

That gives you a cluster that can run production. A platform is the next thing up — production-ready MySQL, Valkey, message brokers and the rest, with replication, backups and upgrade paths already decided. Pair BKE with Bahriya Tersane and you have exactly that: the same combination that runs our own public cloud at bahriya.cloud, occupying the ground OpenShift occupies — but assembled from parts you can name, version and keep.

And it is supported from here. Every other meaningful distribution — Red Hat OpenShift, SUSE Rancher, VMware Tanzu, Mirantis, Talos — is engineered out of the EU or the United States and supported by teams several time zones away, which means a ticket raised in the Gulf afternoon is commonly answered the following day, and an escalation waits on another region's working hours. BKE is supported from within the GCC, and is licensed for on-premise installation with no per-node, per-CPU or per-core charge.

You do not have to take any of this on our word. A 14-day trial licence is issued self-service from the Mamluk console — no sales call and no payment details — and it installs exactly the distribution a paid licence does, because there are no editions to hold back.

• Two decisions, not two hundred — the network fabric and the Kubernetes version. Everything else is yours to enable, per cluster, one line each.
• Proven installation and upgrade of Kubernetes itself, pinned to an exact patch rather than a moving minor, so two installs of one BKE version are the same cluster.
• Proven installation and upgrade of every bundled component, with each chart and image mirrored and held by us — an upstream repository that vanishes cannot break your install.
• Installed with a handful of commands: one on each control-plane node, one on each worker, and one to lay down the components.
• Upgrades classified by blast radius. A patch release moves component patches and never drains a node; only a major moves the Kubernetes version, and it moves nothing else alongside it.
• Non-adjacent version jumps are refused rather than attempted — the failure happens in a message, not in your cluster.
• Hardened defaults, proven under production traffic — the values we run ourselves, carried as deliberate deviations from upstream rather than a frozen copy of it.
• The security controls an auditor asks for, on by default and each a switch — Secrets encrypted at rest under a key that never leaves your cluster, an API audit log, Pod Security enforcement, a hardened control plane and signed images.
• Every component's configuration is a file you own and may edit. Upgrades show you the diff between what you are running and what is proposed, and wait for you to agree — your changes are never silently overwritten.
• Upstream Kubernetes and upstream components. Not a fork, no proprietary CRDs, nothing to re-platform if you ever decide to leave.
• No control plane of ours in your data path. If your licence lapses or we are unreachable, your cluster keeps serving traffic — what pauses is installing and upgrading.
• Single flat licence. One cluster, one fee — irrespective of node count, CPU or memory, and with no per-component upsell.
• Region-resident support engineers: same working day, same working week, same regulator. Enterprise support and SLAs scoped to your operational reality — talk to us.
• Hybrid and multi-region by design. A cluster may span sites, and an estate may span regions, without a separate product, an add-on licence or a change of distribution.

Named after the Bahri Mamluks — the river-stationed elite regiment that founded the Cairo Sultanate.