A plain-English companion to Client VPS Patching — Managed Service.
That page is the design, the work orders and the open questions, and it is written for engineers. This page
explains the same thing without jargon: what actually happens to a client's box, when it happens, what the
client is told, and what is still undecided. Written 2026-10-14, after the cadence and restart rulings. A
client-facing version will be adapted from this once the build lands.
A client's VPS holds their database — the live record of the practice's work. For a real client, the box is handed over tunnel-only: after handover, we have no
login on it, deliberately. The only path between us and the box is the secure tunnel the box itself opens,
and that tunnel carries the database, not a command line. So nobody can "log in and run the updates" the way
we do on our own servers. Everything therefore has to run on the box itself, be installed at the one
moment we do have access (the build visit), and report back out by itself when it has finished.
The boxes we have today are a test estate, and they stay that way. test-client (GP), test-client-dental
and test-client-pharmacy are ours rather than a customer's: they are the estate the apps are developed against,
which is why access to them switches between the two modes — SSH while we are developing, tunnel-only as the
in-service posture — and why they are also the canary for patching. Every patch and image refresh goes to
these boxes first, and only then to a real client's, so a faulty patch or a bad build is caught on our own
machines rather than on a practice's.
That single constraint is what decides the whole design: the update job is a small piece of software we leave
behind during the build visit, not something we drive from our side each month.
| What is updated | How often | Anything needed from us? |
|---|---|---|
| Security fixes to the operating system | Continuously, by itself | No — the box's own automatic update service does it |
| Everything else on the operating system (the full run) | Once a month, on a timer on the box | No — the timer fires, the box reports what it did |
| The box's own packaged software (its database engine; for dental, the radiograph store — SeaweedFS since 2026-10-15, when WO-M4 swapped it in place) | Once a quarter, deliberately | No — but this one is planned rather than automatic |
The scheduling rules. Each box gets its own slot, outside the client's clinic hours. Boxes are
staggered so that no two ever run in the same minute, and each slot is kept clear of the box's own nightly
backup — a database that is being backed up must not be restarted at the same moment. On our own three
platform hosts the same discipline already runs at 02:00, 03:00 and 04:30; the client estate needs the same
discipline, per box, as it grows.
Why security fixes run continuously rather than waiting for the monthly run. A published security hole is
usually being exploited within days. If a box waited up to a month for its next full run, it would sit exposed
for most of that month for no reason. Continuous security updates cost nothing extra and need nobody to do
anything.
Most updates install quietly while the software carries on running — nobody notices. A few updates, usually
to the core of the operating system, only take effect after the machine restarts. On a client's box a
restart is not a private event: it is the practice's database going away for a minute or two. Do that at 11am
on a Tuesday and the reception desk knows about it before we do.
So restarts are the one part of patching that needs a rule, and the rule is the thing that was ruled on.
1. A client's box is never restarted silently. There is always a notice before any restart that a client
would notice, and the notice comes before the decision takes effect, not after.
2. A security-critical update that cannot take effect without a restart goes ahead in a quiet window after
7 days' notice. Seven days is long enough for the practice to say "not that Tuesday, we have a clinic", and
short enough that the box is not left exposed for long.
3. Anything else that needs a restart waits — but not indefinitely. It goes ahead at the next quiet window
once 30 days have passed, after a second notice. The ceiling matters: it means a restart can be
deferred but not forgotten, and a practice that never replies still ends up patched.
4. Every restart is recorded, and the record is the client's. Their dashboard shows the current state
(waiting, scheduled, done) and the record can be downloaded as a file they can hand to an inspector. The
record carries the date the client was told, the date it happened, and whether it was brought forward or
deferred. Records are read-only to the client — they can show it, not edit it, and that is exactly what
makes it evidence rather than a claim.
5. Patch debt is visible, never hidden. If a restart is deferred deliberately, the record says so and the
next run reports it as still outstanding. There is no state in which a box is quietly months behind and the
dashboard looks fine.
Why this shape. The two obvious alternatives both fail. "We always decide" means the practice's database
restarts without them ever agreeing to it. "We always wait for them to press a button" means a busy manager
never gets round to it and the box stays unpatched for months. The rule above is the middle: they are always
told, they can always move it, and there is a hard limit on how long it can slide.
In the design page this is called the hybrid policy, because it combines a fixed notice period with a hard
deferral ceiling.