What does managed Kubernetes on premise mean?

The clusters run on your hardware, inside your data centre and inside your network perimeter. We install them, monitor them around the clock, patch them, upgrade them and answer for their availability. The operational model is a managed cloud service; the custody model is your own server room. No workload, secret or byte of data leaves your premises for us to do any of it.

On request, against your inventory: the number of clusters, the SLA tier and the on-call coverage required. It is quoted separately from the BKE licence , which remains a flat annual fee per cluster regardless of node or core count, so that the operating cost and the software cost are legible to you as separate lines.

Does your team need access to our data?

No, and the boundary is written into the engagement. Operating a cluster requires access to the platform — the control plane, the nodes, the platform namespaces and the telemetry. It does not require access to the contents of your application databases or object storage, and the access granted is scoped to exclude them. Regulated clients typically also record every session, which we expect rather than resist.

Who is accountable if there is an outage?

We are, within the scope of the platform and to the terms of the SLA, and a single named principal engineer is accountable for the engagement rather than a support organisation. That accountability is the difference between this service and a Kubernetes support contract , under which your own team operates the cluster and we respond when called.

How is this different from a hyperscaler's managed Kubernetes?

A hyperscaler operates a control plane in its own region under its own jurisdiction, and the data plane follows. Here the entire cluster is inside your building and under your regulator, and the operations are performed into it rather than around it. The trade is real in both directions: a hyperscaler offers elasticity we cannot, and we offer custody it cannot.

Can you run it on our existing Kubernetes rather than BKE?

The managed service is delivered on the Bahriya Kubernetes Engine, because answering for the availability of a platform requires knowing exactly what is in it and controlling how it changes. An estate already running another distribution is normally migrated as part of onboarding. Where migration is not acceptable, a support contract on your existing distribution is the honest alternative and we will propose it instead.

What hardware do we need?

Ordinary servers. BKE runs on amd64 or arm64 machines under Debian, virtualised or bare metal, and the per-node requirements are published in full so that an evaluation can be completed before anyone is contacted. Sizing for a specific workload is part of onboarding rather than a number we would publish to flatter the product.

What happens if we want to take it back in house?

The exit is written into the engagement at the start. The clusters are already yours, on your hardware; what transfers is the operational knowledge, and the runbooks, decision records and configuration that carry it are yours throughout rather than produced at the end. A licence for BKE can continue, or the estate can be migrated off it. An exit that is only discussed at the point it is wanted is an exit that has been made expensive on purpose.

Managed Kubernetes on Premise — Fully managed clusters inside your data centre

Engagement

On request

Pricing reflects cluster count, SLA tier and on-call coverage. We quote against your inventory.

Begin an engagement ← All services

A fully managed Kubernetes practice, delivered inside your own data centre on the Bahriya Kubernetes Engine. We install the clusters, operate them around the clock, and remain accountable for their uptime — while every byte of data, every secret and every workload stays inside your perimeter and under your regulator. It is the operational model of a hyperscaler, with the sovereignty model of your own server room.

This is the same engineering and on-call practice that runs bahriya.cloud, pointed at your hardware. You get the day-to-day reliability of a managed cloud platform without ever surrendering custody of the systems running on it — an option no hyperscaler can offer, and one that few global vendors are willing to staff from inside the GCC.

What you get

Installation, configuration and lifecycle management of BKE clusters on your hardware
24x7 monitoring, alerting and on-call response from GCC-resident engineers
Capacity planning, upgrades, CVE patching and quarterly architectural reviews
Backup, disaster recovery and audited restore drills
Managed data, messaging, ingress and observability services via the Mamluk Enterprise Helm Charts
Documented runbooks, RACI matrices and a single named principal engineer accountable for the engagement

Ideal for

Regulated institutions, sovereign-cloud programmes, and enterprises that need hyperscaler-grade Kubernetes operations without surrendering data custody.

The engagement

