Will patching take my site down?

Depends on the shape. A static site has no running process to restart, so there is nothing to take down. A dedicated instance sees a few seconds of restart time, confirmed by a health check before the window closes. A managed database on a minor-version update sees a brief connection blip while it fails over, and existing connections reconnect on their own.

What if I don't want a version bumped?

For anything on the ours side of the layer inventory above — the operating system, the runtime, the database engine — that's part of what's included, and it runs on the standing window regardless. For your own application dependencies and framework versions, nothing ships without being briefed and reviewed first, so you always see it before it merges.

Who patches my application's dependencies?

Not silently, and not us alone. A flagged dependency gets triaged as application-level, briefed as a change under the Agentic iteration — CodeHerder add-on, opened as a real pull request by an agent, and merged only once a human has read the diff.

What happens with an urgent vulnerability?

It doesn't wait for the standing window. Anything being actively exploited moves out of band and gets triaged the same day, with the fix applied as soon as one exists — see the severity table above for how the other tiers are handled.

Do I get told before or after?

After, for the routine standing window — you get a note covering what was patched, whether anything restarted, whether it needs anything from you, and when the next window is. For anything that could change your app's behaviour, it's a briefed change you see and approve before it ships, so that one is before.

What about an end-of-life runtime?

Once a runtime stops getting security updates upstream, there's nothing left to patch — only a replacement. We flag it ahead of time and quote the upgrade rather than leaving it running unpatched.

How is this different from monitoring?

Monitoring finds out something is already wrong. This page is the half that tries to stop it going wrong in the first place — the two run side by side, not in sequence.

Who'd be doing all this if I hosted it myself?

You would. The hours ledger prices "patching the os and runtime" at around 2 hours a month for one small stack, on a monthly patch window — here, that row moves to us as part of every plan.

Patching — the patch window, in writing

№ 02 The inventory

Ours, and yours

7 layers, top to bottom. The line down the middle is the whole point: everything above it is patched silently as part of the plan; everything below it becomes a change you see before it ships.

Layer	What that covers	Whose call	Cadence	Do you notice?
Edge network & certificates	The network in front of your app, and the TLS certificate that terminates on it	Ours	Ahead of expiry, on its own schedule	No — renewed before it would ever lapse.
Operating system & kernel	The base system underneath everything you run	Ours	Standing window, monthly	No, unless a restart is needed — logged either way.
Language runtime	Whatever your app runs on — interpreter or managed runtime	Ours	Standing window, monthly	No, same window as the operating system.
Managed database engine	Minor, same-major-version releases of the database engine	Ours	Standing window, monthly	A brief connection blip, noted after the fact.
Web & proxy layer	Whatever sits in front of your app and terminates the request	Ours	Standing window, monthly	No.
Application dependencies	The libraries and packages your own code imports	Yours	As a flagged dependency is triaged	Yes — it arrives as a briefed pull request, not a surprise.
Framework major versions	An upgrade that can change how your app behaves, not just how it runs	Yours	Never automatic — briefed only	Yes, always — this one starts as a conversation.

№ 03 Cadence

Three tracks, one severity table

Every patch on the ours side of the inventory above travels on one of these three tracks — which one depends on how urgent it is, not how we happen to feel about it that week.

Monthly
Standing window
The default path for routine updates across every infrastructure layer above.
As soon as a fix exists
Out of band
A vulnerability being actively exploited does not wait for the next window.
Only when briefed
Never without asking
Anything that could change how the app behaves becomes a reviewed change first, not an automatic update.

Severity	What counts	Triaged by	Patched by
Critical	Actively exploited, or a fix landing for something that is	Same day	Out of band, as soon as a fix exists
High	Serious, but not yet seen exploited in the wild	Within a business day	Brought into the next window, or sooner if that window is more than a couple of weeks off
Medium	Worth fixing, unlikely to be an active target	Within a business day	Next standing window
Low	Hardening rather than an active risk	Logged for the next window	Next standing window

№ 04 Inside a window

What a standing window actually does

Same six steps every time, and the honest downtime line for each shape we host — the closest this page gets to a guarantee.

1
Snapshot first
A point-in-time snapshot is taken before anything changes.
2
Apply, staged
The update lands on a staging copy first, wherever the shape involved allows it.
3
Health check
The service has to answer correctly before anything is promoted.
4
Restart, if needed
Only the process or instance that actually needed it — nothing else in your stack restarts.
5
Verify
A second check after restart, before the window is marked closed.
6
Note
What ran, what changed, and whether it needs anything from you — see the note anatomy below.

Static site: None — there is no running process to restart.
Dedicated instance: A few seconds while the process restarts, confirmed by the health check above before the window closes.
Managed database, minor version: A brief connection blip during failover — existing connections reconnect on their own.

№ 05 What you're told

The note you actually get

Sent after every window that touches your stack, in the same four parts each time.

