Do we need to change our application to run on BKE?

Not if it runs on upstream Kubernetes. BKE adds no resource types of its own. An application that depends on resources specific to another platform, such as OpenShift Routes or SecurityContextConstraints, needs those replaced by their upstream equivalents.

Does the customer still need a separate DevOps suite?

No. The Enterprise Helm Charts include source control and CI/CD. BKE itself is the Kubernetes distribution and works with whichever CI/CD tooling the customer already uses, so a customer with an existing suite can keep it.

How is BKE priced for our customers?

At a flat annual fee per cluster, whatever the number of nodes, cores or memory. The figure and a worked example are on the BKE pricing page .

How can we test our product on BKE?

Start a 14-day trial from the Mamluk console . It installs the complete distribution, without a sales call or payment details, on hardware that meets the published node requirements .

What does Mamluk provide to a partner?

Licences for BKE and the Enterprise Helm Charts, support from the engineers who develop them, and published documentation. The commercial terms of each partnership are agreed directly with the partner.

Partners · Software vendors

Your customer's budget belongs to your software and your services.

A vendor of enterprise software, such as a digital banking suite, an insurance core or a payments engine, frequently finds that the customer must first buy an enterprise Kubernetes subscription and a DevOps suite to run it. Those subscriptions come from the same budget as your licence and your customisation work. BKE reduces the platform to a flat fee per cluster and leaves the rest of the budget for the product the customer chose.

Discuss a partnership The cost of ownership

The problem

The platform is bought before your software is.

Many enterprise applications are supported on one commercial Kubernetes platform, and a customer without it is told to buy it. A common combination is an enterprise distribution licensed per core and a DevOps suite licensed per user, each with its own renewal, and each priced before your implementation has been scoped.

The customer's programme has one budget. The larger the platform's share of it, the less remains for customisation, integration and the consultancy that makes the product succeed, and the harder the business case is to approve.

The platform also lengthens your sales cycle. A proposal that requires the customer to procure a platform first carries that platform's procurement, security review and licence negotiation alongside your own.

The arithmetic

What the platform costs a customer each year.

A worked example: a regulated bank running production, staging and performance testing in 3 clusters, on 320 worker cores in total.

Platform	Per year	Over 3 years
OpenShift, 320 worker cores at an assumed USD 1,850 per core	USD 592,000	USD 1,776,000
BKE for 3 clusters, the Enterprise Helm Charts, and support with a four-hour response time	USD 156,000	USD 468,000
Difference	USD 436,000	USD 1,308,000

The OpenShift rate is an assumption: a heavily discounted figure, including Red Hat’s support subscription, used because OpenShift is negotiated per customer and no list price applies to any particular one. Substitute the per-core rate from a real quote and multiply it by 320; the BKE figures do not depend on it. Hardware and staff are excluded from both sides. The full example, with each arrangement and the cost of growth, is on the BKE site.

On the assumed rate, OpenShift costs 3.8 times as much. The difference does not shrink as the estate grows: a further worker core adds to a per-core subscription every year, and adds nothing to a BKE licence, which is USD 12,000 per cluster whatever its size.

For a software vendor, that difference is money the customer spends in the same programme as your licence. On a per-core platform it is spent before your work is scoped. On BKE it remains in the programme, for the customisation, integration and consultancy that you sell.

What changes

What changes when the platform is BKE.

Upstream Kubernetes as the requirement

BKE is upstream Kubernetes with upstream components: not a fork, and no proprietary resource types. An application packaged as standard manifests or Helm charts deploys to it unchanged.

A platform cost the customer can predict

Each cluster is one flat fee, whatever its size. Production, staging and test are three fees, known at the start of the programme and unchanged as the application's load grows.

The services your application depends on

Where your product needs MySQL, Valkey or a message broker, the Enterprise Helm Charts provide them production-ready, with replication, backups and upgrade paths already decided.

Source control and CI/CD without a second subscription

The Enterprise Helm Charts include source control and CI/CD, so the customer does not need a separately licensed DevOps suite. A customer that already has one keeps it: its pipelines deploy to BKE with kubectl and Helm, as they would to any upstream cluster.

A shorter path to a signed programme

A platform at a flat, published price is a smaller procurement than a negotiated per-core subscription, and a 14-day trial lets the customer's platform team install it before the contract is signed.

Support in the customer's region

The distribution is supported from within the GCC by the engineers who develop it, so a platform issue raised during your implementation is answered in the customer's working day.

What partners work with

One distribution, one chart suite, and the engineers who build both.

Bahriya Kubernetes Engine

Upstream Kubernetes and upstream components, with no fork and no proprietary resource types. Licensed at a flat USD 12,000 per cluster per year, whatever the number of nodes, cores or memory, with every component included.

Mamluk Enterprise Helm Charts

Production-ready MySQL, Valkey, message brokers and more, with replication, backups and upgrade paths already decided. They are the charts that run the managed services on bahriya.cloud, licensed per organisation for on-premise use.

Support from the developers

BKE and the charts are supported by the engineers who develop them, from within the GCC. Support with a four-hour response time and Kubernetes support contracts are available on top of the standard support included with a licence.

An evaluation without a sales call

A 14-day trial licence is issued from the Mamluk console and installs the complete distribution. The documentation and the node requirements are published in full.

The commercial terms of each partnership are agreed directly with the partner.

Questions

Common questions from software vendors.

Do we need to change our application to run on BKE?: Not if it runs on upstream Kubernetes. BKE adds no resource types of its own. An application that depends on resources specific to another platform, such as OpenShift Routes or SecurityContextConstraints, needs those replaced by their upstream equivalents.
Does the customer still need a separate DevOps suite?: No. The Enterprise Helm Charts include source control and CI/CD. BKE itself is the Kubernetes distribution and works with whichever CI/CD tooling the customer already uses, so a customer with an existing suite can keep it.
How is BKE priced for our customers?: At a flat annual fee per cluster, whatever the number of nodes, cores or memory. The figure and a worked example are on the BKE pricing page.
How can we test our product on BKE?: Start a 14-day trial from the Mamluk console. It installs the complete distribution, without a sales call or payment details, on hardware that meets the published node requirements.
What does Mamluk provide to a partner?: Licences for BKE and the Enterprise Helm Charts, support from the engineers who develop them, and published documentation. The commercial terms of each partnership are agreed directly with the partner.