Bun 1.4: the Zig-to-Rust rewrite, native APIs, and why Node still owns production

This OmniKit Editorial brief is for operators who pick runtimes the way they pick models: measure memory, install time, and failure modes before you bet production. Canonical URL: https://omnikitapp.net/blog/bun-1-4. Figures below are as reported with Bun 1.4; treat them as claims to verify on the official release notes, not as OmniKit lab measurements.

Bun 1.4 changes the engine under the hood, and that matters more than any new feature. The runtime moved from Zig to Rust. Bun always had memory trouble under long, heavy server loads; the rewrite brings Rust’s safety guarantees to the garbage collector and memory management. This was not shipped blind. Anthropic is described as having stress-tested it in production via Claude Code, so the runtime has already faced edge cases on weak developer machines.

What is Bun 1.4?

Bun 1.4 is a JavaScript runtime and toolkit release whose headline is not a new package manager command. It is an engine rewrite: Zig out, Rust in, plus a batch of native primitives that used to live in third-party packages. If you only remember one sentence: 1.4 is built to leak less memory and to replace Chromium, node-pty, concurrently, and a slice of crontab glue for local work.

Does the Zig-to-Rust rewrite actually matter?

Yes, if you run Bun in containers or leave processes up for hours. The reported numbers are 35% less memory, 5× lower idle CPU use, and 50% faster startup on Linux. Startup time barely matters for long-running servers. The memory win is real for container density: more replicas on the same node, or the same replica with a smaller memory request. Idle CPU matters when you park many Bun processes on a laptop or a shared CI runner.

Rust does not magically make HTTP correct. It does make use-after-free class bugs in the GC path harder to ship. That is the honest reason to care about the rewrite even if you never touch bun.webview.

What native APIs did Bun 1.4 absorb?

bun.webview — skip Puppeteer for local agents

Bun now ships bun.webview, which skips Puppeteer and Playwright entirely. No Chromium download in the project. On macOS it uses WebKit natively; on Linux and Windows it drives existing Chrome or Edge installs. You lose cross-browser guarantees for serious E2E testing. For local AI agents or scraping scripts, it beats a 200MB dependency and a flaky browser install in CI.

bun.terminal — a PTY without node-gyp

Then there is bun.terminal, a native pseudo-terminal API. Node developers used node-pty for this, and that package was a pain to compile, throwing C++ binding errors on macOS and Windows. Bun drives Bash, Vim, or htop directly from the runtime, with no node-gyp headaches. That is the API coding agents actually need when they “open a terminal,” not a mocked child_process.

bun.parallel and bun.cron

The push into native primitives continues with bun.parallel and bun.cron. Monorepo developers usually reach for the concurrently package; bun.parallel runs multiple scripts with prefixed output. bun.cron registers scheduled jobs with the host OS: crontab on Linux, launchd on macOS, Task Scheduler on Windows. Handy for local scripts. Using it in production is an anti-pattern. Cron belongs at the infrastructure layer, not coupled to a running instance that might scale to zero or die mid-schedule.

How did package management change?

Bun 1.4 adopts the global virtual store model from pnpm. Dependencies download once to a shared cache, then symlink into projects. For multi-service monorepos, that kills gigabytes of redundant disk usage. In CI/CD and Docker multi-stage builds, caching that store can cut build times, since shared dependencies skip the resolution phase. If you already cache pnpm’s store, the idea is the same; the win is that Bun’s installer now thinks that way by default.

Where is the API still messy?

The API design has not caught up. Image processing uses positional arguments like (file, width, height, format), forcing you to memorize parameter order instead of passing clean config objects. Naming is erratic. HTTP/3 support, which is reported to run 2.5× faster than HTTP/1.1, uses flags like H3_true or H1 that shift between release patches. The protocol itself is still unstable, with QPACK edge cases and frame reordering bugs. That combination — speed plus moving flags plus known protocol bugs — is why you do not put public traffic on Bun’s HTTP/3 path yet.

Why does Bun emit heap snapshots as Markdown?

One forward-looking piece: Bun now outputs heap snapshots and profiling data in Markdown. Not for humans. An autonomous agent can ingest it, spot memory leaks, and iterate on your code without parsing binary snapshot files. That is the same reason OmniKit pages ship markdown for agent clients: machines cite what they can read as text. If you profile a leaky local server, dump Markdown, and hand it to an agent, you skip a whole class of tooling glue.

Should you replace Node with Bun 1.4 in production?

No, not for mission-critical production. Bun 1.4 is a genuine improvement for local work and CI. The inconsistent API and immature networking features mean it is not ready to replace Node there. Use it to speed up builds. Use it for local tooling. Keep production on Node until the API surface matures, HTTP/3 flags stop drifting, and you have a soak test that looks like your real traffic — not a laptop agent demo.

How should you roll Bun 1.4 out without betting the site?

• Pin the exact Bun version in CI and in Docker; do not float latest while HTTP flags still move.
• Cache the global virtual store in CI the same way you would cache pnpm’s store.
• Use bun.webview only for local agents and scrapers, not as a substitute for Playwright in CI.
• Keep crontab, launchd, and Kubernetes CronJobs as the production scheduler — not bun.cron.
• If you test HTTP/3, isolate it behind a feature flag and a soak environment; treat QPACK bugs as ship blockers.
• After a memory-sensitive service is on Bun in staging, compare RSS and idle CPU against Node on the same load.

If you model inference spend the same way you model runtime cost, the LLM Cost Calculator is the paid-API counterpart to this brief. The rewrite essay on why writing code is solved but shipping software is not sits next to this one: a faster runtime does not replace a production contract.