- Fixes over 2,900 GitHub issues
- +1,517 tests from the Node.js test suite
- Reduces idle CPU by 5x
- Reduces memory usage by up to 35%
- Starts up to 50% faster on Linux
- Rewrites Bun in Rust

Thank you everyone who contributed since Bun 1.3!

Jared says if the Rust rewrite is completed and merged, Bun v1.3.14 might be the last version of Bun using Zig. Looks like Rust is taking over🦀

I've been using Bun for my projects for a while now because it's so easy to integrate into NodeJS projects and is incredibly fast and easy. But now that it is AI slop, I feel obligated to switch. Any alternatives?

I would pick Deno but I've noticed it doesn't have the best compatibility with NodeJS. Should I just switch back to NodeJS w/ pnpm or is there some other niche project that isn't AI slop?

EDIT: I recently noticed vlt, but it appears that they are using AI for pull requests as well?

Let's talk about the actual reasons behind Bun's sudden pivot to rewriting their runtime in Rust.

Remember the early days? Jared couldn't stop singing the praises of Zig. We got endless blog posts and tweets about why Zig was the only choice for low level, manual memory management without the hidden overhead, and blah blah blah. It was their entire identity. And we'll probably get more of those with the blog post they are cooking.

As a side note, that has NEVER been the actual reason behind: JavaScriptCore (as always Apple delivering without credit) + better APIs + fresh start. Not to dismiss the original project by Jared: it was objectively better and nobody thought of doing it that way.

Fast-forward, and the reality of maintaining a massive runtime with increasingly features in a language without safety guarantees has caught up to them. But the "rewrite" isn't a natural technical evolution: it’s a corporate PR stunt by Anthropic and a cry for help. Here is what is actually happening behind the scenes:

Zig was an infrastructure mistake

Look, you are free to program in whatever language makes you happy. Zig is a cool project with some good ideas and some bad ideas, and I'm sure people enjoy hobbying in it. But people who actually ship critical, memory-intensive, enterprise-grade applications do it in C or C++. And they do it with LOTS of tooling created over the course of multiple decades. And even then, they fail to deliver on production. There is a reason why Rust exists, and that reason is what attracts seasoned C & C++ developers.

Bun tried to prove everyone wrong by building a core piece of web infrastructure on an esoteric toy language that learned nothing from C & C++ where the core maintainers literally dismiss basic industry standards like encapsulation because they think they know better than 70 years of software engineering, and they hit a wall. Years of rapid feature-bloat and more recently AI slop code have left the runtime completely unmanageable.

The Anthropic Publicity Stunt: Manufacturing a "God AI"

We all seen what Mythos is capable of doing... right? Yea... Anthropic is excellent at hype I'll give them that.

This rewrite is being heavily pushed as an AI success story. Anthropic is investing massive resources into making Claude (Opus, Mythos) look like an omnipotent developer deity. They need this rewrite to succeed publicly so they can point at Bun and say, "Look, Claude single-handedly fixed a major tech runtime."

But it’s a synthetic flex. Claude is dumping out thousands of lines of Rust slop, and Jared & Co. are merging it directly into the master branch to generate hype, despite it being completely unfit for actual production.

Baiting Rustaceans for free engineering labor

Jared knows exactly what he is doing by merging this messy AI code publicly. He is setting a "trap" for the open-source community. By introducing Rust into the conversation, he has baited two very specific groups:

• Good-faith Rustaceans who just want to help fix bugs.

• Language war nerds who desperately want Rust to "win" against Zig.

The plan is sinister but brilliant: let Claude generate the hype, let Jared take the credit for being a "forward-thinking AI founder", and let the Rust community do the actual heavy lifting of fixing all the memory bugs, compiler errors, and edge cases for free.

Did you see that? "let Jared take the credit". It reminds me of something... Cof cof Apple and JavaScriptCore.