1
What was patched
The layer and what changed, in plain language rather than a version-string diff.
2
Whether anything restarted
Yes or no, and for roughly how long, matched against the downtime line for your shape above.
3
Whether it needs anything from you
Almost always no — called out plainly on the rare occasion it isn’t.
4
When the next window is
So you are never wondering when the next one lands.

Worked example

What was patched: The language runtime picked up its monthly security update.
Restarted?: Yes — the process restarted, back and answering inside a few seconds.
Needed from you: Nothing. No action required on your side.
Next window: The next standing window is in four weeks, same as always.

№ 06 When it's a code change

When a patch means changing your app

The application-dependency row from the inventory above, followed end to end — this is the half of patching that never runs silently, on purpose.

1
CustomHosted
A routine scan flags a dependency
The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list.
2
CustomHosted
It's triaged as application-level, not infrastructure
A library your own code imports isn't ours to patch silently — it can change how the app behaves.
3
CustomLabs
Briefed as a change
Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers.
4
CodeHerder
An agent opens the pull request
The upgrade lands as a real pull request against the repository, with the test suite run against it.
5
CustomLabs
A human reviews and merges
Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
6
CustomHosted
It ships through the same pipeline
The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.
7
CustomHosted
You're told it's done
A note confirming what changed and that it merged, in the same shape as every other note on this site.

Read how a change gets briefed in the first place on Brief a change, how it ships on The Loop, and a real one followed end to end on Case files.

№ 07 Our own supply chain

How we patch ourselves

The same discipline applied to this site's own build — a real practice, not a policy statement.

A cooldown on brand-new releases
A newly published package version has to sit for a week before anything here is allowed to install it — long enough for a poisoned release to get caught and pulled.
Exact, locked versions
Every dependency is pinned to the exact version we tested against and installed from a locked file, not a version range that can drift underneath us.
Install scripts off by default
A dependency doesn't get to run its own setup code on our build just by being installed.
A build that fails on a critical advisory
A blocking check runs against every dependency before a deploy ships, not just an occasional manual audit.

See it in the ledger at Built in the open.

№ 08 Said plainly

The honest limits

Not buried in a footnote — the same discipline as every other honesty band on this site.

An end-of-life runtime can't be patched, only replaced
Once a runtime stops receiving security updates upstream, there is no patch left to apply. We tell you ahead of time and quote the upgrade — we don't leave it running unpatched and quiet.
A zero-day with no fix yet gets mitigated, not patched
When a vulnerability is known before a fix exists, we reduce the exposure we can — the actual patch still waits on whoever maintains the affected software.
Anything you've pinned stays pinned
If you've deliberately pinned a version for compatibility, it stays there until you say otherwise — this page's automation never overrides a decision you made on purpose.
A patch that needs an app change becomes a briefed change, not a surprise
The same rule as the framework-major row above: if applying it could break your app, it goes through review before it ships, not around it.
We don't issue compliance attestations
This page describes real practice, in writing. It isn't a substitute for a formal compliance certificate if your situation specifically requires one.

№ 09 Answers

Patching questions

The follow-ups that come up once "security patching" stops being a line on a rate card and starts being something you're relying on.

01Will patching take my site down?
Depends on the shape. A static site has no running process to restart, so there is nothing to take down. A dedicated instance sees a few seconds of restart time, confirmed by a health check before the window closes. A managed database on a minor-version update sees a brief connection blip while it fails over, and existing connections reconnect on their own.
02What if I don't want a version bumped?
For anything on the ours side of the layer inventory above — the operating system, the runtime, the database engine — that's part of what's included, and it runs on the standing window regardless. For your own application dependencies and framework versions, nothing ships without being briefed and reviewed first, so you always see it before it merges.
03Who patches my application's dependencies?
Not silently, and not us alone. A flagged dependency gets triaged as application-level, briefed as a change under the Agentic iteration — CodeHerder add-on, opened as a real pull request by an agent, and merged only once a human has read the diff.
04What happens with an urgent vulnerability?
It doesn't wait for the standing window. Anything being actively exploited moves out of band and gets triaged the same day, with the fix applied as soon as one exists — see the severity table above for how the other tiers are handled.
05Do I get told before or after?
After, for the routine standing window — you get a note covering what was patched, whether anything restarted, whether it needs anything from you, and when the next window is. For anything that could change your app's behaviour, it's a briefed change you see and approve before it ships, so that one is before.
06What about an end-of-life runtime?
Once a runtime stops getting security updates upstream, there's nothing left to patch — only a replacement. We flag it ahead of time and quote the upgrade rather than leaving it running unpatched.
07How is this different from monitoring?
Monitoring finds out something is already wrong. This page is the half that tries to stop it going wrong in the first place — the two run side by side, not in sequence.
08Who'd be doing all this if I hosted it myself?
You would. The hours ledger prices "patching the os and runtime" at around 2 hours a month for one small stack, on a monthly patch window — here, that row moves to us as part of every plan.

№ 10 Keep reading

What patching connects to

Running something that needs an upgrade?

Write in through the quote channel — if it's application-level, it becomes a briefed change through the same pipeline as any other fix.

Get a quote →

Patched before it's news.