Bun 2.1 landed on Tuesday with a rewritten package installer that Oven, the company behind the runtime, claims is 3.4 times faster than the previous version on cold installs. The rewrite replaces a single-threaded resolution pass with a work-stealing scheduler across all available cores and moves tarball extraction into a thread pool that decompresses and writes concurrently. On a 1,400 dependency project with an empty cache, install times in our testing dropped from 6.2 seconds to 1.9. The release also introduces a text-based lockfile format, adds isolated dependency layouts as an option, and fixes a set of long-standing Node compatibility gaps in the crypto and worker_threads modules.
Where the speed comes from
The old installer resolved the dependency graph, then downloaded, then extracted, in three distinct phases. The new one pipelines all three: as soon as a package's metadata resolves, its tarball request goes out, and as soon as bytes arrive extraction begins on a worker thread. That overlap alone accounts for roughly half the improvement. The rest comes from a faster manifest parser written against the specific shape of npm registry responses rather than a general JSON path, and from replacing per-file writes with a batched syscall approach on Linux using io_uring where available.
export async function handler(request: Request): Promise<Response> { const started = Date.now(); const upstream = await fetch(request); const headers = new Headers(upstream.headers); headers.set("x-skarvonix-ms", String(Date.now() - started)); return new Response(upstream.body, { status: upstream.status, headers, });}The io_uring path is worth noting because it produces uneven results. On a modern Linux kernel with a fast NVMe drive, install times drop further than the headline number suggests, sometimes by another 30 percent. On macOS, where the equivalent primitive does not exist, gains are smaller. On Windows the installer still uses a conventional path and improvements are around 2.1 times rather than 3.4. Bun's benchmarks were run on Linux, which is fair for CI and less representative of a developer laptop.
The lockfile change
Bun's binary lockfile has been a persistent complaint since 2022 because it produces unreadable diffs and makes code review of dependency changes impossible. Version 2.1 defaults new projects to bun.lock, a text format that is deterministic, sorted, and reviewable. Existing projects with a binary bun.lockb keep working, and a migration command converts. The text format is roughly 40 percent larger on disk and adds about 12 milliseconds to parse on a large project, a cost the team judged obviously worth paying.
The format is Bun-specific rather than compatible with npm or pnpm lockfiles, which keeps the ecosystem fragmented. Bun can read package-lock.json and pnpm-lock.yaml for migration and does not maintain them. A shared lockfile standard has been discussed in the Node package manager working group for years without producing anything, and each new manager makes the problem slightly worse. For a team using different tools locally and in CI, this remains a genuine operational headache.
The story is rarely the launch. It is what breaks, what ships, and who owns the mess at 2 a.m.
Isolated installs arrive
By default Bun creates a flat node_modules like npm and yarn, which means a package can import a dependency it never declared, a phenomenon the ecosystem calls phantom dependencies. pnpm solved this years ago with a symlinked layout that exposes only declared dependencies. Bun 2.1 adds the same as an option through a linker setting, and the team says it will become the default in 3.0 after a compatibility period.
In testing, switching an existing project to isolated mode surfaced four phantom dependencies immediately, all in build tooling rather than application code, and all trivially fixed by adding the packages to package.json. That is the typical experience. The cost is that a handful of packages with unusual resolution assumptions break, particularly older bundler plugins that walk the filesystem looking for their own dependencies. Bun ships a compatibility list and an escape hatch to hoist specific packages.
What this does to CI costs
Continuous integration is where package install speed converts into money, because every pipeline run pays the cold install cost unless caching is configured well and often even when it is. A team running 800 pipeline executions a day at 45 seconds of install time under npm is spending ten hours of compute daily on dependency installation. Cutting that to 90 seconds under Bun saves nine of those hours, which on GitHub Actions hosted runners at standard rates is roughly $2,900 a month for a large runner class.
The catch is that install time is rarely the dominant cost in a pipeline. Test execution and build steps usually take longer, and a team that switches package managers to save 40 seconds while their test suite takes eleven minutes has optimized the wrong thing. The honest recommendation is to measure. For projects where installs genuinely dominate, typically small services with large dependency trees and fast tests, the improvement is substantial.
Bun's position in the runtime market
Oven raised a Series B in 2025 and sells a hosting product, Bun Cloud, which launched in limited availability in March. The company's strategy has been to make the open source tooling irresistible and monetize deployment, which is the same playbook Vercel ran with Next.js and Deno is running with Deploy. It requires the open source project to stay meaningfully ahead of alternatives, which is expensive.
The runtime competition has stabilized into a pattern where Node absorbs successful ideas from Bun and Deno within a year or two. Node 24 shipped a package manager improvement, a test runner, and TypeScript support, all of which followed the alternatives. Bun's durable advantage is that its components are designed together, so the package manager, bundler, test runner, and runtime share code and assumptions in a way Node's assembled ecosystem cannot match. Whether that is enough to build a company on is the question the next two years will answer.
Skarvonix will keep following this beat with reporting grounded in how systems behave outside the launch keynote.
- Open Source
- TypeScript
