---
id: infra/revisit-the-bun-1-3-pin-once-1-4-has-been
title: 'Revisit the bun 1.3 pin once 1.4 has been watched for a while'
theme: infra
status: open
created: 2026-08-22
date_source: stated
order: 6
---

**Revisit the bun 1.3 pin once 1.4 has been watched for a while.** Raised by the owner 2026-08-22,
who asked for it explicitly as a temporary hold — "a few months, until I'm sure the new 1.4 is going
to be safe" — so this exists to stop a deliberate pause becoming permanent by nobody remembering it.

bun 1.4.0 was published 2026-08-20 and `https://bun.sh/install` serves whatever is newest, so a
machine provisioned on 2026-08-22 would have put a two-day-old release under the platform and every
pm2 app except `officer-pty`. The hold is at the SERIES, not a patch: `BUN_SERIES=1.3` in
`scripts/setup/machine-setup/lib/dev.sh`, resolved to the newest `1.3.x` from the npm registry at
install time, so bug fixes inside the series still land.

Two places carry the number and they must move together — `BUN_SERIES` in `dev.sh`, and
`engines.bun` in `package.json`, which is what `bun run doctor` reads to decide whether the running
bun has drifted. bun itself ignores `engines` (verified: an install declaring `1.9.x` ran clean under
1.3.14), so that field is a declaration and doctor is the enforcement.

What is NOT covered, and is the reason a drift check exists at all: `bun upgrade` takes no version
argument — latest-stable or `--canary`, nothing else — so it always jumps to the newest release and
walks a pinned machine off the pin silently. Nothing in a setup script can prevent that; `bun run
doctor` reports it after the fact, and `machine-setup.sh --only 'JavaScript runtimes'` offers to pin
it back down.

To lift the hold: raise both numbers, run `bun run doctor` on each machine, and delete this item.