Dev

Bun 1.2 in production: six weeks later

We moved a Node.js API service to Bun six weeks ago. Here's what actually happened.

Bun 1.2 in production: six weeks later

We had a Node.js API service doing about 8,000 requests per minute at peak. Startup time was 3.2 seconds cold, which was annoying but manageable. After seeing the Bun 1.2 release notes, my tech lead said "let's try it on the reporting service" — low stakes, isolated, easy to roll back.

The good stuff first

Startup time dropped to 180ms. That's not a typo. 3.2 seconds to 180ms. For a service that scales to zero and spins back up on demand, this was huge — cold starts were killing our p99 latency on the first request after idle.

The built-in test runner and bundler are genuinely good. We deleted our Jest config, our Babel config, and our esbuild config. That alone was worth something — I'm so tired of JavaScript toolchain archaeology.

Memory usage at idle dropped about 40%. We're running on smaller instances now for the same workload.

The rough edges

Not everything worked out of the box. We use a niche Postgres driver that had a weird interaction with Bun's node:net compatibility layer — took a day to debug. Some of our worker_threads code needed minor adjustments.

The ecosystem compatibility is good but not perfect. If you have obscure native modules, test carefully before committing.

Bun is ready for production in 2025 if you're willing to audit your dependencies first.

Would I recommend it?

For greenfield services? Yes, immediately. For migrating existing services? Yes, but do a dependency audit first and start with something you can roll back easily. The performance gains are real and the developer experience improvements are real. It's not a meme anymore.

OPEN IN REEDL_ FEED →← Back to feed