DevOps and CI/CD Consulting in Kenya
Our infrastructure code is public, so you can read how we work before you hire us. CloudSpinx is a platform engineering consultancy in Kenya, and we build the delivery machinery engineering teams here and across East Africa run on: CI/CD pipelines, Kubernetes, Terraform, GitOps and the observability to see what production is actually doing.
Who we build for
- 14organizations, 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 DevOps & CI/CD Service
Every engagement covers the full scope: no hidden extras, no upselling.
CI/CD pipeline design
Build, test and deploy on GitHub Actions or GitLab CI, with approval gates where they matter, artifact promotion between environments, and a pipeline your team can debug without us.
Docker and containerization
Sensible base images, multi-stage builds that keep them small, a registry with scanning, and application configuration that comes from the environment rather than from a baked-in file.
Kubernetes
EKS, AKS, GKE, OpenShift or self-managed on bare metal. Autoscaling, ingress and TLS, resource requests set from measurement, and a straight answer on whether you need Kubernetes at all.
GitOps with Argo CD
Cluster state declared in Git, reconciled automatically, drift detected and corrected. Production changes become reviewable commits instead of somebody with kubectl access and good intentions.
Terraform and OpenTofu
Modules that other people can read, remote state with locking, plan output reviewed before apply. This is the bulk of what we contribute upstream, so it is the part we are hardest to beat on.
Secrets management
HashiCorp Vault or External Secrets Operator, short-lived credentials, and getting the secrets that are currently in your repository history out of it.
Observability
Prometheus, Grafana and structured logging, with alerts tied to what users actually experience rather than to CPU graphs nobody acts on.
Pipeline security
Dependency and image scanning in the pipeline, signed artifacts, least-privilege deploy credentials, and no long-lived cloud keys sitting in CI variables.
Team enablement
We build it with your engineers rather than around them, and hand over runbooks and training. A platform only your consultant can operate is a liability with a monthly fee.
Technologies we use
What DevOps work costs, and how we scope it
DevOps engagements are quoted per piece of work rather than per month, because the useful unit is a capability delivered rather than hours attended. A CI/CD pipeline for a single application is a small, well-bounded job. Migrating a hand-built estate into Terraform, or standing up Kubernetes with GitOps and observability, is a project with real discovery in front of it.
What moves the number
The number of applications and environments, whether your infrastructure is already codified or was clicked together, how many integrations the pipeline has to touch, whether you want Kubernetes or something simpler, and how much of the work is training your team against us doing it. Estates built by hand cost more to codify than greenfield ones cost to build, which is counter-intuitive until you have tried to import a few hundred untagged resources.
You can check our work before you hire us
Most consultancies ask you to take their engineering on trust. Ours is public. We rank 4th of all contributors to the largest of the infrastructure-as-code repositories behind Mojaloop, the open-source payment switch that national switches and central banks are built from, and 3rd on its Ansible and Crossplane repositories. That is the same discipline this page sells, written in the open under Apache 2.0, and you can read the review history before you send us a brief. The full ledger is on our engineering record.
Do you actually need Kubernetes?
Usually not, and we will say so before quoting for it. Kubernetes solves problems you get from many services, several teams deploying independently, and genuinely variable load. If you have three applications with steady traffic and one team, it adds an operational burden you then have to staff, and the cluster becomes the thing that breaks rather than the thing that saves you.
- Docker Compose on a couple of servers handles more production traffic than people expect and can be understood by one engineer at 03:00. For a lot of Kenyan businesses this is the right answer and nobody wants to sell it to you.
- A managed container service covers the middle ground: containers, autoscaling and rolling deploys without a control plane to run.
- Kubernetes earns it when you have many services, multiple teams needing isolation, real elasticity, or a platform requirement that already assumes it. At that point the cluster becomes its own engagement, and designing, running and upgrading it is where the ongoing work actually sits.
- OpenShift when you need commercial support and compliance certification, and can carry the license.
Getting infrastructure into code when it was built by hand
Almost every estate we are asked to codify already exists, which is the harder problem. Importing live resources into Terraform without an outage takes discipline: import in small batches, run a plan that shows no changes before you touch anything, and resist the urge to tidy while you import. We work module by module, leaving the estate importable and stable at every point, so the work can pause without leaving you half-managed. The output lives in your repository, and the state file is yours in your own backend rather than in ours.
Delivery on Kenyan bandwidth and Kenyan power
A pipeline designed on the assumption of a fast, always-present link behaves differently here. Container images pulled from a European registry on every build make a five-minute pipeline into a twenty-minute one, so a local or cached registry is worth more than most optimization. A self-hosted runner in the office is fast until the power goes and the build queue stalls with it. Where a team is distributed across Nairobi and Mombasa on different ISPs, the CI system needs to be the thing everyone can reach, which usually means hosted rather than on a machine under someone's desk. These sound small and they are the difference between a pipeline the team uses and one they work around.
When we tell teams not to buy DevOps work
The tooling is rarely the actual problem, and selling you a pipeline when it is not would be easy money and bad advice.
- If you deploy once a month and that is fine, a full CI/CD program will not pay back. Automate the test run, script the deploy, and spend the budget elsewhere.
- If your test suite is thin, fix that first. Automating deployment without tests means shipping breakage faster and more confidently, which is worse than deploying by hand.
- If one person holds all the knowledge, the risk is organizational rather than technical. Documentation and a second pair of hands beat a new platform, and no tool fixes a single point of failure who is a person.
- If you want us to run it forever, reconsider. We would rather build it with your engineers and leave. A platform that only its vendor can operate has just moved your dependency, not removed it.
What you own at handover
The pipeline definitions, the Terraform or OpenTofu modules and their state in your own backend, the Helm charts, the Argo CD configuration, the dashboards and alert rules, and runbooks written for whoever is on call rather than for us. All of it in your source control from the first commit, not delivered at the end. If you want continued support we are glad to provide it through a managed arrangement, and the test of whether we did the job properly is that you could decline and be fine.
Tell us how you ship today
Enough for us to propose the smallest thing that would actually help, rather than a platform you did not ask for. Every field has an escape hatch.
Ready to discuss DevOps & CI/CD?
A 30-minute scoping call, free, and it commits you to nothing.
How Every DevOps & CI/CD Engagement Starts
Review how you ship now
Repositories, environments, current deploy process, test coverage and the manual steps nobody has written down. Short, and it usually reorders the plan.
Design the smallest thing that helps
A target design and a first slice that delivers value on its own, so you get a working pipeline early rather than a platform in three months.
Build it with your team
Paired work rather than delivery over the wall, so your engineers can extend it. Each stage merged and usable before the next one starts.
Hand over and step back
Runbooks, training and an on-call handbook. Then support if you want it, and no dependency on us if you do not.