Hello, I’m Keith. I’ve been working with Linux since before it was cool, and I run a company, Tiger Computing, that helps businesses across the UK manage their Linux infrastructure.
Over the years, we’ve worked with plenty of Managed Service Providers (MSPs) – some with Linux expertise, most without – and I’ve seen the same thing happen time and time again:
A client drops you a ticket or calls your support desk and casually says,
“We’ve just added a new Linux server to handle X. Can you look after it for us?”
And just like that, you’re responsible for something your team hasn’t touched since uni. Or ever.
So, what now?
This article is for MSPs who don’t have Linux expertise in-house but are suddenly faced with a client environment that includes one (or more) Linux boxes. I’ll walk you through your options, common pitfalls, and how other MSPs handle this without risking the client relationship, or losing their minds.
Don’t Wing It: Why Supporting Linux Servers Is Different
Let’s get this out of the way early: Linux is not just “Windows but with a CLI”.
Yes, it’s still a server. Yes, it still runs file systems and network services. But the moment you assume it works the same way as Windows, you’re in for a very long afternoon.
I’ve seen well-meaning engineers reboot production servers because they thought that was the best way to fix the problem. I’ve seen permissions changed recursively across an entire filesystem. Once, someone deleted /bin. (That machine didn’t make it.)
If you don’t know Linux, guessing is expensive. Especially when there’s no System Restore button.
So, What to Do When a Client Asks You to Support a Linux Server?
Here’s what most MSPs do when a Linux-shaped challenge lands on their desk:
1. Ignore It (and hope it goes away)
Tempting. But dangerous. Linux often powers critical services; databases, file shares, container hosts. Pretending it’s not there rarely ends well.
2. Try to Handle It In-House
This might work if someone on your team happens to have a bit of Linux experience. But there’s a difference between “once installed Ubuntu on a laptop” and “knows how to secure and monitor a production Linux server running PostgreSQL.”
If you want to go this route, be honest about your limits, and don’t be afraid to say, “We’ll get back to you once we’ve looked into it.”
3. Google Everything and Hope for the Best
We’ve all done it. But relying on Stack Overflow threads from 2014 to manage a client’s live infrastructure is not ideal. And frankly, it’s not fair on your engineers.
4. Partner with a Linux Specialist
This is the route more and more MSPs are taking, and not just because I’m writing this article. When done properly, it allows you to say yes to your client, without putting your team (or reputation) at risk.
Real-World Examples: How Other MSPs Handle Linux Support
We work with MSPs in a few different ways, depending on what they need. A couple of examples:
- One MSP had a client with an ageing on-prem Linux file server and no clear way to back it up or migrate it. We scoped the project, handled the work under their brand, and kept their project manager as the main point of contact throughout.
- Another MSP came to us when a client’s web application started throwing 500 errors. Their team couldn’t locate the logs or trace the issue, so we stepped in, fixed the problem, and passed on some practical advice to help them handle similar issues in future.
- A third MSP was supporting a long-term client with several legacy Linux servers running overnight business-critical tasks. With no in-house Linux expertise and concerns mounting around patching and performance, they brought us in on a monthly support contract. We now manage the Linux estate 24/7, from routine maintenance to incident response, while the MSP retains full control of the client relationship.
In all these cases, the MSP kept control of the client relationship. We weren’t interested in managing the full environment or upselling anything. (We don’t do Windows. We don’t do M365. We don’t do other managed services. Just Linux. Honestly, we’re quite boring that way.)
Why Not Just Hire a Linux Engineer?
Good question. Here’s why most MSPs don’t:
- They’re hard to find. Linux engineers are in short supply; and the good ones aren’t cheap.
- You might not need one full-time. A handful of Linux servers across a few clients doesn’t justify a permanent hire.
- It takes time to upskill your team. And if they’re already flat out with Microsoft tickets, that time doesn’t exist.
If you’re getting more Linux requests and you’re not ready to build that capability in-house, partnering makes a lot of sense.
Common Mistakes MSPs Make When Supporting Linux
Just to round things out, here are a few things I wouldn’t recommend:
- Don’t pretend you’ve got it covered if you don’t. Clients appreciate honesty more than heroic guessing.
- Don’t assume Linux is secure by default. It’s not. Leaving it unpatched because “no one knows how it works” is a great way to get hacked.
- Don’t hand off responsibility to the client. They came to you because they trust you. Even if you bring in a partner, you’re still their go-to.
The Smarter Way to Support Linux as an MSP
Linux isn’t going anywhere. In fact, with more businesses using containers, cloud-native apps, and AI workloads, it’s cropping up in client environments more than ever.
If you’re an MSP focused on Microsoft technologies, that doesn’t mean you have to miss out; or overextend your team. There is a middle ground between saying no and spinning up a whole new department.
And if you ever need a Linux expert in your corner. I know just the team.
Request a call back and we’ll talk through how we support MSPs just like you.
