Vercel now detects Bun lockfiles inside monorepos so it can skip building projects a commit did not touch, and Bun itself defaulted to a text-based bun.lock back in the v1.2 release. The two changes together mean a team running Bun on Vercel can commit a human-readable lockfile, retire the binary bun.lockb and its git textconv workaround, and let CI rebuild only the workspace packages a commit actually affected.
What did Vercel actually change for Bun monorepos?
In March 2026, Vercel shipped Bun lockfile detection so that, inside a Bun workspaces monorepo, it can skip building projects whose dependencies a commit did not touch, a capability the platform describes as affected builds (vectordynamic).
The mechanism is the dependency graph encoded in the lockfile. When a commit lands, Vercel compares the changes against the lockfile-defined dependencies and rebuilds only the projects those changes affect (vectordynamic). Without affected builds, every commit in a monorepo triggers a full rebuild of every project, regardless of whether the change touched it. With lockfile-aware detection, a documentation edit or a single-package patch rebuilds only the subset of the workspace that transitively depends on what moved.
That is where the cost saving comes from. Rebuilding fewer projects means less build time and less compute on every push, and fewer minutes where a teammate is blocked on a check that was never going to fail. The benefit grows with the size and independence of the workspace: the more packages a commit leaves untouched, the more the detection pays for itself.
One nuance is worth pinning down, because the framing can outrun the facts. The documented behavior is lockfile detection for the purpose of build skipping in monorepos. None of the available sources describe a discrete Vercel launch event phrased as “reading bun.lock by default for zero-config installs.” The practical effect for most teams is that a committed Bun lockfile now participates in Vercel’s affected-builds logic instead of requiring a hand-wired install step. The lower-friction outcome is real; the precise “by default” launch framing should not be oversold.
What is the difference between bun.lockb and bun.lock?
Bun ships two lockfile formats: a legacy binary bun.lockb and a newer text-based bun.lock, with the text format becoming the default in Bun v1.2.
The binary bun.lockb is the original format. Its defining drawback is that it does not diff in git: a pull request that bumps a single transitive dependency produces an opaque binary blob no reviewer can read. The text bun.lock encodes the same dependency resolution as line-oriented text, so the same change produces a diff a human can follow. Bun v1.2 made the text format the default, which means new projects and fresh installs now write bun.lock rather than bun.lockb (Bun’s lockfile docs).
The two formats coexist during the transition, and a repository can carry either. For a new project the decision is already made: Bun v1.2 writes bun.lock on the first install, so greenfield repos get a reviewable lockfile by default and never need the textconv configuration at all. The practical question is which one an existing repository commits, because that choice determines whether dependency changes are reviewable in a pull request and whether a git workaround is needed to make them so.
| Format | Default since | Diffs in git | Needs textconv config |
|---|---|---|---|
bun.lockb (binary) | before v1.2 | No, opaque blob | Yes |
bun.lock (text) | v1.2 | Yes, natively | No |
Why does a text lockfile matter for diffs and PR review?
The text bun.lock diffs natively, so a dependency change shows up as a reviewable diff in the pull request instead of an unreviewable binary blob.
For teams still on the legacy bun.lockb, the established remedy has been a git textconv configuration. You set git config diff.lockb.textconv bun and add *.lockb binary diff=lockb to .gitattributes, which tells git to pipe the binary lockfile through bun to produce a human-readable diff (Bun’s git-diff guide). That works, but it is a per-repository, per-contributor step, and anyone who skips it sees the same opaque blob in their local git diff. New contributors clone the repo, open a pull request, and cannot tell what their dependency change actually did.
The text format removes that workaround. Because bun.lock is plain text, it diffs and merges like any other source file. A reviewer can see which packages moved versions. A lockfile merge conflict can be reasoned about and resolved rather than regenerated blind, which would discard the resolution the team actually wanted. Rebasing a branch across a dependency bump is tractable for the same reason: the conflicts are textual, so a contributor resolves them in an editor instead of deleting the lockfile. For a security-sensitive change like pinning a patched transitive dependency, that visibility is the difference between a review that can approve the change and one that is rubber-stamping a blob.
How do you migrate from bun.lockb to bun.lock?
To migrate an existing repository, run bun install --save-text-lockfile --frozen-lockfile --lockfile-only and then delete the old bun.lockb, per Bun’s lockfile docs.
That command writes a text bun.lock from the current resolution without changing what is installed: --lockfile-only confines the operation to the lockfile, --frozen-lockfile keeps the existing resolution pinned rather than updating it, and --save-text-lockfile selects the text format. After committing the new bun.lock and removing bun.lockb, subsequent installs write text by default.
In a CI pipeline, the value compounds. CI typically installs with a frozen lockfile to guarantee reproducible builds, and a frozen text lockfile makes the resolution CI is pinning auditable in the pull request that changed it. A reviewer who can read the lockfile can confirm CI is installing exactly what was approved, including the patched transitive dependency that prompted the bump.
For repositories arriving from another package manager, Bun can convert in one step. On bun install in a project that has no bun.lock, Bun migrates yarn.lock (v1), package-lock.json, and pnpm-lock.yaml automatically, and it preserves the original lockfile so you can remove it by hand (Bun’s lockfile docs).
What are the caveats for Bun on Vercel?
Vercel’s Bun runtime is still in Beta. You set the version with "bunVersion": "1.x" in vercel.json, Bun.serve is not supported on Vercel Functions, and you must deploy through a framework such as Next.js, Express, Hono, or Nitro (Bun’s Vercel deployment guide; Vercel’s Bun runtime docs).
The Bun.serve restriction is the one most likely to bite. Code written for a standalone Bun server, where Bun.serve is the entry point, will not run unchanged on Vercel Functions; it has to be adapted to a supported framework’s request handler. That is not a lockfile concern, but it is the constraint that decides whether a Bun project can land on Vercel at all.
It is also worth separating the two concerns, because they are often conflated. The lockfile format and the affected-builds detection govern the install and build stage: what gets resolved, what diffs, and what gets rebuilt. The runtime Beta governs execution: whether Bun runs your functions in production. The lockfile and build-skipping improvements are about the pipeline that produces a deploy; the Beta status is about what runs after the deploy lands. Treating the text-lockfile change as a signal that the Bun runtime has graduated to production-ready would conflate the two.
Where does this leave Bun?
Bun v1.3.14 is the current release, and Bun is joining Anthropic, a move the runtime’s homepage frames as Anthropic betting on Bun (bun.sh). For the lockfile question specifically, the relevant signal is that the text format has been the Bun default since v1.2 and that a major hosting platform now reads Bun lockfiles to drive affected builds. Committing bun.lock rather than bun.lockb is the lower-friction path for new Bun-on-Vercel work, and the binary format now exists mainly as a migration source for older repositories.
Frequently Asked Questions
How does Vercel’s Bun build skipping differ from Turborepo or Nx affected builds?
Turborepo and Nx compute affected packages from their own task graph and cache config, which means adding a separate runner config to the repo. Vercel’s detection reads the Bun lockfile’s dependency graph directly, so a Bun workspaces repo gets skipping without a parallel task-runner file. The cost is platform coupling: the detection runs on Vercel’s build infrastructure and does not travel with the repo to other CI providers.
When does Vercel’s affected-builds logic still rebuild most of a monorepo?
A change to a widely depended-on package, such as a root utility, shared UI library, or types package, fans out transitively through the lockfile graph. The detection rebuilds every project that depends on it directly or indirectly, so a low-level dependency bump can trigger a near-full rebuild even with skipping enabled. The savings appear on isolated, leaf-package changes, not on core dependency updates.
What happens if the Bun lockfile is not committed to the repo?
Vercel’s affected-builds detection reads the lockfile committed in the repository, so a gitignored or absent lockfile leaves no dependency graph to skip against and every project rebuilds on every commit. The detection presupposes a committed lockfile, which is also why Bun’s guidance checks it in regardless of format.
Does Bun joining Anthropic change any of the lockfile or Vercel runtime caveats?
Not operationally. The acquisition is a corporate signal, not a format or runtime change: the text lockfile has been default since v1.2, and Vercel’s Bun runtime remains Beta with the Bun.serve restriction intact. Practitioners adopting Bun on Vercel today face the same migration steps and deployment constraints they did before the announcement.
Does the build-skipping feature apply to non-workspace Bun projects?
No. The feature is scoped to Bun workspaces, where the lockfile encodes a multi-package dependency graph. A standalone Bun app or a repo without workspaces has a single build target, so Vercel has nothing to skip and the commit rebuilds the whole project the way it would without detection.
