What enterprises ask before choosing BKE.

Each BKE release pins Kubernetes, Calico, containerd and every component to an exact patch version, tested together. The versions each release pins are stated in that release's notes, which customers read in the console.

They are not published on this site by design. A public list of the versions a release pins is also a list of the vulnerabilities every cluster on that release may carry, and we will not publish that about our customers. During a trial, the release notes are available in the console in the same way.

How versions move between releases is public: Upgrading sets out what each digit of a BKE version promises and how often the Kubernetes version may change.

Debian 12 (bookworm) and Debian 13 (trixie), on amd64 or arm64. Both Debian releases are tested before every BKE release is published. Any other operating system is refused before anything on the machine is changed, because BKE pins the container runtime package for a named Debian release and will not install one built for another.

BKE's requirements are of the machine, not of where it runs: physical and virtual servers that meet them are equally suitable. Before you begin lists every requirement.

Not yet. Every node needs outbound HTTPS to a short, fixed list of hosts during installation and upgrade. Every container image BKE installs is served from a single registry, so the firewall rule does not change when a component does. Installation through an HTTP proxy is supported, and check.sh tests every host before you begin.

A running cluster does not depend on those hosts. Only installation and upgrade reach them. Before you begin lists the hosts and what each one serves.

Your clusters keep running. The licence terms state that licensing is enforced at provisioning only, and that no state of a licence, including expiry, has any effect on a running cluster (clause 5.3). Nothing in BKE stops, degrades or expires the software already installed, and nothing of ours sits in the path of your traffic.

What ends on expiry is our part: delivery of new releases, support, and your licence to use the BKE scripts (clause 11.2). Every component is third-party open-source software licensed to you under its own terms, and those rights continue after a BKE licence ends (clause 6.1).

There is nothing to migrate. A BKE cluster is an upstream Kubernetes cluster created by kubeadm, with Calico as its network and each component installed as an ordinary Helm release of its upstream chart. There is no fork, no proprietary resource type and no BKE-specific manifest in your workloads, so your applications do not change at all.

Operating the same cluster without BKE comes down to four steps:

1. Point the images at their upstream registries. Each component's registry is a single value in its values file under /etc/bke/values/; Calico and the Kubernetes control plane each take a registry setting of their own. The Kong gateway image BKE supplies is built from the upstream Kong release, and the upstream image takes its place.
2. Manage the component releases with helm directly, from the values files you already hold. They are your files, and they remain yours.
3. Upgrade Kubernetes with kubeadm upgrade, following the upstream procedure, one minor version at a time.
4. Remove the reporting job, or disable it before the licence ends.

Any engineer who knows Kubernetes and Helm can do this, and none of it requires our involvement.

The software stays. What you lose is the work done around it, which your team would then do itself:

• A tested combination. Every BKE release pins Kubernetes and each component to an exact patch and is tested as a whole before it is published. Without it, deciding which versions are safe to run together becomes your responsibility on every upgrade.
• Images and charts that cannot move. BKE mirrors every image and chart it installs. An upstream project that retags, moves or withdraws a release cannot break an installation or an upgrade.
• Upgrades that refuse rather than fail. BKE runs numerous checks before an upgrade and stops with a message, rather than part-way through, when a node, a volume or a version jump is not ready. It refuses non-adjacent jumps and tells you in advance whether an upgrade will drain nodes.
• A reviewed change. Every upgrade shows the difference between the configuration you run and the configuration proposed, and which objects that difference moves, and waits for your agreement.
• Access managed in one file. Single sign-on and namespace access are configured in config.yaml; without BKE, those become API server flags and RBAC objects you maintain by hand.
• Security releases and support. New BKE releases, carrying upstream security fixes already tested together, stop, and so does the team that answers for them.

That is the convenience and reliability a licence buys. We would rather a customer renews because of it than because leaving is difficult.

Because BKE is not a product we build in order to sell. It is the engine our own public cloud, bahriya.cloud, runs on. We would build, test and support it for our own production whether or not anyone else licensed it, so the licence fee does not have to recover that engineering from every core it runs on.

The second reason is how we work. BKE is built and supported by small teams of engineers who each work across the whole stack, from the operating system to the components above Kubernetes, rather than by large teams divided by layer. It requires fewer people, each considerably more skilled, and it makes our cost of building and supporting the distribution substantially lower than that of the established vendors. The flat fee reflects that cost.

One cluster, of any size, identified by its control-plane endpoint. Node count, CPU and memory do not affect the fee, and every component is included: there are no editions and no per-component charges. A separate cluster for staging or testing needs its own licence.

Replacing the hardware of the first control-plane node is a support request: we move the licence to the new machine.

The cost-of-ownership example works this through for a bank running three clusters, over one year and three, with and without the Mamluk Enterprise Helm Charts and support. The pricing page converts the BKE fee into the per-core unit an OpenShift quote arrives in, so you can set it beside your own.

Every licence includes baseline support: a response to every ticket within three working days, with corrections delivered through regular BKE releases. Support plans with faster response times, including a four-hour response and a 24/7 tier, and consulting are available on request.

The components BKE installs are fixed for each release, because a tested combination is the point of a distribution. Each of them is optional, however: leave Netdata disabled and BKE installs no monitoring at all.

You remain free to install anything else on the cluster, Prometheus and Grafana included, exactly as you would on any Kubernetes cluster. For stateful services and observability, the Mamluk Enterprise Helm Charts provide production-ready charts maintained by the same team.

Where many customers ask for the same tool, we consider adding it to BKE itself or to the Enterprise Helm Charts.

Yes. Each component's configuration is a values file on your control-plane node, and you may edit it. Upgrades show you the difference between your file and the one BKE proposes and wait for your agreement, so your changes are never silently overwritten. Installing components describes the process.

BKE requires no training of its own. A team that knows Kubernetes, and the components it chooses to enable, has what it needs; the documentation covers everything specific to BKE and is public. A team that is new to Kubernetes can start with How a cluster fits together.

We do offer training. As the engineers who build and operate BKE in production, we can deliver it in Kubernetes, in any of the bundled components, or in the operation of your own estate, tailored to your team.

BKE version numbers are classified by what an upgrade does to a running cluster. A patch release rolls component pods and never drains a node; a minor release may drain nodes; only a major release moves the Kubernetes minor version, and it moves nothing else alongside it. You can decide whether an upgrade needs a maintenance window from the number alone. Upgrading covers the sequence in full.

Yes, through OpenID Connect. BKE grants access through group membership, so the identity provider must be able to emit a groups claim in its ID token. Entra ID, Okta, Google Workspace and Keycloak all can. Access can be granted to the whole cluster or to named namespaces. Cluster login explains the requirements and the configuration.

One small, published report, once a day, so that the console can show you your own estate and support can see your versions. It contains no personal data and no secret, and it gates nothing. You may turn it off in config.yaml with no consequence of any kind. Cluster reporting lists every field.

With a 14-day trial licence, issued self-service from the console, with no sales call and no payment details. It installs exactly the distribution a paid licence does, because there are no editions to withhold. The trial, in an afternoon takes three Debian servers to a working cluster with an application behind it.

Mamluk, the engineering practice that builds BKE and runs it in production at bahriya.cloud. The engineers who answer your tickets are the engineers who build the distribution.