Join my community / free newsletter — sign up here

The boring superpower: a weekly gate that keeps twelve sites' dependencies current

Client
GrN.dk — server fleet (12 production vhosts)
Sector
Maintenance automation / DevOps
Period
July 2026 — ongoing
The gate's weekly fleet report: twelve vhosts with their Drupal core version, web PHP, queued safe bumps and held breaking majors, plus the rule that composer resolves against each site's own web PHP.

At a glance

Twelve production websites on one server, each with its own Composer dependency tree, and the oldest question in hosting: are they up to date, and is it safe to make them so? The dependency-currency gate answers it weekly and automatically — it inventories every vhost, checks each dependency tree against the PHP version that site's web server actually runs, queues the semver-safe updates for approval, and reports the breaking ones instead of applying them.

12 production vhosts scanned weekly; safe bumps queued, majors held for review
Composer resolves against each site's web PHP — the CLI-PHP trap that 500'd two sites is closed by construction
Every apply run snapshots composer.lock + vendor: one command rolls a site back

The challenge

Unpatched dependencies are how sites get owned, but blind composer update is how sites go down — and there is a subtle trap between the two. A server's command-line PHP is often newer than the PHP the web server runs, so an update resolved with the CLI can install packages the live site literally cannot execute. That exact failure — CLI-resolved dependencies that were 8.4-only, on sites serving PHP 8.3 — had already produced HTTP 500s on two live sites here. The fix had to make that class of mistake impossible, not merely less likely.

The solution

A four-phase tool, built as separate approved stages: an inventory of every vhost and its real runtime; a currency check that runs Composer's resolver as each site's own web PHP (lsphp 8.3, not the newer CLI PHP), splitting available updates into semver-safe bumps and breaking majors; an apply stage that snapshots composer.lock and the vendor tree before touching anything, so one command rolls a site back; and a weekly cron that re-runs the check across the fleet and mails the report.

The judgment calls stay human: safe bumps are queued and applied on approval, majors are listed with what they would break, and nothing is ever auto-applied.

The results

The gate has run weekly since mid-July 2026. A typical report: 12 vhosts scanned, a handful of safe bumps queued, zero applied without approval. The two sites broken by the CLI-PHP trap were repaired by re-resolving at their web PHP, and the root cause is now structurally closed — the resolver simply never sees a PHP the live site does not have.

It is the least glamorous case on this page and possibly the most valuable one: the difference between "we should really update those sites sometime" and a Monday-morning email that says exactly what is safe to do.