Subscribe to GEN
Login to GEN
Patching a Linux estate properly is not switching on automatic updates and hoping. Every week an engineer assesses what is waiting across your hosts, decides what is in scope and what is held, and sees it applied. Critical fixes are not held for the weekly run: they are assessed as they land and rolled out to your hosts in order of exposure, with every host's result checked.
It covers everything on the box that comes from a package manager, from the kernel and OpenSSL to PHP, Python and the database, across the Red Hat family, Debian, Ubuntu and Arch, for one fixed monthly fee for the whole estate. When an update breaks something the fee does not cover, it is escalated to an engineer rather than left for you to find.
Applying every update the moment it appears, on every host, is not patch management. It is handing the decision to whoever published the update, and finding out what it did afterwards. Done unmanaged, it makes for an unstable estate: every update is a change, and many introduce more problems than they solve, a regression here, a changed default there, a service that no longer starts.
Most of what lands is not in scope anyway. A fix for a feature you do not use, a component that is not exposed, or a bug that cannot occur on your configuration carries all of the risk of the change and none of the benefit. Our approach is the other way round: an engineer decides what is worth applying, and the tooling carries it out.
Each week your estate is assessed and scoped. Hosts are grouped by distribution, release and architecture, so like is handled with like, and the engineer works through what is waiting for each group: what goes in this week's run, what is held for an application that depends on it, and what needs a word with you first. Everything in scope is then applied at the weekly run, and every host reports back what it did.
Updating a library is not the end of it. A service still running the old copy is still exposed, so each host reports which services are running code that has since been replaced, and whether it needs a reboot, and those are dealt with as agreed rather than left until the next power cut.
A critical fix does not wait for the weekly run. It is triaged once by an engineer for every client it affects, and then seen through to each estate: one search finds every host running the affected package and the version it is on, and the fix goes to all of those still behind, with a reboot afterwards only where the host says it needs one.
When your estate is scoped, hosts are ranked by exposure, and you can ask for priority on the ones that matter most. When something critical lands, those go first. Where a fix is announced in advance, our Cyber Alert reaches you before it arrives, and the work is already planned.
On 21 October 2026 the PHP project released fixes for two vulnerabilities rated 9.2, which became known as PHP2Shell. Patching started the moment the fixed packages appeared, about 30 minutes after release, and around 3,900 client hosts were patched: the 1,700 classed as high risk first, then the rest. Our own servers went last. The full account is in our blog.
Operating system updates are only part of what runs on a server. The flaws that matter most are as often in the language runtime, the web server or the database as in the kernel, so the service covers every package each host installs from a repository it trusts, including the third-party repositories that supply most production PHP, Node.js and database builds.
Hosts running Proxmox, KVM, LXC, Docker or Podman are recognised and held back from bulk upgrades, because restarting their services takes every guest down with them. On a Proxmox node the kernel, Proxmox and Ceph packages are done by an engineer, by hand, and the node is never rebooted by the agent.
Libraries an application installs for itself, with composer, pip or npm, belong to that application and change with it. We review and update them as engineering work, alongside whoever maintains the code, rather than under a weekly run that cannot know what they will break.
£175 a month covers an estate of up to 100 hosts, and each host above that adds £2.50 a month. The fee covers the weekly assessment and run, priority patching when something critical lands, your monthly report, and fixing anything that goes wrong in the package manager while it is done.
| Estate | Monthly fee | Per host |
| 20 hosts | £175 | £8.75 |
| 100 hosts | £175 | £1.75 |
| 500 hosts | £1,175 | £2.35 |
| 1,000 hosts | £2,425 | £2.43 |
Escalated work is raised as a ticket, handled by an engineer and charged as engineering time at our published rates, from prepaid hours where you hold them. Preventative maintenance carries on as before, under your maintenance plan or at published rates.
Most compromised servers we are called to were not breached by anything new. The flaw was known, the fix had been published, and it had not been applied, often for months. The time between a fix being published and the flaw being exploited is now measured in days, sometimes hours, because the fix itself shows an attacker where to look.
It is also no longer only good practice. Cyber Essentials requires critical and high risk updates to be applied within 14 days of release, insurers ask for evidence of patching before they renew, and under UK GDPR leaving a known, fixable weakness in place is hard to defend as an appropriate technical measure after a breach.
Automatic updates do not meet that standard on their own. They apply everything without anyone deciding whether they should, they fail quietly on a mirror blip or a half-configured package and leave the host further behind each night, and they say nothing about the services still running old code. Nobody is told, and nothing records what was done. Patch management is the decision, the checking and the record, as much as the update itself.
Patching is the one process with the right to change every server you have, so it should not be possible for any single party, ourselves included, to turn it against you or take it down with them. The service is built so that no one vendor's mistake, compromise or change of terms reaches your whole estate.
When the agent is installed, the distribution's own automatic update timers are turned off, and turning one back on is reported. An upstream update that turns out to be faulty does not land on every host overnight unattended: it is assessed first, and can go to one host or group and be checked before the rest.
The agent can upgrade or remove packages from repositories the host already trusts, and reboot. It cannot install arbitrary software, run a command, add a repository or import a key, and it refuses to remove the package manager, SSH, systemd, networking or the running kernel. Whoever controlled the other end could not use it to become root on your servers.
Patching works the same on your premises, in our data centres or with any other provider, and the same across distributions. Change provider, or move from one distribution to another, and your patching carries on unchanged, under one record, rather than depending on whichever vendor supplies the platform.
Every update comes from your distribution's own repositories, or the third-party ones you have chosen, and is checked against their own signing keys. Every change is tagged in the host's own package history with the instruction behind it, so the record survives on the host itself, whatever happens to any service outside it.
A small agent on each host reports to Oversight every five minutes: what is installed, what is waiting with its advisory and CVEs, whether a reboot is needed, and every transaction the package manager has run. It opens no port and needs no SSH. Each host calls out over HTTPS, signed with its own key, and instructions come back in the reply, so hosts on your own network or behind NAT work exactly as ours do.
The same record raises alarms for what should not happen quietly: a package installed outside the package manager, a repository added, a new start-up or scheduled entry, or a kernel, microcode or BIOS change nobody asked for. Those are the changes that matter most on a host meant to stay put, and they are brought to an engineer rather than buried in a log.
Each Linux system with the package agent installed, physical or virtual. The fee is worked out from the number of hosts on your estate each month, so adding or retiring a server changes it the following month.
No. The agent works the same on your own premises, in our data centres or with any other provider, including hosts behind NAT. It calls out to Oversight over HTTPS and needs no inbound access, no SSH and no firewall rule.
The Red Hat family (AlmaLinux, Rocky Linux, RHEL and Oracle Linux), Debian and Ubuntu, and Arch, Manjaro and EndeavourOS. SUSE is not covered at present.
This service covers Linux. Windows machines are patched through GENAMS, our asset management system, which is a separate service with its own page under Support.
Only where a host reports that it needs one, and only within the windows agreed when your estate is scoped. A reboot is counted as done only when the host checks in again on its new boot. Proxmox nodes are never rebooted by the agent; an engineer does it by hand.
Yes. The weekly scoping decides what is in scope for each group of hosts, and a package you need held, for an application that depends on a particular version, stays held until you tell us otherwise. Holds are recorded, so the reason is there for whoever looks next.
A failure in the package manager itself, a half-finished transaction, a repository or key problem, a dependency conflict or a service that will not restart, is ours to fix within the fixed fee. Anything at application level is raised as a ticket and escalated to an engineer, charged as engineering time at our published rates, from prepaid hours where you hold them.
Patching applies what each distribution still publishes, so a release that no longer receives fixes cannot be kept safe by patching alone. We tell you which hosts are in that position, and can keep them running safely or move them to a supported release as separate work.
Language runtimes are, PHP, Python, Perl, Ruby, Node.js and Java included, wherever they come from a repository the host trusts. Libraries an application installs for itself with composer, pip or npm belong to that application, and are reviewed and updated as engineering work.
