Service
On-premise Kubernetes setup and management on your own hardware
Bare-metal and on-premise cluster design, storage, load balancing and day-2 operations — for workloads that cannot sit in a public cloud.
On a managed cloud cluster the provider quietly supplies the control plane, the load balancer and the storage layer. On your own hardware, all three become your problem, and that is where most on-premise Kubernetes projects stall. We build clusters on bare metal or on-premise virtualisation for the cases that genuinely call for it — data residency, an existing hardware investment, plant-floor latency, or an air-gapped network — and we will tell you when the case is not there.
What the engagement covers
Cluster design on your hardware
Control-plane topology and etcd sizing, node roles, and a distribution choice — kubeadm, RKE2, k3s or Talos — matched to who has to operate it after we leave.
Load balancing without a cloud LB
MetalLB or a BGP-based setup, plus ingress, so a Service of type LoadBalancer means something on a network that has no cloud provider behind it.
Storage
Persistent volumes backed by Ceph, Longhorn or an existing SAN/NFS estate, with the failure and backup behaviour tested rather than assumed.
Air-gapped and restricted networks
A private registry, mirrored charts and an offline upgrade path, for sites where pulling from the internet at deploy time is not an option.
Hybrid connectivity
Linking on-premise clusters to cloud services where that split is deliberate, with consistent identity and observability across both.
Day-2 operations
Node replacement, certificate rotation, etcd backup and restore, and a rehearsed upgrade path — the operations a cloud provider would otherwise be doing for you.
Tools we work with
Not an exhaustive list, and not a claim of certification — just what we reach for most often on this kind of work.
- Kubernetes
- kubeadm
- RKE2
- k3s
- Talos
- MetalLB
- Ceph
- Longhorn
- Harbor
- Argo CD
- Prometheus
Common questions
- Should we run Kubernetes on-premise at all?
- Only for a reason you can name — data that legally cannot leave the building, hardware you have already bought, latency to equipment on the floor, or a genuinely air-gapped network. If none of those apply, a managed cluster is less work to operate and we will say so.
- Can you run one cluster on-premise and one in the cloud?
- Yes, and it is a common shape: production close to the equipment, non-production in the cloud. We keep delivery, identity and observability the same across both so they do not become two different systems to learn.
- What about hardware — do you supply it?
- No. We specify what the workload needs and review what you already have, but we do not resell hardware, which keeps the sizing recommendation free of any interest in selling you more of it.
Related services
- KubernetesCluster design, GitOps delivery and day-2 operations for EKS, AKS, GKE and self-managed Kubernetes.
- DevOps & CI/CDPipelines that take a commit to production safely, with automated testing, repeatable environments and fast rollback.
- Cloud InfrastructureArchitecture, provisioning and ongoing management of AWS, Azure and GCP environments, defined entirely as code.
Products built on this work
- MES (Manufacturing Execution System)Work order execution, machine state and full traceability on the shop floor.
- OEE & Downtime MonitoringReal-time line visibility, OEE tracking and categorised downtime analysis.
- Vision Analytics PlatformQueue management, tracking and occupancy analytics from cameras you already have.
Talk to us about on-premise kubernetes
Send over what you are dealing with. We will reply with a straight assessment of whether we are the right team for it.