Kubernetes and container platforms for regulated workloads in Nigeria

In most cases yes. Kubernetes manifests, Helm charts and container images are portable; what needs work are the cloud-specific integrations such as managed databases, queues, IAM roles and load balancers. We map those dependencies in the assessment and replace them with equivalents on the private platform and the NuxFamily data layer.

OpenShift is the most common choice where the bank wants a fully integrated, vendor-supported platform with a strong operator ecosystem. Rancher suits institutions that run several clusters and want lighter-weight management. Tanzu makes sense on an existing vSphere estate, and Canonical or upstream Kubernetes where cost and vendor neutrality dominate. We support all of them and choose with you on evidence.

The directive requires the processing environment, backups, IAM, encryption keys and audit logs for payment data to be in Nigeria. A self-hosted cluster on a Nigerian private cloud keeps the control plane, persistent volumes, registry, secrets and audit logs inside the perimeter. Namespace isolation and admission policies also give you demonstrable separation of the payment perimeter for inspection. This is context, not legal advice.

Yes. OpenShift, Rancher and upstream Kubernetes all support disconnected installation from a mirrored registry. Platform updates and application images arrive as signed bundles through your transfer process, and admission policies reject anything that is not signed by your key.

NuxFamily supports the cluster control plane, nodes, ingress, storage integration, registry, GitOps tooling and the platform operators we deploy, with the response times of your tier. Where a vendor subscription exists, for example Red Hat or SUSE, we operate it for you and escalate upstream when needed. The precise scope of L1-L3 responsibility is set out in the support agreement.

Clusters stay within the N-2 window through scheduled minor upgrades, tested first on a non-production cluster built from the same GitOps definition. Upgrades use rolling node replacement so applications with proper disruption budgets do not see downtime. Major version jumps are planned as a project under the Mission Critical tier.

Every change to a cluster is a commit with an author, a reviewer and a timestamp, and Argo CD records when it was applied. We export that history, together with image scan reports and signatures, as a change record the regulator can read without access to the cluster. Manual changes are detected as drift and reverted, so the record is complete.