Bun 1.4 Made the Runtime the Dependency

Bun 1.4.0 shipped on August 20 with its runtime source cut over from Zig to Rust. The release also presents fifteen package-shaped jobs as built-ins: image transforms, browser control, Markdown, PTYs, cron, archives, terminal text, and more. Those changes belong together. Bun is taking responsibility for more application behavior while using Rust, upstream compatibility tests, and production canaries to make that larger boundary safer. Try 1.4 as a pinned, measured migration. Do not swap it blindly for Node.

This is not a story about dependencies disappearing. A line can leave package.json while its implementation, upgrade cadence, platform matrix, and security boundary move into the runtime. Bun 1.4 makes that transfer unusually visible. The release compresses a JavaScript toolchain into one executable, then shows the engineering bill for owning the result.

Fifteen dependencies did not disappear

Bun's release page covers everything shipped since 1.3.0 rather than only symbols first added by the 1.4.0 tag. Feature headings carry version chips. Bun.Image first shipped in 1.3.14; parts of Bun.Terminal date to 1.3.5; Bun.WebView spans 1.3.12 and 1.4.0. August 20 is still a real boundary: 1.3.14 was the final Zig release, and 1.4.0 is the first stable Rust one.

Read the fifteen-to-one claim as product positioning, not interface parity. These are Bun-native ways to perform common jobs. They do not implement every package API, and adopting them trades portable npm contracts for a tighter runtime contract.

A dependency can leave the lockfile without leaving the system.

Integration can still earn the transfer. It can remove version skew, repeated parsing, process boundaries, install time, and adapter code, while giving one maintainer enough control to optimize an end-to-end path. Independent packages have strengths worth naming: their own release cadence, a public interface shared by several runtimes, and the option to replace one subsystem without replacing the runtime. Bun wins the trade only when its implementation and operating boundary are better for the workload.

A terminal call now ends inside the runtime

Bun.Terminal is the cleanest small example. A TypeScript program supplies dimensions and callbacks, hands the terminal to Bun.spawn(), then reads and writes a pseudo-terminal without importing node-pty. In the tagged 1.4 source, the native object stores the master file descriptors, reader, writer, and event-loop handle. On Windows it also owns the ConPTY handle. The subprocess retains a pointer to the attached terminal and calls back into it on exit. Bun coordinates both objects, so the PTY lifecycle becomes part of the runtime lifecycle.

1. Create Bun.Terminal

   Columns, rows, data and exit callbacks
   attach →
2. Spawn Child process

   Child process attaches to the PTY
   bridge →
3. Own Native PTY

   POSIX descriptors or Windows ConPTY
   schedule →
4. Deliver Runtime events

   Bun event loop returns data and exit

I downloaded the official macOS arm64 1.4.0 artifact, matched its SHA-256 to GitHub's release metadata, and confirmed revision 34cbb9a40. A small PTY program spawned /bin/sh, received the marker written by the child, and observed exit code zero. That reproduces the narrow path. It does not prove node-pty parity, Windows ConPTY behavior, or resilience under an interactive agent's long session.

Rust is the payment for the larger boundary

The rewrite targeted cleanup failures rather than missing feature capacity. Jarred Sumner's account describes recurring use-after-free, double-free, and forgotten-cleanup bugs across a large native codebase. The team mechanically ported 535,496 lines of Zig with Claude Code, kept the TypeScript test suite as the behavioral contract, then used Rust ownership and sanitizer builds to expose lifetime problems.

That mechanism is credible; the phrase “Bun is memory-safe now” outruns the evidence. Bun's own post says roughly four percent of the Rust code uses unsafe, and the runtime still crosses large C and C++ boundaries. Rust can make Bun-owned resource cleanup more deterministic and move more lifetime errors to compile time. It cannot make a protocol correct, model every event-loop ordering, or prove an FFI dependency safe.

The strongest outside evidence comes from a failure, not a benchmark. Prisma Compute had two Bun 1.3 problems: memory growth while reading S3 objects and a SQL connection pool that did not recover after scale-to-zero. Prisma says the Rust canary passed both tests and launched its public beta on that build. It also explicitly refuses the larger conclusion: two repaired failure modes do not prove every pool or memory problem fixed.

Compatibility percentages cannot model an event loop

Bun reports 1,517 more Node.js suite tests and pass rates of at least 97 percent for several core modules. That is valuable evidence because compatibility is an accumulation of small semantics. Production workloads still add states the suite does not model. A post-release WebSocket report found that delaying authentication before handleUpgrade() could leave an upgrade hanging in 1.4.0. The repair merged two days after the release tag. A broad suite could be green while one ordering between authentication, upgrade, and socket lifecycle was wrong.

The timing matters more than using the bug as a scare story. The issue had a bounded reproduction, maintainers repaired it, and the fix was not in 1.4.0. “Fixed on main” and “safe in the tagged binary” are different states. Pinning a runtime makes that distinction operational instead of rhetorical.

The security obligation moved too

I also passed an image containing a raw onerror attribute through Bun.markdown.html() on the official release binary. The attribute survived, exactly as Bun's documentation warns. That is a parser contract, not a security boundary. The important point is ownership. Deleting a Markdown package does not delete the application's obligation to sanitize untrusted content.

