Skip to content

PATTERN Cited by 1 source

Dependency update discipline

Intent

A narrowly-scoped but frequently-ignored operational pattern: keep track of what needs updating, update for security fixes and important bug fixes, and deliberately don't update for no reason — because updates destabilise, but more importantly because the value of dependency updates is not in the updates themselves but in the process and testing infrastructure to metabolise them confidently.

Fly.io 2025-02-26 puts it self-deprecatingly:

"Keep your dependencies updated. Unless you shouldn't keep your dependencies updated. I mean, if there's a vulnerability (and, technically, this was a DoS vulnerability), always update. And if there's an important bugfix, update. But if there isn't an important bugfix, updating for the hell of it might also destabilize your project? So update maybe? Most of the time?"

And the actual insight:

"Really, the truth of this is that keeping track of what needs to be updated is valuable work. The updates themselves are pretty fast and simple, but the process and testing infrastructure to confidently metabolize dependency updates is not."

The three inputs

  1. Awareness — monitor upstream issue trackers, CVE feeds, and cargo audit / npm audit / pip-audit equivalents; read release notes for critical dependencies. The goal is zero-surprise on which updates exist.
  2. Classification — security fix, important bugfix, or "just an update." Fly.io's rustls bug was technically a DoS vulnerability, "so always update," but the typical feature-version bump is not.
  3. Pipeline — CI matrix covering the dependency versions in question, canary rollout, and rollback discipline. The pipeline is the expensive part; the update itself is cargo update or npm install.

Anti-patterns

  • Auto-bump-everything. Dependabot opening PRs on every minor release, auto-merged on green CI without human classification. Works until a "destabilising update" slips through because your CI didn't exercise the relevant path.
  • Freeze-in-place. Never updating except under duress. Lets a DoS vuln sit in your production binary for months because you don't have a tested pipeline for any upgrade.
  • Pin-then-forget. Lock-file in place, no scanning, no awareness of upstream activity. No mechanism for "is the thing we're pinned to still safe?"

Sibling patterns

  • patterns/upstream-the-fix — if you're the one finding the bug, the update-discipline counter-party is to push a fix upstream before waiting for an update to bring it to you.
  • patterns/flamegraph-to-upstream-fix — concrete diagnostic workflow that often ends up discovering which version of which dependency needs updating.

Seen in

  • sources/2025-02-26-flyio-taming-a-voracious-rust-proxy — Fly.io frames the pattern as the self-drawn lesson from the tokio_rustls/rustls DoS bug. The bug was a known upstream issue (tokio-rustls#72) and was technically a DoS vulnerability, so "always update" applies — but the post's honest framing is that knowing which updates are which and having the test infra to land them is the work. Canonical wiki statement of the pattern.
Last updated · 200 distilled / 1,178 read