Server management that keeps Linux patched, hardened, and documented.

Server management is the ongoing administration that keeps a server available, secure and performing: applying OS patches, hardening the configuration, controlling drift, watching for trouble, and verifying the backups. It matters because most outages are self-inflicted — configuration errors cause a large share of them and unpatched software remains the first way in. Argus Root administers Linux servers wherever they run, yours or ours, inside the EU, and keeps a fleet at a measurable baseline rather than letting it drift.

NIS2 turned patching from hygiene into an obligation. Security updates have to be installed within a reasonable window and verifiably, which means prioritised, tested, documented and rolled out in a way you can show an auditor, rather than applied at some point and forgotten. We run patch management that produces that record by default, on a hardening baseline drawn from the CIS Benchmarks, with configuration managed through Ansible so nothing drifts between one server and the next.

That keeps the server layer audit-ready and feeds the wider picture. Detection and response above the operating system sit with our managed security, the monitoring with observability, the restore side with backup and disaster recovery, and the evidence trail with compliance.

The proof is the part most teams cannot produce on demand. An auditor does not want a claim that you follow best practice; they want measurable evidence with timestamps: the CIS benchmark score for each host, the date a given CVE was patched, the rationale where one was deferred. We generate that from the tooling rather than assemble it by hand before an assessment, running OpenSCAP CIS scans that produce a rule-level compliance score, so the answer to "show me" is a report rather than a scramble. Patching on Linux is a discipline you maintain rather than a problem you solve once, and the record is what shows you have maintained it.

Server administration is the work we have done longest. We run fleets of Linux servers on our own infrastructure and built the management framework we use to do it, thousands of lines of tooling for patching, hardening and operations refined against real production. We are honest about the lane: this is Linux administration, on AlmaLinux, Ubuntu and Debian, with response driven by runbooks and proactive monitoring rather than a promise of a 24/7 analyst desk we do not staff. The result is a server that is patched, consistent and accounted for, run by the people who built their own way of doing it.

# /etc/ssh/sshd_config — keys only, no root, fail fast
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
LoginGraceTime 20
MaxAuthTries 3
AllowGroups ops

# /etc/sysctl.d/60-hardening.conf — drop spoofed + redirected packets
net.ipv4.conf.all.rp_filter        = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
# validate before reload: sshd -t && systemctl reload ssh

A freshly installed server is not a secure one. It ships with default accounts, open services, permissive settings and password logins, all of which an attacker enumerates within minutes of it appearing online. Hardening removes that easy attack surface before anything else is done: SSH keys and MFA in place of passwords, a tightened firewall, the unused services and defaults disabled, and mandatory access control through SELinux or AppArmor so a compromised process is boxed in rather than free to roam the host.

We harden to the CIS Benchmarks, the published, specific baselines for each operating system, rather than to a private notion of good practice, because a named standard is auditable and a personal one is not. The compliance is measured with OpenSCAP scans that score each host against the benchmark and flag where it falls short, so hardening becomes a number to track and improve rather than a one-time checklist. A well-hardened server is also a more stable one, which is part of why it survives a patch with fewer surprises and presents a smaller target in the first place.

Some patches need a reboot, and a reboot is its own risk: a server that has run for a year may not come back cleanly, and the downtime has to be scheduled around the people who depend on it. Kernel updates are the usual culprit, and the choice between rebooting now and staying exposed is a real one when the flaw is being exploited. Where it fits, live kernel patching applies the fix to a running kernel without a reboot, closing the vulnerability without the outage or the gamble of a restart.

Where a reboot is unavoidable, it is planned rather than sprung: the dependent services identified, the restart sequence known, the rollback ready, and a tool like needrestart used to catch the processes still running old libraries after an update, so the patch is genuinely in effect rather than merely installed. The aim is an update that is fully applied and a system that comes back exactly as expected, instead of a patched server sitting one reboot away from a surprise nobody scheduled.

Server management is the discipline, not a tie to where the server lives. We administer Linux on your own hardware, in your cloud account, or on our infrastructure, and the patching, hardening and configuration are the same regardless of where the metal sits. That separates this from a hosting plan, where the management comes bundled with the data centre and ends at its door.

The hybrid estate that most organisations really run, a mix of cloud instances, on-premise boxes and the occasional legacy machine, is the harder case and the one this is built for. Managing updates and configuration consistently across that fragmented estate is the real work, and doing it from one defined state rather than three separate habits is what keeps a mixed estate coherent. You decide where your servers run; we keep them in order wherever that is.

An unmanaged server tells you it is in trouble by going down. A managed one is watched so the trouble is caught while it is still a warning: a disk filling, a service flapping, memory creeping up, a daemon that died and did not restart. Resource, service and availability checks run continuously and surface the problem to us before it reaches your users, which is the difference between a quiet fix at 2am and an outage everyone notices by 9.

The monitoring is wired into the same observability stack we run rather than a separate dashboard nobody watches, so a server signal sits alongside the application and infrastructure picture and a pattern across them is visible rather than scattered. The point is to act on the few metrics that predict a failure rather than collect numbers for their own sake, turning maintenance from reactive firefighting into the unremarkable business of fixing small things before they become large ones.

A server sized for last year's load is a slow outage waiting to happen. Performance work is the unglamorous maintenance that keeps a system responsive as it grows: tuning the configuration to the workload, right-sizing the resources so you are neither starved nor paying for idle capacity, and watching the trend so the wall is seen coming rather than hit. A database that has quietly outgrown its memory, a disk approaching full, a connection limit about to be reached, each is a failure that announces itself in advance to anyone watching the right number.

We read the growth rather than react to the crash, so capacity is added on a plan and tuning happens before a slowdown becomes a complaint. The same view feeds sensible decisions about when a workload should move to bigger hardware, scale out, or simply be configured better on what it already has. Most performance emergencies were predictable months earlier; the work is noticing in time and acting while the fix is still cheap.