Dependency updates: how often, and how to do them safely
Updates close known holes and occasionally break things. The cadence that balances both, and why a year without updates is the real risk.
The short answer
Updates to the packages your site is built from do two things: they close vulnerabilities that have been published, which attackers scan for within hours, and they occasionally change behaviour in ways that need adjusting. The cadence that balances both is simple: security fixes within days, routine updates monthly, major version upgrades planned and tested separately. Done through a pipeline with previews, automated checks and one-step rollback, updates become boring, which is the goal. The dangerous state is not the update that breaks something; it is the year without updates, after which everything is overdue at once and every step is large.
The cadence
| Kind of update | When | How |
|---|---|---|
| Security fix for a used package | Within days of publication | Proposed automatically, checks run, approved as soon as green |
| Routine minor and patch updates | Monthly, batched | One proposal per group, previewed, checked, approved together |
| Major version of a framework or key library | Planned, a few times a year at most | Read the migration notes, update on a branch, test thoroughly, schedule |
| Platform announcements | As announced | Read, assess, adapt before the deadline |
| Browser and standards changes | Continuous | Regular re-testing of the site regardless of changes |
The process that makes it safe
- Automation watches the lock file and opens a proposal for each available update, grouped sensibly.
- The pipeline builds and checks each proposal: types, tests, page loads, accessibility, visual comparison where configured.
- A person reviews: green checks, change notes skimmed, anything notable flagged.
- A preview is opened for anything user-visible.
- Approve and deploy, one group at a time, so a regression points at a small set of changes.
- Monitor after deploy: errors, speed, forms. Roll back in one step if something regressed; then fix forward.
- Record it in the monthly report: what was updated, anything notable.
What long gaps actually cost
A site a year behind on updates carries every vulnerability published in that year, each of them scanned for by scripts that found the site long ago. It also carries a debt: the eventual update is large, the change notes span many versions, and things that would have been small adjustments in March compound into a project in December. The monthly hour is far cheaper than the annual week, and much cheaper than the incident in between.
What this means for you
Updates are maintenance, not risk. Insist on a cadence: days for security, monthly for routine, planned for major. Insist on the process: automation proposes, pipeline checks, person approves, preview, deploy, monitor, rollback if needed. Then updates become an item in the monthly report that you never think about, which is exactly what they should be.
Frequently asked questions
Updates sometimes break our site. Should we do fewer?
More, in smaller steps. Breakage comes from large jumps after long gaps and from applying updates without previews and checks. Small, frequent updates through a pipeline with automated checks and a one-step rollback rarely break anything visible, and when they do, the cause is obvious and the fix is quick.
Who decides which updates to apply?
Automation proposes them and runs the build and checks against each proposal. A person reviews the result, reads the change notes for anything significant, and approves. Security fixes are approved as soon as checks pass; others are batched monthly; major versions are scheduled.
What about updates to the platform itself, or the browser?
Platforms update themselves and announce breaking changes in advance; the partner reads the announcements and adapts. Browsers change continuously, which is one reason a site should be re-tested regularly even when nothing in it changed. Both belong in the monthly maintenance routine.