fix(docker): upgrade bun to 1.3.14

[waleedlatif1]

Summary

• Staging is currently down. Bun 1.3.13 cannot load Next 16.3.0's compiled server runtime, so every app-page render throws and /api/health returns 500. This bumps Bun to 1.3.14, which fixes it.
• The app container runs the Next server under Bun (oven/bun:1.3.13-slim, CMD ["bun", "apps/sim/bootstrap.js"]), so the failure is at runtime, not build time:

⨯ Error: Failed to load external module
  next/dist/compiled/next-server/app-page-turbo.runtime.prod.js:
  TypeError: Expected CommonJS module to have a function wrapper.
  If you weren't messing around with Bun's internals, this is a bug in Bun

• Isolated to Bun, not Next, by loading that exact module inside the real container images:

	Bun 1.3.13	Bun 1.3.14
Next 16.2.12	loads (why staging was fine before)	loads
Next 16.3.0	CJS wrapper error	loads

Only one cell fails. Bun 1.3.14 is the current stable and already contains the fix, so this bumps every pin rather than reverting #6235 — a revert would only defer the same latent Bun bug to the next framework upgrade.

• Bumps all 13 pins: docker/app.Dockerfile, docker/db.Dockerfile, docker/realtime.Dockerfile, package.json packageManager, and bun-version in ci.yml, test-build.yml, desktop-e2e.yml, desktop-release.yml, docs-embeddings.yml, helm.yml, migrations.yml, publish-cli.yml, publish-ts-sdk.yml.

Incident detail

• First error at 01:52:56 UTC, ~2.5 min into deploy d-8SLBY3ZXK (the image carrying chore(deps): upgrade next to 16.3.0 and clean up the TypeScript toolchain #6235). 745 occurrences, zero before that timestamp.
• Both ALB targets unhealthy / Target.ResponseCodeMismatch on the only target group serving traffic. CodeDeploy reported Succeeded and no rollback fired.
• Production was never affected (5/5 tasks healthy, zero occurrences) — it deploys from main.

Why no gate caught it

Local dev machines run Bun 1.3.14, while the container and CI pinned 1.3.13 — so every local check (build, dev, 18k tests, typecheck) ran on the version without the bug. CI pins 1.3.13 but only builds the image; nothing boots a container and probes /api/health, so CI went green on an image that could not serve a page. A container smoke test in CI would have caught this and is worth adding as a follow-up.

Type of Change

• Bug fix (production/staging outage)

Testing

• Reproduced and verified the fix at the root cause by loading app-page-turbo.runtime.prod.js in oven/bun:1.3.13-slim (fails) vs oven/bun:1.3.14-slim (loads) — see matrix above.
• Bun 1.3.14 is already the version this repo's full verification suite runs on locally (builds, 18366/18367 tests, 23-package typecheck all pass on it).
• A full image build on Bun 1.3.14 with an /api/health probe is running; I'll post the result here before merge.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Ready	Preview	Aug 4, 2026 2:26am

[cursor]

PR Summary

Medium Risk
Changes the production app runtime and every CI/dev image pin; risk is concentrated in Bun/Next CJS compatibility rather than app code, but a missed pin or sandbox image lag could still leave an environment on 1.3.13.

Overview
Bun is bumped from 1.3.13 to 1.3.14 everywhere the repo pins it, so production images and CI match the runtime that can load Next 16.3.0’s compiled server modules. The app container starts the Next standalone server with bun apps/sim/bootstrap.js; on 1.3.13 that path throws when loading app-page-turbo.runtime.prod.js (CommonJS wrapper error), which broke staging page renders and /api/health.

Pins updated include root packageManager, docker/app.Dockerfile, docker/db.Dockerfile, docker/realtime.Dockerfile, .devcontainer/Dockerfile, PI_BUN_VERSION in pi-sandbox-packages.ts, and bun-version across CI workflows (ci, test-build, migrations, desktop, docs-embeddings, helm, publish-cli, publish-ts-sdk). No application logic changes—only toolchain/runtime alignment.

^{Reviewed by Cursor Bugbot for commit 454b8a3. Configure here.}

[greptile-apps]

Greptile Summary

This PR upgrades the repository’s Bun runtime and toolchain pins from 1.3.13 to 1.3.14 to restore compatibility with the Next 16.3.0 server runtime.

• Updates Bun base images used by the app, database, realtime service, and development container.
• Aligns the root package manager declaration, CI workflows, and desktop/release workflows.
• Aligns the Pi sandbox Bun package and version assertion with the root toolchain version.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains; the previously reported devcontainer and Pi sandbox version mismatches are fixed, and all active Bun pins now consistently use 1.3.14.

Important Files Changed

Filename	Overview
docker/app.Dockerfile	Updates the application runtime image to Bun 1.3.14, addressing the reported Next 16.3.0 runtime incompatibility.
package.json	Aligns the repository’s declared package-manager version with Bun 1.3.14.
.devcontainer/Dockerfile	Resolves the previously reported devcontainer mismatch by upgrading its Bun image to 1.3.14.
apps/sim/scripts/pi-sandbox-packages.ts	Resolves the previously reported Pi sandbox mismatch by aligning its installed and asserted Bun version with package.json.
.github/workflows/ci.yml	Updates both CI Bun setup steps to exercise the repository under Bun 1.3.14.
docker/db.Dockerfile	Aligns the database container’s Bun base image with the upgraded toolchain.
docker/realtime.Dockerfile	Aligns the realtime container’s Bun base image with the upgraded toolchain.

_{Reviews (2): Last reviewed commit: "fix(docker): align the remaining bun pin..." | Re-trigger Greptile}

[waleedlatif1]

Verification promised in the description is done — the fix is confirmed end-to-end, not just at the module-load level.

The in-container next build OOM'd on my machine (arm64, 13 static-gen workers, SIGKILL 137), so instead I built the standalone output locally and ran the real Next 16.3.0 server under each Bun version in oven/bun:*-slim, probing the actual health endpoint the ALB uses:

Bun	/api/health	function wrapper errors in logs
1.3.13	500	24
1.3.14	200 {"status":"ok",...}	0

Bun 1.3.13 reproduces the staging outage exactly — same error, same 500 on the same endpoint. Bun 1.3.14 serves 200 with zero occurrences. Identical build artifact in both runs; the only variable is the Bun version.

Worth noting for the follow-up: this A/B took about two minutes once set up, and it is exactly the check CI is missing. CI builds the image but never boots one, which is why a container that could not serve a single page went green.

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 454b8a3. Configure here.}