Hyperscaler operations, inside your perimeter.

Regulated organisations in the Gulf are routinely asked to satisfy two requirements that appear to conflict. The data, and increasingly the control functions that act on it, must remain inside the country and inside the institution's own custody. At the same time the platform running on it has to be operated to the standard of a managed cloud service, because the institution's own availability commitments do not soften on the grounds that it chose to host its own infrastructure.

Managed Kubernetes on premise resolves that by moving the operations rather than the data. The clusters are installed on your hardware, in your data centre, behind your firewall. We operate them: monitoring, on-call response, capacity planning, upgrades, CVE patching, backup and audited restore drills. Nothing leaves the building for us to do any of it, and a single named principal engineer is accountable for the outcome.

It is the same engineering practice, the same distribution and the same on-call rota that runs bahriya.cloud, our own public cloud, pointed at your hardware instead of ours. We are not assembling a managed service to sell you. We are operating the one we already run.

Responsibility

Where the boundary sits.

The most common failure of a managed engagement is not technical. It is an outage in which both parties believed the other was responsible for a component. The split below is agreed in writing before the first cluster is installed, recorded as a RACI matrix, and revisited at each architecture review.

We are accountable for

Installation, configuration and lifecycle of every BKE cluster on your hardware
Control-plane availability, etcd health and the recovery of both
Monitoring, alerting and on-call response, 24 hours a day
Kubernetes and component version currency, and CVE patching against a defined schedule
Backup execution, retention and the restore drills that prove the backups are real
Platform services — ingress, storage, observability, and the managed data and messaging services delivered through the Mamluk Enterprise Helm Charts
Capacity planning, and telling you before the estate runs out rather than afterwards

You remain accountable for

The physical estate: the data centre, the machines, the power and the network fabric
Your applications, their correctness, and their behaviour under load
The data itself, its classification and who inside your organisation may reach it
Identity, and which of your people hold which roles in the cluster
Procurement of hardware as capacity planning identifies the need
The regulatory relationship, which we support with evidence rather than assume

Onboarding

From first conversation to an operated estate.

Stage 01

Inventory and assessment

What hardware exists, what runs on it today, what the availability commitments actually are, and which regulations apply to which data. This produces the cluster count and the SLA tier, and therefore the price. It is also the point at which we will tell you if the estate does not warrant the service.
Stage 02

Design and the responsibility matrix

Cluster topology, network and storage design, the identity integration, the backup and recovery position, and the boundary above recorded as a RACI matrix. The access we will hold is defined here, in writing, including what it deliberately excludes.
Stage 03

Installation

BKE clusters installed on your machines, the platform services deployed, monitoring connected and alerting routed to our rota. Nothing is declared operational until a restore has been performed from a backup taken by the system rather than by hand.
Stage 04

Workload migration

Applications moved onto the estate in a sequence agreed with your teams, beginning with something that matters enough to be tested honestly and not so much that the first migration is also the first outage. Your engineers migrate their own workloads with us alongside them.
Stage 05

Steady-state operation

Round-the-clock monitoring and on-call, patching and upgrades on schedule, restore drills on schedule, a quarterly architectural review, and a named principal engineer who knows your estate rather than a rotating account manager who knows your contract.

Comparison

The three ways this requirement is usually met.

An organisation that needs Kubernetes operated to a production standard, with its data inside national borders, has three realistic options. Each is legitimate; they differ in what they ask of you.

Build a platform team

The strongest long-term position, and the slowest to reach. It requires hiring several scarce engineers into a market that is competing for them, retaining them, and covering a rota with them. Organisations that succeed at this should do it. Many discover eighteen months in that they have one engineer and a single point of failure.

Buy a distribution and a support subscription

A licence from a global vendor, negotiated per customer and usually priced per core, with support delivered from wherever that vendor's engineers are. It solves the software problem. It does not solve the operations problem, which remains yours, and the support jurisdiction may not be one your regulator accepts.