Senior Linux engineering for fleets you want to stop thinking about.
Kernel tuning, systemd quirks, and the patch policy that keeps your servers boring on Mondays. Ubuntu, Debian, RHEL, AlmaLinux, Rocky, SUSE, and NixOS, run by people who have been on the rotation.
- Ubuntu · Debian · RHEL · AlmaLinux · Rocky · SUSE · NixOS
- systemd · kernel tuning · sysctl · cgroups v2 · eBPF
- apt · dnf · zypper · nix · unattended-upgrades · dnf-automatic
- patch policy · CIS baseline · auditd · SELinux · AppArmor
Linux Engineering, in plain terms.
Senior Linux sysadmin and engineering — kernel tuning, systemd quirks, and the patch policy that keeps your fleet boring on Mondays. We come in when the boxes are doing something weird and the team that built them has moved on, or when you need a real standard built before the fleet doubles.
We run every major distribution in production and we are opinionated about which one fits which workload. Ubuntu LTS is the default for developer-led fleets and hyperscaler AMIs where image parity matters. Debian stable is what we reach for on long-cycle infrastructure — routers, jump hosts, anything that should outlast the team that built it. RHEL is the answer when a regulated workload needs a vendor support contract; AlmaLinux and Rocky are the supported community rebuilds we recommend for everyone who used to run CentOS and got caught flat-footed by the Stream pivot. SUSE Linux Enterprise Server still owns the SAP and enterprise storage corner of the rack. NixOS is where we go when you want declarative, reproducible, immutable hosts and have the team to carry the learning curve.
We write the runbooks, set the patch cadence, and tune the bits that actually matter — process and I/O schedulers, networking sysctls, file system mount options, cgroups v2 limits, journald retention, eBPF observability hooks, and the unit files that nobody reads until they fail. Patch automation rides on unattended-upgrades, dnf-automatic, zypper-automatic, or Nix channel pinning depending on the distro, and the policy is written down so an auditor can read it without us in the room.
Because we also run our own infrastructure on AS54098, we know what a healthy Linux host looks like under real production traffic, not a benchmark. That experience shows up in the recommendations we give: small, defensible, and documented enough that the next engineer can pick it up.
Common triggers for this engagement.
- 01Your fleet has grown past the point where one person can hold it in their head
- 02Patching is ad hoc and you want a written, repeatable policy you can show an auditor
- 03A host is misbehaving under load and you need someone who can read a flame graph without flinching
- 04You are moving to NixOS or immutable images and want senior eyes on the rollout
- 05You inherited a CentOS fleet and need a tested migration path to AlmaLinux or Rocky
- 06An LTS or vendor-support lifecycle is ending and you need a planned upgrade, not a fire drill
Questions teams ask before signing.
Which distributions do you support in production?
Ubuntu LTS, Debian stable, RHEL, the supported RHEL rebuilds (AlmaLinux and Rocky Linux), SUSE Linux Enterprise Server and openSUSE Leap, and NixOS. We will work on others when there is a good reason — Amazon Linux, Oracle Linux, Arch in a niche role — but we are honest when a stack is outside our daily reps.
Do you handle kernel tuning, or only userspace?
Both. We tune scheduler, network stack, and I/O parameters for real workloads, and we are comfortable with custom kernels when a vendor module or a low-latency requirement demands it. We also use eBPF and bpftrace for production observability rather than guessing.
Can you take over patching for our fleet?
Yes. We design the patch policy, build the automation, and can run the rotation ourselves or hand it to your team with the runbooks. Either way you get a written cadence and a paper trail.
What is your stance on CentOS Stream versus AlmaLinux and Rocky?
For most production fleets we recommend AlmaLinux or Rocky Linux. Both are bug-for-bug RHEL rebuilds with corporate sponsorship and a credible long-term release cadence, which is what the CentOS user base actually needed. CentOS Stream is a defensible choice for upstream RHEL development and for teams that genuinely want the rolling-preview position, but it is not a drop-in replacement for the CentOS Linux that shipped through 2021.
Do you have an opinion on Ubuntu versus Debian for production servers?
Both are first-class and we run them in production. Ubuntu LTS is the right default when you want hyperscaler AMI parity, a shorter release cadence, and Canonical's commercial support options. Debian stable wins for very long-cycle infrastructure where you want the smallest possible base, a slower-moving release train, and the longest-running community packaging discipline in the ecosystem. We pick per workload, not per dogma.
Frequently scoped alongside this work.
DevOps
CI/CD that ships, infrastructure-as-code that holds together, and an on-call rotation an engineer can actually live with. We build the pipeline with your team, then walk them through running it.
Custom Server Deployments
Bare-metal spec, procurement, and deployment for GPU clusters, storage servers, and edge appliances. We have shipped from a single 1U through 40U-plus buildouts.
24/7 NOC
Eyes on your network around the clock, run by the engineers who write the runbooks. Pages routed to humans, not a ticket queue — for incidents that need a real person at 3 a.m.
Compliance Readiness
Mapping your environment to the controls auditors actually check, and closing the gaps before the audit window opens. We've sat on both sides of that table.