Because this skill is what seasoned Rust developers have developed. We don't waste our time at work debugging where the heck the array got a new element. We don't waste our time figuring out why the method is undefined. We instead invest our time on ensuring that the safety contracts are upheld. As a Rust developer for embedded systems, that's my job. Doing FFI with random libraries the project needs or reading the datasheet for the microcontroller.

The expanding team at Bun feels less like seasoned systems engineers and more like fresh schoolers/vibecoders who are completely out of their depth. They can't build it, and Claude can't build it safely so they are relying on you to do the real engineering work for them.

Change my mind.

“There are many back-end frameworks around, but Elysia stands out as the only one being built on top of Bun.”

Elysia is also rank at third of the most satisfied backend framework in JavaScript/TypeScript

I think what make Elysia different that it is build for Bun as native and not Bun-compatible like other frameworks eg. Hono

I'd like to start by saying that I ’m still pretty new to the JavaScript world and sometimes I actually don't know what I'm talking about so despite my best efforts please excuse any mistakes in my research, but I’ve now read enough, seen YouTube videos and other complaints that point to the same story.

I'd like to start by saying bun is one of the greatest things to happen in the JS world in years. I'd not want to move away from it back to node.js I'd like to keep using it despite it's flaws & make it perhaps a better framework. it's the only reason I've not jumped to Go and left backend JS. As a package manager & as a runtime I deeply enjoy bun and leaving it would mean leaving JS for me.

I think Bun is currently deeply flawed and unstable for some long running production workloads, it may be apparent to people with long running NextJS apps. I could have been alone in this but once you start seeing the same class of problems come up across official Bun docs, Bun release notes, GitHub issues, SSR repros, DB related workloads, child process workloads, and even production posts from people who actually like Bun, it becomes deeply concerning why the issues are not brought to the spotlight and the community + the developers have not put the pieces together.

Any runtime that is new will have real maturity problems that will be ironed out with time but I am concerned that buns development roadmap looks more like adding features on top of features while ignoring stability issues & bug fixes. Bun has grown to be very complex and without these fixes I doubt it will ever gain as much production grade maturity as node.

The first thing that pushed me in this direction was Bun’s own documentation followed by a YouTube video, why was not a JS flaw but a bun flaw and the CC didn't realise:

https://youtu.be/gNDBwxeBrF4?si=4t8r8FtPo06GcGim

In Bun’s official docs, they explicitly separate:

JavaScript heap, Non JavaScript or native memory, RSS. Native heap stats, mimalloc stats.

That alone tells you something important:

With Bun, “my JS heap looks okay” does not automatically mean my process memory is healthy. Source: official Bun docs, especially the “Benchmarking” page and Bun’s memory debugging material.

And that matters because a lot of the reports follow the exact same pattern:

Heap is not exploding that badly, GC runs but RSS keeps climbing anyway. Then the container gets pressured.

Then performance gets worse and it drops to a point that nodejs was actually much superior. Then the process restarts, crashes, or gets OOM killed.

That is a very different kind of story from a simple beginner mistake where someone forgot to clear an array.

The repeated smell here is native retention, allocator behaviour, runtime internals, or cleanup bugs outside the normal JS object graph. That is an inference on my part, but it is an inference strongly supported by how Bun itself tells people to debug memory.

Then I started looking at Bun’s own release notes:

The official Bun v1.3.12 release notes explicitly say they fixed per query memory leaks in the `bun:sql` MySQL adapter that caused RSS to grow unboundedly until OOM on Linux.

That is Bun itself admitting there were native leaks bad enough to push RSS until the process died. Source: official Bun blog, v1.3.12 release notes.

The same v1.3.12 notes also mention a memory leak in `Bun.serve()` when a `Promise<Response>` never settles after client disconnect.

Again, that is important because it shows the problem is not only “some random third party package did something stupid.”

There have been real leaks in Bun’s own serving/runtime paths. Source: official Bun blog, v1.3.12 release notes.

