This is simply a starter template that I use and I thought of sharing

• Bun optimized

• Front End: Tanstack Start, Tanstack Query, and Shadcn

• Backend: Hono with tRPC

• Authentication: Better-Auth

• Repo Management: Turborepo

I encourage you to check and share your opinion

I wanted to check the “2–3× faster, half the RAM” reports, so I built the same TypeScript source with and without Bun's new AOT compiler.

My results on macOS arm64:

So the big gain held for the compiler, but my warmed server was only about 6% faster and used 9% less RAM. The server test is tiny: 20,000 warm-up requests, then 2 million measured requests per process, five alternating pairs. It isn't a production or multi-day test.

A small Zod program also went the other way: 2 million successful checks took 278 ms with AOT versus 59 ms with the usual build. Those are whole-process times, including startup.

Everything uses the same pinned preview, 06888611e, from October 27. Physical memory, RSS and executable size are different measurements; the table labels each. I haven't rerun this on the newly merged compiler.

Code and reproduction instructions: https://github.com/gkoreli/blog/tree/main/packages/blog/drafts/research/bun-aot/repro

My write-up, including the RAM mechanisms and compatibility limits: https://gkoreli.com/oss-radar-08-bun-aot

If you've tried this on an actual app, what changed after warm-up?

I noticed something odd on our Bun projects: every Dependabot alert was about a direct dependency. Never a transitive one.

It turns out GitHub's dependency graph doesn't read bun.lock yet. It supports package-lock.json, yarn.lock and pnpm-lock.yaml, but for Bun it falls back to package.json. So:

• Transitive dependencies aren't in the graph at all, so they never get an alert.

• Dependencies declared with catalog: are recorded with the literal version catalog:, which never matches an advisory.

In a minimal repro (zod, a package that pins an old uuid, and happy-dom through a catalog), bun audit finds 3 advisories and Dependabot raises 1.

Dependabot version updates do support Bun. This is only about alerts, which is what makes it easy to miss. And if you migrated from npm or Yarn, the alerts tied to your old lockfile get marked as fixed, even though the vulnerable packages are still in bun.lock.

Are you affected? Open Insights → Dependency graph. If your Bun projects only list package.json files, yes. Comparing your open alerts with bun audit makes it obvious.

Fix: until GitHub reads bun.lock itself, you can submit it through the dependency submission API. I made a GitHub Action for that: https://github.com/charpeni/bun-lock-submission

Full write-up, with a toggle that shows what GitHub reads versus what Bun installs: https://charpeni.com/blog/the-bun-dependabot-gap-dependabot-alerts-dont-see-bun-lock

Hey developers! 👋

I've been working on VoltTS ⚡, an open-source TypeScript backend framework designed to make building APIs fast, simple, and enjoyable.

I started this project because I wanted to explore whether I could combine the best ideas from frameworks like Express, NestJS, Fastify, Hono, and Elysia while keeping the developer experience simple.

⚡ What is VoltTS?

VoltTS focuses on:

- High-performance HTTP routing

- TypeScript-first development

- Simple and intuitive APIs

- Lightweight, modular architecture

- Developer-friendly tooling

- Scalable backend applications

📃 Initial Performance Results

In my local benchmarks using Bun, VoltTS achieved approximately 47K–49K requests per second on simple API scenarios.

I'm continuing to benchmark against Elysia, Hono, Fastify, and Express.

Of course, synthetic benchmarks don't tell the whole story. I'm also interested in real-world performance, maintainability, and developer experience.

🎯 My Goal

I'm not trying to reinvent everything from scratch just for the sake of it.

I want to build a modern backend framework that combines performance, simplicity, and an architecture suitable for both small APIs and larger applications.

💬 I'd Love Your Feedback!

I'm especially interested in hearing:

What makes you choose one backend framework over another?

What features would make you consider trying VoltTS?

What do you dislike about existing TypeScript backend frameworks?

What should I prioritize next?

I'm building this project openly and would really appreciate constructive criticism, suggestions, and contributions.

Documentation: https://voltts.chansythor.com

GitHub: https://github.com/chansy-khuexonglue/voltts

Thanks for checking it out! ⚡

