OpenShift has a price and almost nobody will show it to you. Red Hat's own pricing page says it varies with your sizing and points you at a salesperson. Microsoft's page for Azure Red Hat OpenShift explains that the license rides on the worker nodes, then hands you a calculator. AWS is the only one of the three that prints a rate you can read without a sales call, and its clusters cannot run in Kenya.
That is where an OpenShift engagement in this market actually begins, because what you are buying is a subscription and what sizes it is a core count somebody has to defend on your behalf. CloudSpinx designs and runs Kubernetes clusters for organizations in Kenya and across East Africa, on the hyperscalers' managed offerings and on hardware in Nairobi facilities. We are the 3rd or 4th contributor on each of the three infrastructure-as-code repositories behind Mojaloop, the open-source payment switch that national payment systems are built from, and the engineering record carries the commit counts. Apply everything below to us as readily as to anyone else on your list.
The subscription counts application cores, not servers
- cores you entitle
- entitlement included
An infrastructure node keeps its included entitlement only while nothing but cluster components runs on it. Schedule one application pod there and its cores become countable again.
Red Hat sells self-managed OpenShift by the core-pair, which its subscription guide defines as two physical cores or four vCPUs. Add up the vCPUs across your compute nodes, divide by four, and that is the number on the quotation.
Two exemptions decide how big that number gets, and both are easy to lose. Control plane entitlements come with the subscription, so those cores are not counted, right up until applications run on them. In a compact three-node cluster they do, and the guide is blunt about the consequence: there are no special accommodations, every core on the node has to be entitled. The cheapest hardware shape on the shelf is also the one that turns your free cores into paid ones.
The second exemption is the infrastructure node, and a consultant who has actually sized a cluster will raise it before you do. Move the registry, ingress, monitoring and logging onto dedicated infra nodes and those cores come off the count, on one condition: nothing but cluster components may run there. Schedule a single application pod onto an infra node and the exemption leaves with it.
So ask how many core-pairs your workload needs, and what they would put on infra nodes. An answer pitched in node counts instead of core counts came from somebody who has bought servers rather than subscriptions.
The release you install decides your upgrade calendar
- full support
- maintenance
- extended terms
Full support runs six months or ninety days past the next minor release, whichever is later, so a slow release train quietly lengthens the first phase and never the last one.
Maintenance support on a minor release ends 18 months after it goes generally available. Even-numbered releases go further through Extended Update Support, to 24 months, then 36 and 48 on add-on terms. Odd-numbered releases get none of that. Land on one and 18 months is the whole allowance, at any price, which means the release your supplier picks in week one is the upgrade you are budgeting for in year two.
This is the single question worth asking early, because the answer cannot be revised in the meeting. Somebody who has operated OpenShift will tell you which minor they would install and why it is an even one. Somebody who has read the documentation will say the latest.
Set that against what an unsubscribed cluster gives you. Upstream Kubernetes patches a minor for roughly 14 months, 12 standard plus two in maintenance, which is the same clock we walk through in what to ask a Kubernetes consultant. The subscription is not buying features you cannot get upstream. It is buying the right to leave a production cluster alone for longer, and for an organization with one platform engineer that is worth real money.
The only published price belongs to a cluster that cannot run here
AWS prints its rates plainly. Red Hat OpenShift Service on AWS, or ROSA, charges $0.171 per four vCPUs per hour on worker nodes, and the hosted control plane version adds $0.25 an hour per cluster. Run those out over a year and the 24 vCPU cluster in the first figure is about $9,000 in service fees, plus $2,190 for the cluster itself, before a single EC2 instance or EBS volume appears on the bill. Commit for a year and AWS quotes $1,000 per four vCPUs instead of roughly $1,500.
Those are the numbers a Kenyan buyer can verify, and they describe a cluster in Ireland or Frankfurt or Cape Town. There is no AWS or Azure region in Kenya. Where a contract, a regulator or a client's own policy fixes where personal data sits, the published price is for the wrong product, and the honest design is a self-managed cluster on hardware in a Nairobi facility or a split estate with the regulated tables staying here.
Which puts you back at a core count and a quotation nobody publishes. That is not a reason to distrust the model. It is a reason to have someone who is not selling the subscription do the arithmetic.
The OpenStack estates that arrive at OpenShift without choosing it
A growing share of the OpenShift conversations we have in this region did not start with OpenShift. They started with Red Hat OpenStack Platform 17.1, which is the last release built on the classic director-managed control plane. Its successor hosts that control plane on OpenShift, so a telco or bank adopting the vendor's own upgrade path acquires an OpenShift estate it had no independent reason to run, along with the subscription and the skills to operate it.
That changes the shape of the decision rather than settling it. Both routes off 17.1 are real, and we have written up what each one costs an operator in detail. The point for a buyer shopping for OpenShift help is that an engagement arriving this way is really two engagements, and a supplier who prices it as one has not read the lifecycle notes. Our own OpenStack work scopes them separately for exactly that reason.
Who should actually be buying OpenShift
Three cases justify it without argument. You need commercial support with a named escalation path and a certification you can hand an auditor. A vendor ships its product as an OpenShift operator and will not support it anywhere else. Or the RHOSO path above already made the decision for you.
Outside those, the honest answer for most teams here is a plain Kubernetes distribution, and we say so on the first call. A four-person engineering team with two services in production is not held back by the absence of an integrated registry and a web console. It is held back by not having a pipeline, which is delivery machinery rather than a platform license. Buying OpenShift to fix that spends a subscription on the wrong problem and adds an upgrade calendar on top.
The detail that breaks the first deployment
OpenShift will not run your containers as root. The default security context constraint drops privileges and assigns a random user ID, and a surprising number of upstream Helm charts assume neither of those things. So the plan that reads "lift the charts across in a sprint" meets a wall of pods stuck in CreateContainerConfigError, and the migration timeline doubles while somebody rebuilds images to run unprivileged.
It is the most predictable delay in an OpenShift migration and the easiest one to interview for. Ask what they do about workloads that need a fixed UID. An engineer who has done this will describe rebuilding the image before they describe granting an exception, because the exception is how a cluster ends up less secure than the one it replaced.
Send us your workload list and how many vCPUs it runs on today, and you get back a core-pair count, the release we would install and one figure for the work. Free, no obligation, and if the arithmetic says plain Kubernetes, that is what the reply will say. The scoping form takes a couple of minutes, or WhatsApp +254 713 403 044 if you would rather just describe it.