OpenStack Consulting and Private Cloud in Kenya
CloudSpinx designs, deploys and runs OpenStack private clouds for service providers, banks, universities and government teams in Kenya and across East Africa: highly available control planes, Neutron and OVN networking, Ceph storage, upgrades off releases that stalled, and migrations from VMware and Red Hat OpenStack Platform. The software is free. The cost sits in the hardware, the three networks under it, and having someone who can still upgrade it in year three.
Who we build for
- 14organisations, from ISPs and payment platforms to a national regulator
- 6flagship engagements published in full, with the numbers counted
- 4thof all contributors to the open-source payment switch national systems run on
Everything in Our OpenStack Consulting Service
Every engagement covers the full scope: no hidden extras, no upselling.
Private cloud design and sizing
We start from who will consume the cloud, not from a parts list. Tenancy model, instance profiles, growth over three years, then the controller, compute and storage split that carries it.
OpenStack installation and deployment
Kolla-Ansible or OpenStack-Ansible against OpenStack 2026.1, with the inventory and configuration in your git repository from day one rather than on somebody's laptop.
OpenStack HA control plane design
Three controllers behind an HAProxy and keepalived VIP, MariaDB Galera sized for quorum, RabbitMQ that survives a partition, and honest numbers on what each failure actually costs.
Neutron and OVN networking
Provider and tenant networks, floating IP ranges, distributed gateways instead of one chokepoint, security groups, and the MTU maths that stops large transfers stalling later.
Ceph storage integration
One Ceph cluster serving Nova ephemeral, Cinder volumes and Glance images over RBD, plus RGW where you need S3-compatible object storage. Converged or on its own nodes, sized to the failure domain.
VMware to OpenStack migration
Wave-based moves off vSphere and ESXi. Disks converted, Windows drivers prepared in advance, NSX policy redesigned as Neutron networks and security groups, test boots before every cutover.
Red Hat OpenStack Platform migration
RHOSP 17.x estates facing the move to an OpenShift-hosted control plane. We scope both routes, adoption into RHOSO or an exit to upstream OpenStack, and tell you which one fits your team.
OpenStack upgrades and rescue
Clouds three or more releases behind, brought back onto a supported version through the SLURP path, rehearsed on a clone of your own database before anything touches production.
Identity, quotas and multi-tenancy
Keystone against Active Directory or LDAP, federated logins, projects and domains that match how the business is actually organised, and quotas that hold when a team writes a bad loop.
Bare metal and container platforms
Ironic for provisioning physical nodes through the same API, and Kubernetes running on top of the cloud where the workload wants containers rather than instances.
Monitoring and capacity planning
Prometheus and Grafana across the control plane, Ceph and the hypervisors, with alerts on the things that actually take OpenStack down: certificate expiry, queue growth and Galera drift.
Managed OpenStack support
Patching, upgrades on a cadence, backup verification, capacity reviews and an engineer who already knows your cloud when the API stops answering at 21:00 on a Friday.
Technologies we use
How we design an OpenStack private cloud
Four shapes that decide whether a private cloud is still healthy in year three: the control plane and the three networks under it, how a tenant packet actually reaches the internet, what each kind of failure really costs you, and the upgrade path most estates never take. Node counts and sizing come out of your workload during the design phase.
OpenStack private cloud reference architecture
Three controllers behind one API endpoint, compute you add without touching them, and Ceph serving Nova, Cinder and Glance from one pool. The part people underestimate is on the left of the diagram: three separate networks. Collapse the management, tenant and storage networks onto one pair of switches to save money and you will spend it back the first time a backfill starves your API.
- Management and API network
- Tenant overlay: OVN Geneve tunnels
- Storage network: Ceph public and cluster
- Provider and external network
Neutron and OVN: how a tenant packet gets out
Networking is where OpenStack deployments actually fail, and it fails quietly. A cloud that boots instances fine can still be unusable because the provider VLAN was never trunked to the right switch ports, or because the gateway path funnels every tenant through one node. We design the north-south path and the tenant isolation before anyone racks a server, because retrofitting it means rebuilding.
What actually happens when something fails
Three different failures, three completely different outcomes, and only one of them is the one people expect. The important one is on the right: OpenStack does not restart your instances somewhere else when a compute node dies. Nova has no equivalent of VMware HA in the base product. We say that during design rather than during your first outage.
The OpenStack upgrade path and the SLURP cycle
Almost every stalled OpenStack we are called to rescue stalled for the same reason: somebody deployed it, nobody planned the second upgrade, and four releases later the jump looks impossible. SLURP exists to fix that. Every other release supports a direct skip-level upgrade, so you can move once a year instead of twice and still land on a supported version. Pick the cadence at design time and rehearse it before you need it.
Do you actually need OpenStack?
The honest version, first card included. Most businesses that ask us for a private cloud want the second one. A fair number want the first, which is not OpenStack at all.
One team, one set of VMs
Nobody outside infrastructure asks for a server, and the count is under a hundred. A Proxmox cluster or plain KVM does this with a fraction of the moving parts.
Costs you: nothing, and that is the point. You keep the money and the weekends.
Small private cloud
Three controllers and four or more compute nodes, one Ceph pool, projects and quotas per department. Developers get an API and stop filing tickets for a VM.
Costs you: three servers that carry no workload, and an operator who owns upgrades as a job.
Ten or more compute nodes
Ceph moves onto its own nodes, Octavia gives tenants load balancers, host aggregates separate the noisy workloads, and quotas actually get enforced against a budget.
Costs you: a real storage network, and capacity planning that happens before the alert.
You are selling the capacity
An ISP or a hosting business with external customers: multiple regions, Ironic for bare metal, metering into billing, and tenant isolation that survives an audit.
Costs you: a team, not a person. At this size the cloud is your product, not your IT.
These are the shapes, not the build sheet. Controller spec, compute sizing, the storage network and the upgrade cadence all come out of what you are actually running, and that is the first conversation we have.
What an OpenStack private cloud actually costs in Kenya
OpenStack has no licence. No per-socket fee, no per-core bundle, no renewal that reprices because the vendor changed owner. That lands well with anyone who has just opened a VMware quote, and it leads straight to the right question: if the software is free, where does the money go? Three places. Hardware, including three controllers that will never run a workload of yours. The network, because a private cloud wants three of them. And the engineering, which on OpenStack is the largest line and the one most proposals quietly leave out. A vendor subscription is a choice rather than an entry fee. Canonical folds OpenStack support into Ubuntu Pro at a published USD 500 per physical server per year, or USD 1,775 with 24/7 infrastructure cover, on the Ubuntu Pro price list; Red Hat and Mirantis quote per node and publish nothing. We build on upstream OpenStack, so you can take a subscription later or never. Every engagement is scoped rather than listed, because a four-node teaching cloud and a twenty-node IaaS platform with paying tenants are not the same job. We have worked the arithmetic through against a renewal in what a private cloud costs here, using a real core count.
- Control plane overhead: three servers bought before your first instance boots, carrying no tenant workload of yours, ever
- Compute node count and spec: the only line that scales with what you actually run, and the one to spend on
- Storage design: Ceph converged onto the compute nodes is cheaper; Ceph on its own nodes is what a busy cloud ends up wanting
- Three networks: management, tenant overlay and storage, each with its own switch ports, planned alongside your LAN and firewall design
- Deployment tooling: the repository that built the cloud is an asset if it is maintained and a liability if it is a fork nobody owns
- Windows and SQL licensing: follows the physical host cores whatever runs underneath, and is often the biggest number on the page
- Operator time: OpenStack expects one. If nobody is going to own it, managed is not an upsell, it is the design
- Migration effort: instance count, how much of the estate is Windows, and how many cutover windows the business can tolerate
OpenStack architecture: control plane, compute and Ceph storage
An OpenStack cloud is two machines bolted together, and confusing them is the most expensive mistake available in the design phase. The control plane takes API calls, decides where an instance should land and writes the answer to a database. The data plane is the compute and the storage that actually carry the workload. They fail differently, they scale differently, and past a proof of concept they should not be sharing hardware.
Three controllers, one endpoint
Everything reaches the cloud through a single virtual IP in front of HAProxy, so no user ever knows which controller answered. Behind it, MariaDB Galera needs a majority to accept writes, which is why three is the floor and why two controllers are genuinely worse than one: you double the failure surface and gain nothing, because either failure takes the database read-only. Lose one of three and the API keeps serving. Lose two and you can still run everything already running, you just cannot create, resize or attach anything until a controller comes back.
Compute is the part that scales quietly
A compute node runs nova-compute and ovn-controller and very little else, which is exactly the point. Adding capacity means racking a node, running the playbook and watching it appear in Placement, with no change to the control plane and no downtime. Where the thinking goes is above that: flavors that match real workload shapes rather than a tidy list of sizes, host aggregates so the noisy tenant is not on the same box as the database, and an oversubscription ratio that is a commercial decision dressed as a technical one. We hardened the Linux platform underneath before any of it, because a hypervisor is only as trustworthy as its host OS.
Ceph is one decision, not three
Put Nova ephemeral disks, Cinder volumes and Glance images on the same Ceph cluster and several good things happen at once. Live migration works because every host can already see the disk. Instances boot in seconds from a copy-on-write clone rather than a full image copy. A compute node becomes disposable. The trap is converging Ceph onto the compute nodes to save hardware and then giving it the same NICs as everything else, so the first disk failure starts a backfill that competes with your tenants for bandwidth. That design is fine at four nodes and a problem at twelve, and we say which side of the line you are on before you buy.
OpenStack networking with Neutron and OVN
This is where private clouds fail, and they fail quietly. A cloud that boots instances perfectly can still be unusable because the provider VLAN was never trunked to the right switch ports, or because every tenant egresses through one gateway node that nobody sized. OVN removed most of the old per-network agent sprawl and made the datapath something you can reason about, which is a genuine improvement and not a reason to skip the design. Retrofitting the network layout on a running cloud means rebuilding it.
- Provider networks: the VLANs that reach the rest of your estate, agreed with whoever owns the switches before the design is signed off
- Tenant networks: Geneve overlays so projects cannot see each other, with the tunnel overhead accounted for in the MTU rather than discovered during a large transfer
- Floating IPs: a public range reserved up front, because running out of them is an embarrassing way to stop a launch
- Gateway placement: distributed where the traffic pattern allows it, so north-south does not funnel through a single node
- Security groups: useful per instance, and not a substitute for a real firewall at the edge or for a security review of the whole estate
- Octavia: load balancers tenants can create themselves, which is usually the feature that stops them asking you for one
VMware to OpenStack migration and Red Hat OpenStack Platform
Two very different calls end up here. The first is a VMware estate whose renewal came back as a per-core subscription bundle with a number nobody had budgeted for, and OpenStack is on the shortlist because it is the only open-source alternative to VMware that offers real multi-tenancy without a licence attached. The second is a Red Hat OpenStack Platform site that has read the lifecycle notes properly. RHOSP 17.1 is the last release with the classic director-managed control plane; its successor hosts the control plane on OpenShift, which is a re-platform rather than an upgrade, and we have written up both routes off 17.1 in detail. Both calls deserve the same answer: build the new thing beside the old one, move in waves, and keep the way back open until the last wave has been boring for a month.
What converts, and what has to be redesigned
Disks convert. That part is mechanical and we have done it enough times to be dull about it. Networking does not convert at all: NSX segments, distributed firewall rules and vSphere port groups have no import path into Neutron, so they get redesigned as tenant networks, routers and security groups, and that redesign is the real project. Windows guests need virtio storage and network drivers prepared on the source side rather than during the cutover, which is where rushed migrations lose a weekend to a machine that boots to a blue screen. Your Windows Server estate keeps its identity and its licensing position through the move, and we work the licence maths before you buy hardware because it sometimes changes the node count.
The Red Hat OpenStack Platform decision
There are two honest routes off RHOSP 17.x and they cost very different things. Adopting Red Hat OpenStack Services on OpenShift keeps the vendor relationship and the support contract, and it means standing up and then owning an OpenShift estate you may have had no other reason to run. Moving to upstream OpenStack deployed with Kolla-Ansible drops the subscription and the OpenShift dependency, and hands your team the operational load instead. Read the Red Hat OpenStack Platform life cycle and work out your own deadline first; we will scope both routes against it and say which one we would take if it were ours.
Waves, and the way back
We build the landing cloud empty and prove it empty, then move the quietest workloads first so the mistakes happen where nobody is watching. Business applications follow, databases and the regulated tenants last. Nothing on the old platform is deleted until the final wave has run untouched for a month. It is slower on paper than a big-bang weekend, and it is the reason we have never had to tell a client there is no way back.
OpenStack upgrades, SLURP, and rescuing a cloud that stalled
Most of the OpenStack estates we get asked to look at are several releases behind, and the story is always the same: the deployment was a project, the project ended, and the second upgrade never had an owner. Upstream took that seriously. Under the skip-level release process, every other release supports a direct upgrade from the previous one of its kind, so 2026.1 Gazpacho takes you straight from 2025.1 Epoxy without stopping at Flamingo on the way. That is one upgrade a year instead of two, on a path the project actually tests, and it is documented in the OpenStack release cadence policy. It works. It only works if somebody rehearses it.
- Establish which release you are on and whether it still receives fixes, before any other conversation happens
- A staging cloud restored from your own database dump, because your data is what breaks an upgrade, not the packages
- One canary controller upgraded alone, with the API watched behind the VIP and a rollback that has been tested rather than assumed
- Database migrations run once, on a dump you have already restored somewhere else successfully
- Compute nodes upgraded in batches with live migration, so tenants keep running through the whole window
- The deployment tooling upgraded alongside the cloud, because an estate built by an unmaintained fork of a playbook is the actual problem to solve
Managed OpenStack support and day-2 operations
A private cloud is not a project that finishes. It is a service with a lifecycle, and the difference between one that is still healthy in year three and one that quietly rotted is entirely whether anybody was watching. The failures that take OpenStack down are rarely dramatic. An internal TLS certificate nobody diarised expires and every service stops talking at once. A RabbitMQ partition leaves the scheduler taking requests it will never act on. Galera drifts and one node stops joining after a reboot. Ceph fills to the point where it refuses writes, which it warns about for weeks first. Managed OpenStack support puts all of that on somebody's calendar, and where you already take our wider managed IT cover it folds into the same response commitment.
- Certificate inventory with expiry alerts, because this is the single most common cause of a total API outage
- Control plane, Ceph, hypervisor and tenant-quota metrics into Prometheus and Grafana with thresholds that mean something
- RabbitMQ queue depth and Galera cluster state alerted on, not left to be discovered during an incident
- Patching on a cadence, and a release upgrade planned once a year rather than deferred until it is frightening
- Quarterly capacity review against real growth, plus a clean-up of the orphaned volumes and images every cloud accumulates
Running a private cloud in Nairobi
Plenty of Kenyan organisations have solid reasons to keep the platform in the country and often in their own building: a regulator that expects to know where the data sits, an application that talks to systems on site, or an internet link that could never carry the workload. Those clouds work. The constraints are physical and local. A three-controller Galera cluster does not enjoy an unplanned group reboot any more than Ceph does, so grid reliability, UPS runtime and generator start time stop being facilities trivia and become part of the storage and control plane design. Heat and dust kill more disks in an unfiltered comms room than any software fault. And when a controller dies at midnight, somebody has to physically be there, which is a staffing question long before it is a technical one. Where your tenant data may legally live is a design input too, and the Data Protection Act rules on cross-border storage shape the region layout rather than being checked afterwards. We are equally happy building into a Nairobi colocation facility or onto hardware we source and host for you, and the choice between the two usually comes down to who can reach the rack at 2am.
When we tell clients not to use OpenStack
We deploy OpenStack and we talk more people out of it than into it. It is the most capable platform in this category and the most expensive to own, and those are the same fact rather than two facts. Saying so is what you are hiring a consultant for, and if you want the reasoning in full, the choice against Proxmox turns on one question rather than on any feature list.
- One team runs everything and nobody outside infrastructure ever asks for a server. You want a hypervisor cluster, and our Proxmox work delivers that with a fraction of the moving parts
- Under roughly a hundred instances with no self-service requirement. Three controllers that carry no workload will cost you more than they return
- You need it live in six weeks. A private cloud designed in six weeks is the thing we get called to rescue in eighteen months
- Nobody will own it after go-live and there is no budget for managed support. OpenStack punishes neglect faster than anything else we run
- What you actually want is containers. If the ask is that developers deploy without raising a ticket and the workload is stateless, Kubernetes on far less hardware is the honest answer
- The demand is spiky and small. Public cloud wins on economics until your utilisation is steady enough to make owned hardware cheaper, and we will run that comparison with you honestly
What you keep when we step back
Everything we build is reproducible without us, and we treat that as the actual deliverable. The deployment repository lives in your git from the first commit, so the whole cloud can be rebuilt by anyone who can read Ansible. You get the as-built architecture, the network and address plan, the storage layout with the reasoning attached, the tenancy and quota model, and an upgrade runbook that has already been executed once on staging rather than written from the documentation. We train your team on the API, the CLI and the admin console, rotate every credential to you, and stay involved only for as long as you want us to. Some clients hand the whole thing back to us as managed cloud infrastructure and never log into a controller again. Others run it themselves from week one. Both are good outcomes and we scope for either.
Tell us who is going to consume it
Answer what you know and skip what you do not. The tenancy question is the one that decides everything else, so guess at it rather than leaving it blank. A senior engineer reads every submission and comes back with a sizing view and a scoped price, usually within one business day. If OpenStack is the wrong answer for you, we say so.
Ready to discuss OpenStack Consulting?
A 30-minute scoping call, free, and it commits you to nothing.
How Every OpenStack Consulting Engagement Starts
Tenancy and workload discovery
A free session to work out who consumes the cloud, what they expect to self-serve, what the recovery targets really are, and whether OpenStack is the right answer at all.
Architecture and sizing
A written design: control plane, compute profile, the three networks, storage layout, tenancy and quota model, upgrade cadence, and one scoped price with the reasoning attached.
Build, migrate, prove
We build the cloud, move you in waves, pull a controller out in front of you to show what does and does not survive, and run an upgrade rehearsal before anyone signs it off.
Handover or managed operations
Repository, runbooks and training, then either your team runs it or we do, with monitoring, a yearly upgrade slot and a named engineer.