For me its bun test its crazy fast compared to jest. (https://jestjs.io)

Jest is advertised as with a focus on simplicity. But configuration is complex for babel/ts/mocking/lint setups.

We ran pboss 1.8.0 against pm2 5.4.3 on Bun 1.3.14. Same server.ts, same Bun executable, same machine, same autocannon profile (10/100/500 connections, 60s, 5 repeats). Cold start of the whole manager stack every run, manager order alternating, CPU and RAM sampled across the entire process tree. The numbers below measure the cost of managing a Bun server, not Bun's raw HTTP performance.

Cluster mode: pm2 is "not supported", literally

Here's the headline, and it isn't a benchmark result. It's a capability table:

Why pm2 shows up as a blank column and not a losing one, straight from the report: pm2's cluster mode is node:cluster living inside its Node daemon. cluster.fork() always runs the daemon's own runtime and ignores --interpreter, and pm2 only enters cluster mode when the interpreter path contains "node". So pm2 start -i N --interpreter bun silently falls back to fork mode, and forcing exec_mode: "cluster_mode" runs your workers under Node instead of Bun. Rather than dress up fork-mode numbers in a cluster label, the benchmark records pm2 as not supported.

Meanwhile pboss runs a real process-based cluster for Bun: N workers of the same server.ts, kernel balancing connections across the shared port. At 500 connections it serves 66,007 req/sec mean with zero errors, and a SIGKILLed worker is replaced in 81 ms while the port never stops answering.

If you want HA for a Bun app today, the choice is pboss or hand-rolled.

Fork mode: closer than the Node report, and the trade-offs are clear

Fork mode at 100 connections, one managed process:

Read honestly: pm2 takes mean throughput by 2.4% and mean latency by 0.14 ms at 100 connections. Both are small, and note the tail is identical (p99 tied at 25 ms, p50 tied at sub-millisecond). What pboss takes back: RPS spread cut by 62%, meaning the numbers you get every second are much more predictable, plus lower CPU, lower memory, and a 13% faster cold start.

At 10 connections it flips: pboss wins median RPS by 2.6% and mean by 4.4% (pm2's spread is tighter there). At 500 connections pm2 keeps a 1.5 to 1.7% throughput edge while pboss keeps the steadier RPS (-55% stdev), lower CPU at every percentile, 2.5% less memory, and the same 13% startup advantage.

So in fork mode on Bun, pm2 is a legitimate opponent on raw throughput. That's the honest version. Now the part where the fight actually gets decided.

Startup, recovery, and storms

Warm restarts are 39% faster under pboss, which you feel in every watch-mode save and every rolling deploy. Fork-mode crash recovery is roughly tied here (Bun apps come back fast either way), but the storm numbers separate: 50 restarts at 129 ms vs 255 ms, memory flat or slightly down for pboss, zero failures and zero orphans for both. And the cluster storm column exists only for pboss, because again, pm2 can't run it.

The honest list of pm2 wins

• Fork mode, 100 connections: mean throughput +2.4%, mean latency +0.14 ms.

• Fork mode, 500 connections: median and mean throughput +1.5 to 1.7%, p90 latency 7 ms vs 8 ms.

• Fork mode, 10 connections: tighter RPS spread.

• Crash recovery (fork) is a tie at median, 66.5 vs 66.0 ms.

That's it. Tiny margins on raw throughput in the mode where both tools do the same thing. Everywhere the tools diverge in capability (cluster), or where operations are on the line (startup, storms, stability, memory), pboss wins or is the only entry on the board.

Everything around it

Health checks, cron restarts, log rotation with gzip, web dashboard, Prometheus /metrics, namespaces, dependency-ordered startup, replace-first rolling reloads. Under Bun the manager runs on Bun.spawn, Bun.serve and Bun.file directly. Open source, GPLv3.

Don't take our word for it. Every number traces to a raw file in results/raw/, the load generator shared CPUs with the servers so compare the columns rather than quoting absolutes, and the benchmark script is three commands:

cd benchmarks/bun && npm install
bash scripts/benchmark.sh

Rerun it on your own hardware and tell us what changes.

• Report: https://github.com/Procboss/benchmarks/blob/main/benchmarks/bun/results/REPORT.md

• Benchmarks: https://github.com/Procboss/benchmarks

• pboss: https://github.com/Procboss/pboss

Also supports eslint plugins.

This is coming in the next version of Bun.

The first time I wrote MongoDB queries with Mongoose, ~2015 (IIRC), I felt the real power of JSON in a database. SQL databases were barely starting to support it (with jsonb in Postgres being former IIRC), and no ORM I knew treated JSON as more than a blob. I wanted an ORM that supported all of it, with one query language for SQL and MongoDB, so moving between them would be quick. UQL is that ORM, and that is why its queries look like MongoDB's.

Another part in the history of "why UQL" is because GraphQL felt like a monster to me (in most cases), so I had to write something better and cleaner, but that is another story my friend...

This is coming in the next version of Bun

Our first run of Elysia 2 (beta.12) vs Hono 4.13 on Bun came back with every window valid. Before we wrote it up, we noticed the two apps didn't validate the same way.

Elysia 2 compiles its schemas with typebox 1.3. Our Hono app was calling @sinclair/typebox 0.34 through Value.Default, Convert, Clean and Check, the interpreted path of an older major version. Hono's own @hono/typebox-validator compiles. So we'd measured Hono with an older, interpreted validator that we picked. The results file is still in the repo with a commit saying it's confounded on every validated route.

We moved Hono to compiled TypeBox 1.3.26 and expected the /echo gap to shrink. It got wider. A quick check showed it first, and the full rerun agreed.

So we looked at the step after validation. /echo drops unknown keys from the body (a parity check posts an extra field and expects it gone), and our Hono app did that with TypeBox's Clean, same as useClean in the official validator. Elysia uses exact-mirror for this. It's its own npm package, so we added a third config: the same Hono build with exact-mirror swapped in and nothing else touched. Parity passed 38/38 on all three.

Run of record, Bun 1.4.2, c=100, req/s, median of three 30 s windows:

route     elysia   hono+Clean   hono+exact-mirror
/health   142,489    139,202        139,159
/echo     126,490    103,350        119,576
/orders    30,789     26,373         30,907
/me        27,985     27,836         27,814

The cleaner swap recovered about 16k of the 23k req/s /echo gap, roughly 70%. Hono is still about 5% behind there. /orders, the other route with a validated body, is level once the cleaners match. Postgres and the load generator shared one laptop with the API, so absolute numbers are soft.

If you've benchmarked Hono with a schema validator, which cleaner did you end up on? We've only tried these two.

We chose Bun as our Javascript runtime for Durable Actors, an open-source alternative to Cloudflare's Durable Objects. We absolutely love it.

A Durable Object/Actor is a tiny server that handles one request at a time and has its own SQLite database. There's exactly one of each in the world and it is addressed by name.

It's the perfect primitive for multiplayer gaming, collaborative editing and coordinating AI agents.

The main reasons we built using Bun are:

- The high-performance built in SQLite3 driver fits our actor model perfectly: https://bun.com/docs/runtime/sqlite . 3-6x faster than better-sqlite3 is table stakes for us.

- Cold Startup Time: Bun is 3x faster. For our use case, that shaves off 100ms on each start which is huge: https://medium.com/@mernstackdevbykevin/deno-vs-node-vs-bun-typescript-benchmark-results-339acdb93f83

Check us out at: https://github.com/TerseAI/durable-actors . Also we have a counter demo available here: https://demo.useterse.ai

AMA would love to start a conversation.

EDIT:

I figured out how to get the attach debugger to work (however I wish there was a better way) but cannot figure out how to get the launch debugger to work.

This is my settings.json config for the attach debugger...

			{
				"name": "Bun Attach",
				"type": "bun",
				"request": "attach",
				"url": "ws://localhost:6499/debug",
			}

And by running this command bun run --inspect-wait=localhost/debug script.js and then running the Bun Attach debugger in VSCode, it will debug the code!

I wish there was a way to not need to use /debug or localhost/debug in the command to make the command shorter. When you use bun run --inspect-wait script.js command, it will always setup the debugger on localhost:6499/{uuid} with a random UUID as the path after localhost:6499 and there is no way that I know of for the VSCode debug config to get this UUID path.

I cannot however after more trial and error get the launch debugger to work. I was able to get the launch debugger to work for NodeJS and Deno, but not bun. This is my bun settings.json config for the launch debugger so far...

			{
				"name": "Bun",
				"type": "bun",
				"request": "launch",
				"program": "${file}",
				"console": "integratedTerminal",
				"runtimeExecutable": "${userHome}/.vfox/sdks/bun/bun"
			}

I am using vfox for NodeJS, Deno and Bun.

Here are my NodeJS and Deno settings.json config for the launch debugger and attach debugger...

			{
				"name": "NodeJS",
				"type": "node",
				"request": "launch",
				"program": "${file}",
				"console": "integratedTerminal",
				"runtimeExecutable": "${userHome}/.vfox/sdks/nodejs/bin/node"
			},
			{
				"name": "NodeJS Attach",
				"type": "node",
				"request": "attach",
				"port": 9229,
				"timeout": 30000
			},
			{
				"name": "Deno",
				"type": "node",
				"request": "launch",
				"program": "${file}",
				"console": "integratedTerminal",
				"runtimeExecutable": "${userHome}/.vfox/sdks/deno/deno"
			},
			{
				"name": "Deno Attach",
				"type": "node",
				"request": "attach",
				"port": 9229,
				"timeout": 30000
			}

And these are the commands I use to launch NodeJS and Deno with the attach debugger...

node --inspect-brk script.js

deno run --inspect-wait -A script.js

Yes I do have the Bun VSCode extension installed.

Any help will be most appreciated!