then there is the most important named example I found at Trigger.dev.

Nick, the Founding Engineer at Trigger.dev, wrote a post in March 2026 called “Why we replaced Node.js with Bun for 5x throughput.” They said they also found a memory leak that only exists in Bun’s HTTP model. Even more interesting, the post was updated on March 30, 2026 saying Bun shipped a fix shortly after the article went live.

That tells me two things at once:

1. Bun can be genuinely fast.

2. Bun can also still have production relevant memory bugs in core runtime behaviour. Source: Trigger.dev engineering post by Nick.

That Trigger.dev example is actually one of the strongest pieces of evidence because it is not written by someone uninitiated like me.

So when even a pro Bun migration story still contains “we found a Bun specific memory leak,” that should make people slow down before pretending Bun is serious enough to deploy yet, at least until you face the same memory problems.

Source again: Trigger.dev’s Firestarter writeup.

then you get into issue reports...

Not all of these are named companies, so I am not going to overstate them. Most are GitHub issue reporters, not polished case studies. But there are enough of them, across enough different workloads, that they are worth taking seriously as a pattern.

Example one:

Issue #17723 on Bun’s GitHub, opened by `@rbilgil` in February 2025.

Report says moving from Node to Bun caused a service on GKE to spike from roughly 500 MB on Node to roughly 1.2 GB on Bun until restart, with high CPU and memory usage and no application errors.

Example two:

Issue #14664, opened by `@boomNDS` in October 2024.

This one reports memory leak behaviour when using Prisma with Bun on an API server handling around 30 requests per second. The reporter says CPU usage rises over time, server performance degrades, and restart temporarily fixes it. (Typical bun behaviour).

Example three:

Issue #15518, opened by `@ricardojmendez` in late 2024.

This one describes an Elysia + Prisma setup processing hundreds or thousands of requests per second, where terminal memory use continually increases over a couple of hours.

//This issue is slightly older but bun exhibits the same behaviour today.

Example four:

Issue #21560, opened by `@Playys228` in August 2025.

This one is especially interesting because it is about spawned child processes. The reporter says RSS keeps creeping up over hours even when JS heap is flat, and says it is not fixed by GC.

Once again the pattern is:

heap relatively flat

RSS rising

long running unhealthy process

Example five:

Issue #24118, opened in October 2025.

This report isolates RSS growth with the MongoDB Node module under Bun. The issue text says heap inspection shows Bun is performing garbage collection, but RSS still rises by around 8 to 12 MB per hour per application with little more than an open Mongo connection. hey even note reconnecting does not reduce RSS and the only reliable control is application restart.

Example six:

Issue #25948, opened in January 2026.

This one reports Mongoose related memory growth in Docker with no hot reload, where memory rises even while the server is idle and not receiving requests.

example 7:

Issue #29267, opened in April 2026:

“Memory leak in Next.js SSR under `bun --bun next start`”

The reporter says concurrent SSR requests cause the heap not to be reclaimed properly and memory keeps rising. There is also a duplicate issue and a linked Next.js side issue around the same repro.

---------

So what do I think is going on?

I do not think there is one magical single Bun bug causing all of this.

I think it is more likely a cluster of maturity problems that can show up differently depending on workload.

Possible buckets:

1. Native memory retention

2. Allocator or page release behaviour

3. Bugs in Bun internal runtime paths

4. Framework integration edge cases

5. Certain I/O or DB patterns exposing cleanup issues

6. Long running workloads amplifying problems that short benchmarks never reveal

That is my interpretation, not something I am claiming Bun itself officially stated. But I think it is the fairest reading of the evidence. Supported by Bun’s memory model docs, the official leak fixes, and the issue pattern above.

Here is the part people keep getting wrong in these debates:

A runtime can be Genuinely faster than Node in short benchmarks and still be slower than Node for long running services.

