Plain-English companion to Client VPS Patching — Managed Service.
How It Works covers what runs and when;
What a Client Sees covers the record. This page covers
the promises we make and the uncomfortable half: what we do when an update goes wrong on a machine we are not
allowed to log into.
Critical security fixes land within 7 days; routine updates run monthly; the box's own packaged software is
refreshed quarterly; and no restart of a client's box is ever silent. The 7 days is deliberately the same
number as the notice before a security restart — so the thing we promise and the thing we tell the practice can
never contradict each other.
Two honest notes about that sentence. The timing is an engineering commitment — it is what our jobs are
built to do — but what appears in a client's contract is commercial and stays with Matthew. And the promise
is about our boxes and our jobs: it says nothing about whether the practice's software felt fine afterwards
(see the limits section below).
With two boxes this does not matter. With three hundred it is the single largest risk in the whole service — not
that one patch fails, but that the same bad patch reaches every practice in one night. So runs are rolled
out in waves:
| Wave | Size | What happens |
|---|---|---|
| Canary | one box | The first box is always a test-estate box — ours, permanently. If it is unhappy, nothing else moves, so a real client's box never takes a bad patch first. |
| Early | 10% | A spread across clients, not the newest or the oldest only. |
| Standard | the remainder | Everything left, in per-box slots. |
The halt rule is the point of the whole design: if any box in a wave fails its check after the run, or simply
stops reporting inside its window, the wave stops by itself — no further box proceeds. And a halted wave is
never re-started automatically: a person looks at what happened, fixes it, and re-runs it, and both the halt
and the re-run are recorded as their own events, so a stalled rollout is visible rather than quietly retried
until it "works".
The signals the halt rule needs already exist — the tunnel health, whether the database answers, and whether the
application returns a healthy response. Wiring the gate is the work; inventing new monitoring is not.
Two different strategies, because two different things are being patched:
This is the part an inspector will ask about, and the honest starting point is that we cannot log in to a real
client's box — by design, and that is the posture every box is in once it is in service. (The boxes we run today
are our own test estate: on those, access switches between SSH for development and tunnel-only for maintenance,
so the posture we promise is also the posture we rehearse — and they are the canary wave above.) So the answer is layered, and the first layer needs nobody:
1. The box checks itself, and holds back what it cannot undo. After a run, and again after any restart,
the agent reports its own health, and a restart that has not succeeded is simply not taken again — that
covers the common case with no human involved at all, which matters because the common case is also the one
nobody notices in time. What is deliberately not claimed: automatic rollback of an installed package. If an
update has already been applied and the box is still unhappy, the fix is layers 2 and 3 below, not a magic
revert. The design page's ruling asked for an automatic revert "where the platform allows it"; the build that
landed on 2026-10-14 ships the health report and the held restart, and the difference is recorded here rather
than glossed.
2. The practice's own admin has a runbook. A short, plain-English "what to do if the box looks unhappy"
guide, in the same register as their dashboard guide: what a failed update looks like, what to do, and how to
call us. Written for a practice manager, not for an engineer.
3. If hands are genuinely needed, they get a temporary credential — for that incident only. The same
pattern as the build visit: the client issues a temporary login, we use it, and it is terminated again. It is
logged as its own event, with its own record, so the client can see when we had access and why. That record
is part of the same evidence trail as the patch runs themselves.
And one option we rejected: keeping a stored credential under dual control. It would be convenient, and it
is exactly the liability the whole access model exists to remove — one leaked key would be every client.
Because "we hold no login to your server" is a sentence both a practice's data-protection lead and an inspector
want to hear, and because one credential covering hundreds of machines is the largest liability an estate like
this could carry.
The honest caveat, which belongs on the same page rather than in a footnote: the agent runs with elevated
rights on their box, so we are not literally keyless — we are delegated. What makes that acceptable is that
its permitted actions are a fixed, published list — update the operating system, refresh a listed container
image, report the inventory, restart when required — verified against a signed job, and never a
general-purpose remote shell. A compromised system of ours still cannot turn a client's box into arbitrary
remote execution.
Everything above depends on software that has to be installed while somebody is at the machine, because that is
the only time we hold access. So the build visit is not an install-and-leave; it is a recorded step:
provisioning installs and verifies the update agent, the backup job, the reporting configuration and the
client's own dashboard, confirms each one, and writes that confirmation down before the temporary credential
is handed back. It is a deliverable in its own right, not a paragraph in somebody's notes.