The inventory
Distribution, release, and every installed package with its version — for machines you set up last week and for the one nobody has logged into since spring.
Linux patch management · Debian and Ubuntu
Patch status for every Linux server you run.
unattended-upgrades is running on most of them, and you could not say which machine it ran on last night — or which one is still on a release that stopped getting updates months ago. PatchPilot puts the whole fleet in one table: what is installed, what is pending, what is waiting for a reboot, and what has quietly run out of support.
Free during the beta, no card.
patchpilot
Fleet · all servers
8 servers
3 reboots waiting
1 out of support
23 security updates pending
- Host Release Pending Status Last upgrade
- web-01 Ubuntu 24.04 LTS 3 updates · 1 security — 2 days ago
- web-02 Ubuntu 24.04 LTS 3 updates · 1 security — 2 days ago
- db-01 Debian 12 7 updates · 2 security Reboot waiting 6 hours ago
- cache-01 Debian 12 up to date Up to date 6 hours ago
- build-01 Ubuntu 22.04 LTS 14 updates · 4 security Reboot waiting 3 weeks ago
- mail-01 Ubuntu 22.04 LTS 9 updates · 3 security — 5 weeks ago
- pi-flur Raspberry Pi OS · arm64 2 updates — yesterday
- vpn-01 Ubuntu 18.04 LTS 41 updates · 12 security Out of support Reboot waiting 14 months ago
Next window · tonight 03:00–04:00 · 6 servers
vpn-01 excluded — no window setEvery server, and what it is actually running
One agent per machine, one row per machine. Nothing to correlate by hand, and nothing that depends on somebody remembering to look.
What is pending
The updates each server has waiting, with the security ones marked and the CVE each of those closes named next to it — and every installed package open to a vulnerability attackers are known to use, from CISA's catalogue, with its EPSS score. Below that, every other CVE of the server, and for the kernel whether the one that runs contains the vulnerable code at all.
What is waiting for a reboot
A kernel or a library that has been replaced but is still the old one in memory. Flagged per machine, so the restart happens when you decide rather than when something breaks.
When it was last upgraded
Per server, as a date rather than a feeling. This is the column that usually finds the machine everybody had forgotten about.
What failed
A held-back package, a full disk, a dependency apt refused to resolve. The run reports what happened instead of ending in a log nobody reads.
One table
The whole fleet on one screen. The dashboard is the product here — everything else on this page exists to keep it correct.
The update that nobody’s automation installs
Every automatic updater in the world will faithfully patch a release that has stopped receiving patches. It does its job, it reports success, and the machine gets quietly more exposed every month — because the thing that needed upgrading was the release, not the packages.
PatchPilot knows which release each server runs and when that release stops getting updates. The dashboard flags it in the months before it happens, while the upgrade is still something you can schedule, and it stays flagged in red afterwards for as long as it is true.
It is the one thing on this page that unattended-upgrades structurally cannot do for you, and it is the reason the fleet belongs in one table rather than on eight separate machines.
- Support ending months of warning, not weeks
- Already unsupported flagged for as long as it is true
- Security-only window updates narrowing to security fixes
- Release upgrade available the newer LTS, and since when
It installs in your window. It never reboots your machine.
Watching is the default. Installing is something you switch on per server, and it stops exactly where an automated tool should stop.
-
01
Set a window
Per server, because the database and the build box do not get to be unavailable at the same time. Tuesdays at 03:00, the first Sunday of the month, or never — a server with no window is watched and left alone.
-
02
It installs inside it
Security updates first, then the rest. When the window closes it stops, and what it did — and anything apt refused — is on the server’s row before you wake up.
-
03
It stops at the reboot
If the update needs a restart to take effect, the machine is flagged on the dashboard. PatchPilot does not restart it. Nothing here ever takes a service down on a schedule you did not press.
Under five minutes from the first command to the first answer: install the agent on a Debian-based server you have root on, and its row is there. Everything above is something you switch on afterwards, if you want it.
You hear about it before you go looking
A dashboard you have to remember to open is a dashboard that tells you things four weeks late.
A security update is new
On which server, for which package, and which CVE it closes — once, and only where no maintenance window installs it. One that is being exploited there, you hear about at once.
The window cannot install it
Held back by apt, or the server was offline when its window opened: the updates it will not get on its own.
A run failed
Out of disk, or refused by apt — with what it said, not just that it did not work.
By email, and to Slack, Discord, Microsoft Teams or a webhook of your own. Nothing else to configure, and no app to install.
Root on your fleet, and how little of it we take
Installing packages needs root. The agent does not get it — only the update step does, and that step is fixed when you install. Here is the whole of what that means rather than a sentence designed to stop you asking.
It does not run as root
It runs as its own user, sandboxed by systemd. Updates are installed by a separate step the install command sets up: apt-get, as root, with fixed options. The agent can start that step; it cannot change what it runs.
It only talks outbound
The agent opens the connection to us. No port is opened on your server, we hold no SSH keys, and nothing here ever connects into your network.
It sends package names and versions
Plus what the dashboard shows about the machine: its hostname, distribution and release, architecture and kernel, which options the kernel was built with and which of its modules are loaded, whether a reboot is waiting, when it last started, when packages were last upgraded, whether Ubuntu Pro is on, a one-way hash of its machine ID, the agent's version, and the result of the runs it performs. Not your files, not your databases, not your environment variables.
Remove it and nothing changes
Your package sources and your configuration are untouched by all of this. Uninstall the agent and the machine carries on exactly as it was.
One command to install, one to remove, on x86-64, arm64 and 32-bit ARM. That list is the complete description of the relationship between your servers and us — if a claim is not on it, we have not made it.
Free while it is in beta
PatchPilot costs nothing during the beta: every feature on this page, for every server you connect, with no card to enter.
Paid plans come after the beta, priced per server — not per update, not per CPU, not per user. Their prices will be on this page before they apply to anyone, and every plan will have every feature, because a security warning you have to upgrade to receive is not a business model. Questions — write to us.
Eight honest answers about PatchPilot
Do you need root on my servers?
To install it, yes: the install command creates the agent's own user and the update step. After that the agent runs without root, and updates are installed by that step — apt-get, as root, with options fixed at install that the agent cannot change. It only ever talks outbound to us, so nothing on your server is exposed, and what it sends is the list of installed packages and their versions, with the few facts about the machine the dashboard shows, all of them listed above. It does not read your files, your databases or your environment.
Does PatchPilot install updates, or only watch?
Both, and you decide per server. It always shows you what is pending. Give a server a maintenance window and it installs the updates inside that window, then shows you what it did and tells you what failed.
Who decides when a server reboots?
You do. PatchPilot never restarts a machine. When an update needs a reboot to take effect, the dashboard flags the server as waiting for one. The restart stays yours.
Why not just use unattended-upgrades?
Keep it. It installs security updates on the machine it runs on and it is good at that. What it cannot tell you is which of your twelve servers it actually ran on last night, which update it held back, which machine is waiting for a reboot, or that one of them is on a release that stopped getting updates eight months ago. That part is ours.
Which distributions do you support?
Debian, Ubuntu and the apt-based derivatives, Raspberry Pi OS among them, on x86-64, arm64 and 32-bit ARM. Distributions with another package manager — RHEL, Rocky, Alma, Fedora, Arch, Alpine — are not supported today.
Can I use it for the server in my flat?
Yes. PatchPilot is free during the beta, the agent runs on arm64 and 32-bit ARM, and a Raspberry Pi is a perfectly ordinary thing to point it at.
What does it cost?
Nothing while PatchPilot is in beta, however many servers you connect. Paid plans come after the beta, and their prices will be on this page before they apply to anyone.
What happens to my servers if I stop paying?
Nothing happens to them. Their package sources and their configuration are exactly as you left them — you remove the agent and the machines carry on. PatchPilot is where you look at your fleet, not something your fleet depends on.
Which of your servers has not been upgraded since last year?
One command on the first one, and you will know. It is free during the beta.
Free during the beta, no card.