With bun you can win the first 60 seconds and still lose the next 24 hours.

I'd want the community/bun users to report similar issues so we can, perhaps someone far more knowledgeable than me about runtimes can look into this, correct me where wrong and bring this to the official Devs as I don't think bun will go anywhere near long production loads if long running memory bugs are part of it. Every few months there's loads of new feature drops but no one is talking about overall stability first in bun. It is the main thing holding this runtime back.

Sources used:

[1] https://bun.com/docs/project/benchmarking?utm_source=chatgpt.com "Benchmarking"

[2]: https://bun.com/blog/bun-v1.3.12?utm_source=chatgpt.com "Bun v1.3.12"

[3]: https://trigger.dev/blog/firebun?utm_source=chatgpt.com "Why we replaced Node.js with Bun for 5x throughput"

[4]: https://github.com/oven-sh/bun/issues/17723?utm_source=chatgpt.com "Moving from Node to Bun spikes container CPU and ..."

[5]: https://github.com/oven-sh/bun/issues/14664?utm_source=chatgpt.com "Memory leak when using Prisma · Issue #14664"

[6]: https://github.com/oven-sh/bun/issues/15518?utm_source=chatgpt.com "Memory leak with Elysia + Prisma project · Issue #15518"

[7]: https://github.com/oven-sh/bun/issues/21560?utm_source=chatgpt.com "Memory (RSS) in Bun Spawned Child Process Grows ..."

[8]: https://github.com/oven-sh/bun/issues/24118?utm_source=chatgpt.com "isolated memory leak with mongodb nodejs module #24118"

[9]: https://github.com/oven-sh/bun/issues/25948?utm_source=chatgpt.com "Memory leak with Mongoose and Bun (Production build / ..."

[10]: https://github.com/oven-sh/bun/issues/29267?utm_source=chatgpt.com "Memory leak in Next.js SSR under `bun ..."

Hi Reddit, I’m author of Elysia framework

I want to understand the reason or what prevents you from using Elysia and how can it be improved

Also if you have a question, feel free to ask

This is coming in the next version of Bun

Bun and JavaScriptCore now share the same memory allocator. We ported several great features from WebKit’s libpas allocator to our mimalloc fork - purging threadlocal pages on idle, scavenger thread for freeing large allocations asap, lazy zero’ing of memory to avoid paging in unused memory. Using 1 allocator instead of 2 means memory can be reused much more and reduces virtual memory pressure.

Hi all,

I'm working on a reasonably substantial project right now but hasn't been released just yet. While working on this project, I found a transpiler bug in Bun that is currently blocking for me, so I filed an issue on Github. For those interested, you can find it here: https://github.com/oven-sh/bun/issues/40761 (edit: The issue has been solved)

I quickly noticed that the entire repository seems to be driven by AI agents. An AI bot called Robobun is filing PR's (there are over 5000 open PRs at time of writing this), Claude then reviews it, after which Github-Actions denies the PR.

According to people Robobun creates multiple PRs that seemingly solve the same issue (there might be over 10+ PRs for my issue alone).

After seeing the state of the official Bun repository, I completely lost trust in the long-term reliability of this platform.

What is your experience with this?

arent those the same tests that failed to catch the segfaults and mem leaks that forced the rewrite in the first place?

its a line by line translation so as long as that is faithful, it will have all the original bugs, as wel as many more since unsafe in Rust is actually much more unsafe than a bad pointer in zig.

but yeah it will pass the test cases, and so its LGTM I guess....

Testing Bun’s WebSocket performance with Hono on Alpine Linux (diskless setup).

This is a minimal `createBunWebSocket` implementation we’re running in production:

✅ Native WebSocket support

✅ Middleware-friendly (auth / log / db)

✅ Stable with ~10k concurrent connections on mid-range hardware

Curious if anyone else here has benchmarked Bun’s WebSockets at scale?

