platform/deploy/2026.08.29.01.report.md

2026.08.29.01 — deploy report

7 of 7 target hosts succeeded. 1 skipped (officer-dev, the host this rollout ran on).

Every target ended at 58f50a52, the tag commit. Tag and package.json agreed before anything was touched. No host failed, none was left half-applied, and nothing was reset or discarded.

The two facts this release is about

Every host prints a libvips version. sharp@0.35.4 installed and loaded on all seven, libvips 8.18.6 everywhere — x86_64 and arm64, Node v22 and v24. The plan flagged edge-pertento-bridge (Node v24) as the most likely failure; it was not one.

Every host now has ffmpeg. Six already had it. macbruno did not, and the plan's per-host brew install ffmpeg ran there before the restart and succeeded — so this release ships with no ffmpeg caveat outstanding on any host.

Host	HEAD before → after	install	libvips	ffmpeg	officer
officer-dev	—	—	—	—	SKIPPED — rollout host
alpha	9c8af9d4 → 58f50a52	14 pkgs	8.18.6	6.1.1 (had)	online, rt 2→3, 401
fofos	de425d9d → 58f50a52	no-op	8.18.6	6.1.1 (had)	online, rt 25→26, 401
macbookpro	16fa8692 → 58f50a52	10 pkgs	8.18.6	8.1.2 (had)	online, rt 2→3, 401 :9010
macbruno	9c8af9d4 → 58f50a52	10 pkgs	8.18.6	9.0.1 (installed)	online, rt 5→6, 401
production-pertento-bridge	9c8af9d4 → 58f50a52	14 pkgs	8.18.6	6.1.1 (had)	online, rt 3→4, 401 :9010
edge-pertento-bridge	9c8af9d4 → 58f50a52	14 pkgs	8.18.6	6.1.1 (had)	online, rt 4→5, 401
deadpool-rezio-bridge	9c8af9d4 → 58f50a52	14 pkgs	8.18.6	6.1.1 (had)	online, rt 21→22, 401

Health is /api/health on each host's own port, read from its .env rather than assumed. 401 is healthy per the plan. production-pertento-bridge was checked on 9010, not 9000.

Schema

Unchanged, and no bun db:push was run anywhere. The plan says so and I verified it rather than taking its word:

git diff --name-only deploy/2026.08.28.01..deploy/2026.08.29.01 | grep -iE 'schema|/db/|databases'

returns nothing. No table, column or constraint in this release, so the "check the database by query" rule had nothing to check and no SQL was improvised. Plugin schema lines in plugins:update output (schema: applied in …ms, N table(s) verified) are that script's own per-plugin verification, not this release.

The one deviation, and why

On macbookpro the standard step order failed, and I ran the same steps in the other order.

bun run plugins:update exited 1 with:

error: Cannot find package 'sharp' from '…/src/servers/api/file-browser/thumbnails.ts'

The updater imports the server graph, which now reaches the new thumbnails.ts, which imports sharp. The standard steps in prompts/deploy-commander.md put plugins:update before the plan's bun install — so on a host where sharp is genuinely new, the step cannot resolve a dependency the same release is about to add.

I ran bun install first, then plugins:update, which then exited 0. Both steps ran, none was skipped and nothing was composed — only the order changed. I did the same on the four hosts after it. alpha and fofos had already passed in the documented order because sharp was on disk for reasons of their own: alpha via a plugin's declared npm dependencies, fofos as the pre-tag test host.

This is a finding for whoever writes the next plan, not a fix I made. Any future release that adds a runtime dependency imported by the server graph hits the same wall in the same place. The ordering lives in the commander prompt's standard steps, and correcting it is a documentation change, which a rollout does not make.

What else moved

bun run plugins:update restarts sidecars itself. It reported sidecar: started on alpha (15/15 plugins, officer-music re-added), fofos (5/5), macbruno (1/1), production-pertento-bridge (1/1, officer-gitea), edge-pertento-bridge (2/2, officer-offscale) and deadpool-rezio-bridge (2/2). macbookpro has no plugins installed. So more than officer bounced on most hosts — that is the updater's own behaviour, not a restart this rollout asked for. The only restart it issued was pm2 restart officer, per host, by name.

production-pertento-bridge: all eight non-Officer Pertento processes were still online after the restart. Nothing there was named or touched.

Notes, not problems

• fofos carries one untracked file, scripts/chk.ts. Noted, not a reason to skip — a fast-forward cannot touch it. No host had tracked changes; no work was discarded anywhere.
• production-pertento-bridge prints an nvm warning (has a globalconfig and/or a prefix setting…) on every bun/node invocation. Pre-existing, unrelated to this release, harmless to it.
• macbruno: officer's PM2 environment already carries /opt/homebrew/bin, so the newly installed ffmpeg is on the restarted process's PATH. Verified, not assumed.

For the owner

• officer-dev is deliberately a step behind the fleet. Its checkout is already at 58f50a52, but nothing was pulled, installed or restarted on it, and bun install has NOT run there — so sharp is not necessarily present for the running process. Restart it deliberately when you are happy with the rest, and run bun install first or the thumbnails endpoint will not have its dependency.
• The plugins:update ordering above is worth fixing in the prompt before the next release that adds a dependency.