OUR DISCIPLINES
DevOps & Cloud Engineering in South Africa.
Every release that ships without drama runs on infrastructure someone made reliable. This is how DevOps and Cloud Engineering really works in South Africa: the roles, the market and what it takes to get it right, whether you’re hiring or building your own career.
A LOOK AT THE MARKET
The DevOps and Cloud Engineering market in South Africa.
The strange thing about this job is that when it’s done brilliantly, nobody notices. The site stays up, the deploys go out, the cloud bill behaves, and it all looks like nothing’s happening. The day people finally do notice is the day it breaks, and by then it’s a bank’s payments sitting in a queue, a POPIA question nobody wants to answer, or the company’s name in a headline for the wrong reason. That invisibility, right up until the moment it’s catastrophic, is what makes these people so hard to hire well and so easy to underestimate.
For a while, plenty of businesses did underestimate it. The cloud was going to be cheaper and simpler, so infrastructure got treated as plumbing, something you set up once and forget. Then the bills landed, nobody could fully explain them, and “just move it to the cloud” turned out to need real engineering. Now AI’s been added to the pile, and truthfully AI workloads are brutally unforgiving about both cost and scale they test a shaky setup fast. What most companies have worked out by now is that their gap was never someone who can write a Terraform module. It’s someone who can build things that stay up on their own, keep the spend tied to something the business actually values, and design security in from the start instead of bolting it on after the audit.
Which is why the market’s ended up in two very distinct places. Standing up a pipeline or wiring some infrastructure is a skill plenty of people have. Being the person who gets handed production, takes the 2am call, and is genuinely accountable when a bad deploy takes half the platform down with it, that’s a much smaller group, and they know their worth.
THE TITLE
What 'DevOps' in a job title actually means.
“DevOps” might be the most stretched word in tech hiring. It started life as a way of working, dev and ops pulling in the same direction instead of throwing work over a wall at each other, and somewhere along the way it got printed on business cards. Now it’s a catch all for four or five genuinely different jobs, and a “DevOps engineer” at one company can be doing almost nothing like the “DevOps engineer” at another.
So rather than chase the label, it helps to ask a pointed question: how much of production is this person trusted with, and how much breaks if they get it wrong? That single question sorts the field faster than any title. A cloud engineer is usually building and wiring up the infrastructure a business runs on. While a platform engineer takes that and turns it into something other engineers can build on safely, without needing to understand every layer underneath. An SRE is the one trusted to keep the whole thing standing under real load, take the call when it doesn’t, and own the fix. Same broad world, very different weight on your shoulders.
This is the bit that catches people out. Because the titles blur, businesses hire a builder when what they actually needed was someone to keep the lights on, or expect one person to do all of it, and only find out where the gap is when something’s on fire.
If you’re hiring, get clear on which kind of trust the role really carries before you write the spec. And if you’re the one deciding your next move, look past what it’s called to what it’s actually responsible for, because that, far more than the title, is what shapes where you can go from here.
THE ROLES
The roles, and what each one involves.
The easiest way to make sense of these roles isn’t the job title, it’s how close each one sits to live production, and how much of it is theirs to answer for when something goes down. The tools people reach for change all the time. The roles themselves are pretty steady, and these are the ones you’ll keep running into.
Cloud architect
Designs how a business runs in the cloud: the landing zones, networking, security and cost model everything else is built on. A senior role focused on the bigger picture, and the one that matters most in large or regulated environments.
Common tools: AWS, Azure or GCP, Terraform, network and IAM design, and cloud cost and governance frameworks.
Cloud engineer
Builds and runs the infrastructure a business depends on, turning architecture into working, provisioned environments. Often the foundation the rest of the team builds on, and increasingly expected to own security and cost as well as uptime.
Common tools: AWS, Azure or GCP, Terraform or Pulumi, scripting in Python or Bash, and infrastructure as code.
DevOps engineer
Sits between development and operations, building the pipelines and automation that get code from commit to production safely. Owns how software ships, not just where it runs. A broad role that means very different things depending on the team.
Common tools: CI/CD tooling such as GitLab, GitHub Actions or Jenkins, Docker, Terraform, and scripting.
DevSecOps engineer
Builds security into the pipeline rather than bolting it on at the end, so compliance and safety travel with the code. Increasingly valued where regulation, POPIA or audit scrutiny is part of the picture.
Common tools: CI/CD security scanning, secrets management, policy as code, container security, and IAM.
Kubernetes | container engineers
Runs the container platforms that modern workloads sit on, keeping clusters healthy, scalable and secure. A specialist role where the depth of production experience is often what separates people, not the certification.
Common tools: Kubernetes, Docker, Helm, service mesh, and cloud-managed container services (EKS, AKS or GKE).
Platform engineer
Turns raw infrastructure into something other engineers can safely use without needing to understand every layer beneath it. Builds the internal platforms, guardrails and self-service that let teams move faster. A newer role, and an increasingly valued one.
Common tools: Terraform, Kubernetes, internal developer platforms, CI/CD, and Go or Python.
Site reliability engineer (SRE)
Keeps production standing under real load, owns uptime and the response when things break, and is accountable for the fix. Part software engineer, part operator, and in short supply.
Common tools: observability and monitoring (Prometheus, Grafana, Datadog), incident tooling, Kubernetes, and scripting.
Systems | Infrastructure engineer
Builds and maintains the servers, networks and core systems a business runs on, across cloud and on-premise. The reliability layer beneath everything else, and the role that matters most where legacy and modern estates sit side by side.
Common tools: Linux, networking, scripting, virtualisation, and cloud platforms.
Other disciplines we recruit in
Software engineering · Data and Analytics · Project and programme management and more
IF YOU'RE HIRING
Hiring someone you can trust with production.
The tricky thing about hiring for this is that the moment that actually matters, how someone behaves when production is down and everyone’s looking at them, is the one moment an interview never gets to see. Anyone can look calm across a table. So the job is finding a way to see it anyway, before you hand over the keys.
Skills are the easy bit to check, and the least useful. Plenty of people can write Terraform or stand up a pipeline, but in the interview phase, you really need to work out whether you can trust this person with the thing you can’t afford to lose, and that starts with being honest about what the role is genuinely on the hook for.
The way we get at it is to stop asking what they know and start asking what they’ve lived through. A deploy that took half the platform down, a cloud bill that quietly tripled before anyone noticed, a moment where the fast fix and the safe fix pointed in opposite directions and they had to pick. How someone talks about those, what they did, what they’d do differently, whether they own the mistake or dodge it, tells you more than any technical round.
Don’t forget to listen for the quieter signals too: the good ones are careful about what they automate, quick to say when they’re not sure, and able to admit a gap to someone senior without getting defensive. In a business where an hour of downtime is measured in lost revenue, that honesty is worth more than another line on the CV.
WHY LEVELS MATTER
Understanding seniority.
Here is a top line view of what each level looks like in practice, whether you are writing a brief or working out where you sit.
-
A junior learns quickly and delivers well-defined pieces of work with support: writing pipeline steps, scripting automation, fixing failing builds and handling routine tickets. The good ones are curious about why the system is built the way it is, ask before they change something in production, and become more reliable month on month. You are hiring for attitude and safe instincts more than finished skill.
-
A mid-level professional works independently and owns a defined area, whether that is a set of pipelines, a cloud environment or a service in production. They can be trusted to deliver without close supervision, and they understand why an approach is safe, not just that it works. They are usually in the on-call rotation and can hold their own when something breaks.
-
A senior engineer designs the approach, anticipates where the infrastructure will fail before it does, and improves how the whole team ships. Seniors are measured by the incidents they prevent and the reliability they build in, as much as by the systems they stand up, and by the people they make better around them.
-
A lead or principal sets technical direction, holds the standard, and translates between the platform team and the business. At this level the work is as much about judgement, cost, security and knowing which problems are worth solving as it is about the hands-on build.
Skills that command a premium.
There’s a rough rule in infrastructure: the further your work is from the thing that breaks, the less it pays. Setting up a pipeline is useful, but it’s also something a lot of people can do, so the rate for pure build work keeps drifting down. The real money sits with the people who are trusted when it counts, the ones who can keep a system upright under load they didn’t expect, or make a platform faster for everyone without quietly making it less safe, or keep a regulated environment in a state you could actually defend to an auditor.
Underneath all of that, the unglamorous fundamentals still pay everywhere, because everything else is built on them: solid Linux, real networking, scripting that isn’t held together with hope. And there’s one combination that’s worth more than the sum of its parts, especially in banking, insurance and fintech, someone who’s genuinely technical and understands security, compliance and cost. That mix is hard to find and expensive to get wrong, so the people who have it name their price.
If you’re hiring, the truth is that the skills you’ll pay most for are usually the least visible ones. For professionals building a career, the lesson is the same from the other side: going deep enough that a business would trust you with production is worth far more than adding another year of a bit of everything.
Understanding the salary package.
In South African infrastructure roles, the real value is spread across the whole package, not just the base. Some of it is the standard stuff that quietly adds up: medical aid and retirement, where employer contributions vary widely, and bonuses or equity that can outweigh base pay over time.
Some of it is specific to this world, like on call and standby allowances, which stop being an afterthought the moment you’re the one carrying the pager. And remote or hybrid working is now weighed as heavily as pay by a lot of people.
Then there’s the part that never shows up on a payslip but shapes your next few years: real exposure to modern cloud platforms, harder problems at scale, and the freedom to fix things properly rather than just patch them.
None of this means the number doesn’t matter, it does, and lowballing loses good people fast, but base pay is the easy part to match. What’s harder to copy is everything around it: who you learn from, what you get to work on, and whether you’re trusted to do the job properly. That’s usually what a move really turns on.
THE COST
Contract vs Permanent.
In infrastructure, the contract versus permanent call comes with a catch that most fields don’t have. To do the work at all, a contractor usually needs deep access to your production systems and credentials, the keys to the things that cannot go down. So before you get anywhere near a day rate, the real question is who you’re willing to hand that access to on a short-term basis, and whether you can govern and pull it back cleanly when the work’s done.
Where it’s the right call, though, it’s clearly the right call. A lot of infrastructure work has an obvious shape and a finish line, a cloud migration, a platform build, a Kubernetes rollout, a burst of work no sane business would grow a permanent team around. For that, a contractor is exactly right: the specific skill you need, for precisely as long as the project runs, and gone the moment it’s done. The day rate looks steep next to a salary, but you’re not paying for benefits or notice or loyalty, you’re paying for capability, right now, and only for as long as you need it.
For a business, then, the honest question isn’t really about cost per day, it’s whether a problem with an end date deserves a hire without one. And for the engineer, contract is a real path rather than a consolation prize: better day rates, more variety, a run of interesting problems to fix and move on from. What you trade away is stability and the trust that only builds by sticking around. That suits some people, and some points in a career, far more than others.
DevOps & Engineering Salaries in South Africa.
FOR CONTRACTOR ROLES
Seniority
Indicative hourly rate
> Junior engineer
R450 – R550
> Mid-level engineer
R700 – R800
> Senior engineer
R1000 – R1200
> Lead or Principal engineer
R1200 – R1600
FOR PERMANENT ROLES
Seniority
Annual cost to company
> Junior engineer
R600K – R750K
> Mid-level engineer
R900K – R1.3M
> Senior engineer
R1.4M – R1.6M
> Lead or Principal engineer
R1.7M – R2.3M
Figures are drawn from Acuity’s own placements across the South African market and are indicative ranges, not quotes. Actual pay and rates vary with specific skills, sector, location and how in-demand a role is at the time. Contractor rates are excluding VAT. Last reviewed: July 2026
IF YOU'RE BUILDING A CAREER
Making your next DevOps or Cloud engineering move
a good one.
Nobody remembers the deploy that went fine. In this field your reputation is built entirely in the bad moments, the outage you caught before it spread, the rollback you called right when everyone was tense, the fix that actually held. That track record ends up meaning more than any title, and a role where you genuinely own production will take you further than a senior-sounding line on an org chart with nothing real beneath it.
So when you start looking, get clear on what you actually want handed to you next, because that’s the thing that’ll grow you. Lots of people can reel off the tools they’ve used. The ones who get ahead can walk through a decision that mattered, why they made the call they did under pressure, and what they’d do differently now. If you can talk about your work like that, you’re already showing a serious employer the exact thing they’re trying to find.
And here’s how we work with you. We take the time to understand where you’re trying to get to, not just what’s already on your CV, and we only put you forward for roles that move you that way. You stay in control the whole way through, and we’d genuinely rather point you at the right role than hurry you into the nearest one.
COMMON QUESTIONS
DevOps & Cloud Engineering questions, answered.
FOR BUSINESSES LOOKING TO LEAD, BUILD & SCALE
Our cloud bill keeps climbing and nobody can explain why. Is that a hiring problem?
Runaway spend usually means nobody owns cost as part of their actual job, so it grows unchecked between projects.
The fix is someone who treats spend as a design constraint, not an afterthought, whether that is a cloud engineer with FinOps instincts or a dedicated hire once the estate is large enough. We can help you work out which you need.
How do we hire someone we can safely give production access to?
This is the question that matters most and the hardest to answer from a CV. Certifications tell you what someone has studied, not how they behave when a system is down at midnight.
We screen for track record under pressure: real incidents handled, calls made, and how someone thinks about the blast radius of a change before they ship it.
Should we build a permanent platform team or bring in specialists for the migration?
It depends on whether the work has an end. A migration or a Kubernetes rollout is a project with a finish line, and a contractor sized for it makes sense. Keeping the lights on afterward is permanent work. The common mistake is hiring permanent heads for a spike, then carrying the cost long after the spike is gone.
How long does it take to hire a strong DevOps or cloud engineer in South Africa?
Longer than most teams expect, because the people worth hiring are usually employed and quietly fielding offshore offers. Budget for a real search rather than a quick fill, and be ready to move fast once you find someone, since the strong candidates rarely stay on the market long.
FOR PROFESSIONALS EXPLORING
Should I specialise or stay broad?
Early on, breadth helps you find what you are good at and enjoy. After that, the market pays for depth, particularly in the areas it struggles to staff and trust, like reliability, platform work and security. We can help you read where the scarcity sits and where your earning power actually grows.
I don't have a computer science degree. Does that count against me?
Less than you would think in this field. Infrastructure is judged on what you can run and keep running, and a lot of strong engineers came in sideways from sysadmin, support or development.
A visible track record, a few things you have genuinely operated in production, tends to speak louder than the qualification.
What actually makes a candidate stand out?
Evidence that you can be trusted with real systems. Anyone can list tools; far fewer can walk through an outage they owned, a cost problem they solved, or a platform decision that paid off later. Being able to explain your reasoning, including what you would now do differently, is what separates people.
Do you place contract and permanent roles, and can you help with remote work?
Yes to all three. We work across contract and permanent, and remote is a growing part of what we do, including roles with international teams. We will talk through the trade-offs honestly, since a higher day rate or an offshore salary is not automatically the right move for where you are.