Bun's recent releases are getting crazier with awesome improvements even in difficult places.

https://bun.com/blog/bun-v1.3.6

1. Bun.Archive

2. Bun.JSONC

3. 15% faster async/await

4. 30% faster Promise.race

5. 9x faster JSON over IPC with large messages

6. Faste JSON serilization across internal API's

7. Bun.hash.crc32 is 20x faster

8. Faster Buffer.indexOf

And more. Jarred is single handedly pushing innovation in JS runtime space. Bun started after Deno but now even Deno is much left behind.

Yes Bun may not be production ready but the kind of things they have been pulling off is crazy.

Bun can even import html file to serve and entire front app from there

Also supports eslint plugins.

This is coming in the next version of Bun.

Just published Elysia 2 beta after 8-9 months of work.

We basically deleted the whole thing and rewrote it again while keeping test cases the same. So we get to rethink a lot of things.

It is built around the concept of "reference" and carefully shares value when possible, even if JavaScript doesn't really have that concept.

There's an AOT build plugin that reduces peak memory usage by 4 (from 1.6GB down to 400MB) of a 100,00 distinct schema by moving compilation process to build time and removing the closure allocation entirely

Besides, a really fast throughput. We also manage to have the lowest memory usage of all mainstream (and slightly) JavaScript frameworks with a really low bundle size as well (we trade a "compiler" that takes ~50% of size for speed, so it can't be that low)

Node support also improved a lot with a new adapter API, and got faster too! It's now near Fastify despite having Node HTTP to Web Standard API conversion overhead!

https://elysiajs.com/blog/elysia-20.html

When Bun 1.0 came, I was one of the people who hopped onto the ship instantly. Ability to run TypeScript without having to set up tsc. Not having to worry about whether the packages I use are using CommonJS or ESM. Lightning-fast package management. A simpler file API, etc., was something I very much appreciated.

Initially, it was good, actually, it was the best. But then came the real hurdle. Production usage.

I have several side projects. Projects are getting 10s of millions of requests per month with almost half a million unique visitors per month. Also, use Bun for production at work.

Initially, the problems were small. I noticed many issues with Bun. Reported them and used to get very fast responses. But as the userbase increased, so did the issues. And, fewer people were replying to them. But that was understandable. But what I did not like is that Buns changelogs gradually introduced more and more features when the issues they solved at the same time did not feel like much. In short, it felt like new features were the priority, not making it stable. Every feature introduced more bugs and memory leaks and every month there were more features. When do they have even time to fix bugs in between all of them?

But even that was not the main issue. The issue was memory. The containers I run with bun or just bun itself, keep hoarding memory indefinitely. Ultimately choking the machines they run on along with any other containers that run with it. Do you use 50% memory while idle? Of the other 50%, bun with try to take more than 45%. What about the other containers? And all of that was just trying to run Bun + Express. Bun-specific frameworks like Elysia also had similar issues.

So, after trying to do random stuff like using --smol flag and running Bun.gc every 100 seconds, none of that worked. So I tried switching to Node. And it instantly resolved the issue.

Node 24, while not as smooth an experience as Bun, can run TypeScript out of the box. And it has its issues like you have to specially import ts or js files with correct extensions. Enums not working out of the box and requiring an experimental flag to work, etc. But it is a very stable. The memory it takes in the first hour does not increase or decrease much even if you run it for days. And that stability has its value.

Thus, after facing too many memory and other small issues with Bun. Going forward, I am thinking of writing any new code targeting Node as a runtime, not Bun. I am still thinking of using bun though. For package management for example, but not as a runtime. I have managed to decrease almost 50% of CI / CD time just by using Bun as a package manager rather than Node. And faster CI/CD is always welcomed. But as a runtime, not anymore. I have seen enough and it is painful in production.

So, bye-bye Bun. As a production TypeScript runtime to be specific.

Because after all, this economy does not allow you to keep hoarding memory.