The browser story has the same shape. Bun.WebView can remove Puppeteer from a supported automation path, but macOS uses system WebKit and other platforms use an installed Chrome-family browser. The API is experimental. A deployment may have fewer npm nodes while depending more heavily on OS versions, browser provisioning, profile isolation, and Bun's release cadence.

The package graph measures who you install. It does not measure everything you trust.

Anthropic is both the advantage and the bias

Anthropic acquired Bun in December 2025. Claude Code ships as a Bun executable and exercised the Rust port for months before stable release. That gives Bun something most runtimes lack: funding plus a demanding, long-lived, widely distributed owner workload. Terminal control, browser automation, package review, test selection, self-contained executables, and machine-readable performance reports make sense together when AI coding tools are a strategic user.

The same evidence is correlated. Claude Code proves Bun can carry serious work, but it is no longer an independent customer choosing among neutral vendors. Prisma's beta and Vercel's first-party Bun runtime broaden the case, while Vercel's public-beta label and documented Node-relative gaps keep it open. Bun's reported monthly downloads do not reveal how many teams use the package manager, the runtime, a compiled CLI, or production servers.

Fifty agents make small runtime costs expensive

My laptop is an M5 MacBook Pro with 24 GB of RAM. The CPU, memory, and disk are fast, and I still feel the machine slow down. A normal workday can include Chrome, VS Code, ChatGPT's desktop app or Claude Cowork, several CLIs and MCP servers, and many Claude Code or Codex sessions at once. The metric I care about is how much of the workstation remains after all of them are running.

This is why Bun's resource numbers matter more to me now than they would have a few years ago. Saving a little idle CPU or tens of megabytes in one process can look trivial on modern hardware. Keep 10–15 agent processes and their tools alive, then aim for 50–100, and the same steady-state costs become the limit on useful parallel work. These benchmarks measure the runtime cost beneath every Bun-based agent; total agent capacity remains unmeasured.

Bun attributes the CPU drop to better garbage-collector timer requests, a segmented-array layout for visiting JavaScriptCore Strong roots, fewer futex calls, and allocator changes. Claude Code is owner evidence, not an independent benchmark, but it is the right shape of workload: a large application that stays alive while tools, subprocesses, and user sessions keep moving through it.

Memory decides how many workers stay resident

Bun measured peak memory under one million requests with 64 connections, except the Next.js and Vite runs, which used 100,000 requests. Every tested Bun server used less peak memory than it did on 1.3:

The long-running cases are even more relevant to agent software. In Bun's Next.js App Router test, a dynamic route using React.cache and a no-store fetch settled at 238 MB after 4,000 pages on Bun 1.4. Node settled at 410 MB; Bun 1.3 kept growing. A 100-deep Response.clone() chain around a 10 MB stream fell from about 1,050 MB to 20 MB. Those are narrow tests, but both remove the kind of retained memory that makes a long session decay while the developer is still using it.

Startup and binary size constrain fan-out

Short-lived workers pay startup cost on every invocation. Resident workers pay the memory cost for their whole lifetime. Bun 1.4 cuts both in these Linux and Windows tests, which makes process-level isolation less expensive for schedulers that start tools on demand instead of keeping every tool inside one host.

Bun can also compile TypeScript or JavaScript, its imports, and a copy of the runtime into one executable for a supported operating-system and architecture target. That does not turn JavaScript into a tiny native program; each executable still embeds Bun. It does give agent tools one deployable file and one runtime boundary instead of a separate Node installation and package tree.

I want 10–15 parallel agent sessions to feel ordinary, then 50–100 terminal panes without saturating the machine. A runtime cannot erase the cost of models, browsers, editors, MCP servers, or the work each agent performs. Bun 1.4 still moves in the direction I care about: more work per machine, a smaller steady-state cost, and one fast toolchain with which to build the next layer of agent software. To me, these improvements buy capacity.

What engineers get from Bun 1.4 in practice

Bun's original moat was the integrated JavaScript toolchain. Version 1.4 pushes that integration upward into application work. Node compatibility is becoming the entry contract beneath a Bun-specific toolkit, not the final destination. That is a stronger product and a larger bet.

The architecture matters only if it removes work or makes a production failure less likely. The practical list below uses the full 1.3-to-1.4 release train and keeps the final tag boundary visible. These are the changes that make me want to test Bun again on real projects.

This is the part that genuinely excites me. Bun says the 1.3-to-1.4 train fixed more than 2,900 issues, while the Rust port fixed 128 bugs that still reproduced on 1.3.14. The one-time cutover now sits behind a stable tag. In the first week after release, smaller fixes, ownership cleanup, and performance work were already landing in an official 1.4.1 canary. That proves fast delivery from main to canary, not a faster stable cadence; at the August 26 cutoff, 1.4.0 was still the only stable 1.4 release. What changed is that the next fixes no longer have to share a release milestone with the mechanical port. Whether the 1.4.x line turns that into smaller, quicker stable releases is the next result I want to see.

Adopt by canary, not by ambient upgrade

Bun 1.4 preserved enough behavior through a source-language migration to keep widening the runtime boundary. That combination deserves a serious production trial because the integration is real, the test investment is large, and the canary evidence reaches beyond microbenchmarks. A blind replacement is still unjustified because every deleted package line concentrates more behavior behind one upgrade.

The package graph shrank. The dependency became Bun.