Where most MSPs say “we don’t do Linux,” we ask which distro.

The SMB Linux blind spot is structural, not accidental

The standard SMB managed-services stack is built around Windows RMM tooling, Active Directory, and Microsoft 365. That covers the desk. It doesn’t cover the systems behind the desk: the Ubuntu server running your internal apps, the Rocky Linux box handling CI/CD, the AlmaLinux container host, the pfSense or OPNsense appliance sitting between your network and the internet.

Most MSPs don’t ignore your Linux because they’re lazy. They ignore it because their entire toolchain was designed for Windows. Patching means Windows Update, not apt. Service health means SCM, not systemctl. When your Linux server needs a kernel update, their RMM either doesn’t see it or doesn’t know what to do with it.

The result: your Linux infrastructure runs unmonitored, unpatched, and outside the incident response plan — while the monthly invoice keeps coming.

What we cover

Distributions

We work across the mainstream Linux distributions in SMB production environments. Not “we support all Linux” — that’s the claim that means nothing. The specific ones we manage:

For each environment, the distro choice matters. Ubuntu LTS is a reasonable default for servers where long-support cycles and broad package availability are the priority. Debian stable is appropriate where minimal package churn matters more than recency. Rocky and AlmaLinux are the practical RHEL-compatible choices for environments that need that ecosystem without the subscription cost. We’ll have a real opinion on which is right for your workload — not just install whichever you ask for.

Network appliances

pfSense and OPNsense are the dominant open-source firewall platforms in SMB environments that chose to control their perimeter rather than outsource it to an ISP appliance. We manage both — firmware updates, rule audits, log review, and the pfSense-to-OPNsense migration question that comes up more often now that Netgate has changed its licensing model. If your network perimeter runs on one of these, it’s in scope, not carved out.

Patching and maintenance cadence

A Linux server that doesn’t get patched isn’t managed — it’s just watched. Our patching practice for Linux environments uses unattended-upgrades for security-only updates between maintenance windows, with scheduled maintenance windows for kernel updates and package upgrades that need review. For Ubuntu LTS systems this means tracking the -security and -updates pockets appropriately. End-of-life tracking is part of the job: Ubuntu 20.04 LTS hit end of standard support in April 2025; any system still on it is carrying risk.

Monitoring and log review

We monitor Linux systems with the same visibility we apply to Windows infrastructure — which requires specific configuration, not an assumption that the standard RMM agent covers it. Service health via systemd unit state monitoring, disk and memory pressure alerts, failed authentication tracking, and scheduled log review with logwatch are part of the standard practice. A Linux box that’s “just working” without active monitoring is a box you’ll find out about during an incident.

Workload types

Servers (web, application, database, file/NAS), developer workstations, container hosts running Docker or Podman, CI/CD runners, build infrastructure, and the network appliances already mentioned. For development environments where the team runs Linux desktops, we handle the infrastructure layer — we’re not a workstation-support service for developers who know what they’re doing, but we are the layer above the hardware that keeps those systems patched, backed up, and monitored.

Backups and recovery

Linux backup strategy depends on what you’re protecting. File-level backup with rsync-based tooling, snapshot-based backup for container hosts, and configuration backup (including pfSense/OPNsense config exports) are all different problems. We size the approach to the workload, not to a template.

The practitioner background behind this

Ryan, TCG’s principal practitioner, has run Linux systems since the late 1990s. That means familiarity with what Linux looked like before systemd replaced SysV init, what a production environment looks like when it depends on cron and shell scripts for its reliability, and what “kernel panic” means in a real operational context.

Prior work included managing Linux-based post-production infrastructure for a TV production company with petabyte-scale data requirements — high-speed storage arrays, disaster recovery systems, and the kind of infrastructure where data loss is not recoverable. That’s a different category of Linux administration than managing a single Ubuntu server, and it shapes the operational posture we bring to environments at any scale.

The current practice extends to modern Linux operations: configuration management via Ansible, container hosting on Docker and Podman, monitoring with the systemd/journald stack and Prometheus-compatible exporters, and CVE-response cadence tied to upstream security advisories for the distros in scope. The era reach matters — knowing what Linux looked like before systemd is useful for the legacy boxes still in SMB environments; knowing current operations is what gets the work done today.

The current daily work environment runs on Linux. This isn’t a claim about Linux as a philosophical preference — it’s a description of how we actually operate. When something breaks in a Linux environment at 11 PM, we’re not reaching for a tutorial.

On certifications: the honest position is that hands-on diagnostic depth has mattered more than cert status in every Linux environment we’ve worked in. The industry pattern of cert-holders who perform on paper but struggle in live environments is real, and it’s shaped how we weight credentials. Certifications do add client-verifiable value for a growing entity, and TCG holds and evaluates them on that basis.

Questions we get from buyers who’ve been burned before

What we don’t do

We don’t manage enterprise-scale Linux deployments: large data center environments, multi-region high-availability clusters, HPC farms, or environments that require 24/7 dedicated Linux staffing. Those require a different operating model and we’re not the right fit for them.

We don’t certify or attest compliance. We can harden Linux systems against CIS Benchmarks and support your preparation for SOC 2 or audit review — but we’re the team that does the work, not the assessor who signs off on it.

We don’t recommend migrating your Linux infrastructure to Windows or cloud-managed equivalents as the solution to Linux management complexity. You chose Linux intentionally. Our job is to manage what you have, not to convince you that the path forward is a platform you didn’t choose.

We don’t provide general-purpose Linux desktop support for development teams who are fully capable of managing their own workstations. We work at the infrastructure layer — servers, network appliances, shared infrastructure — not as Tier 1 helpdesk for a team of engineers who know their way around a terminal.

Linux, managed IT, and AI integration — the combination

TCG is one of the few PNW SMB-focused providers managing all three under the same flat-rate agreement: full managed IT, Linux infrastructure, and AI integration for the workflows that benefit from it. That combination matters because the systems are not separate.

When a client runs a self-hosted LLM inference endpoint on a Linux server — for document processing, internal search, or workflow automation — that server needs the same patching cadence, monitoring, and backup coverage as any other production system. An AI integration that runs on infrastructure nobody’s watching is a fragile integration. Our managed IT practice covers the layer the AI runs on, not just the application layer above it.

The Linux page and the AI Integration page are the same engagement for clients who have both needs. You don’t manage the Linux separately from the AI that runs on it.