Kubernetes as a Service

Sovereign KaaS

Production Kubernetes, operated by us, owned by you.

Sovereign KaaS is managed Kubernetes on infrastructure you control. Neor builds, operates and secures the clusters — upstream, conformant Kubernetes with no proprietary fork — across your data centres, your edge sites and any cloud accounts you choose to keep. They sit under one control plane, and the keys, the source and the build definitions stay inside your organisation.

Kubernetes is cheap to start and expensive to run properly. The recurring cost is not compute; it is the specialist team needed to keep every cluster patched, hardened, tenanted and auditable, and the outages and audit findings that follow when that team is stretched. Sovereign KaaS moves that work onto a standing engineering team and a repeatable build, so your platform engineers spend their time on the applications the business is paid for.

Architecture

How it is put together

Fleet control plane

A single inventory and API across every cluster you run, with resource search that answers where a workload is, on which version and under which policy, in one query.

Governance and tenancy

Workspaces, role bindings federated to your own directory, resource quotas and a complete audit trail, so several teams can share a cluster without sharing each other's risk.

Cluster lifecycle engine

Declarative creation, scaling, upgrade, repair and retirement of clusters, driven through Git so every change to a cluster is reviewed, versioned and reversible.

Platform baseline services

The services a cluster needs before it can carry production work — networking and network policy, CSI storage, ingress, certificate management, an image registry, backup, and Prometheus and Grafana observability — delivered as one versioned, tested baseline rather than assembled cluster by cluster.

Node and runtime layer

Hardened operating system images, a standard container runtime, and node pools spanning x86 and ARM, bare metal and virtual machines, including GPU-accelerated nodes where workloads require them.

Substrate you own

Your own racks, your private cloud, your edge locations and any external cloud you still use, joined into one fleet with no foreign control plane sitting above them.

Capabilities

Clusters on demand

Production-grade clusters are provisioned from a declarative definition onto bare metal, virtual machines or an existing cloud account, so a new environment is a request rather than a project.

One fleet, one console

Every cluster — central, remote and edge — appears in a single control plane with a shared view of workloads, versions, capacity and policy.

Managed version upgrades

Kubernetes and node upgrades are tested against your baseline, staged ring by ring across the fleet and rolled back on failure, so staying current stops being a risk event.

Hardened by default

Clusters are built to a hardened baseline — admission policy, pod-level security restrictions, signed and scanned images, encrypted secrets and mutually authenticated service identity — and drift from that baseline is detected continuously.

Multi-tenancy and quotas

Workspaces, namespace isolation, quota enforcement and per-tenant consumption reporting let business units share capacity while remaining separately governed and separately accounted for.

Networking and storage baseline

A supported cluster network plugin with network policy, multiple network interfaces per pod where workloads demand it, and replicated block storage presented through CSI, all versioned and upgraded with the cluster.

Fleet-wide observability

Metrics, logs, alerting and capacity reporting are aggregated across clusters, so control-plane health and node exhaustion are visible before they become an incident.

Backup and multi-site recovery

Cluster state and persistent volumes are backed up and restore-tested, with active-active, active-passive and active-backup topologies across data centres for services that cannot stop.

Where it fits

A bank runs Kubernetes in three data centres and cannot tell an auditor which version, which policy set and which patch level each cluster is on.
A ministry needs a hardened production cluster for a new public service this quarter, and the internal platform team is already fully committed to existing systems.
A telecommunications operator's clusters have fallen two minor versions behind because the last upgrade caused an outage and nobody wants to attempt the next one.
Several development teams share one cluster, and a single misconfigured workload can exhaust the nodes and take the others down with it.
A regulated organisation must keep its clusters on hardware and software it can source and support domestically, with no external control plane and no supplier able to withdraw the platform.

What you end up with

A hardened, continuously upgradeable Kubernetes fleet running on infrastructure you own, with the build definitions, runbooks and operational knowledge handed over to your own engineers.