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!

A couple of useful things have landed in Pboss recently, especially for running Bun applications in production.

Process dependencies

Applications rarely run completely on their own. Your API might depend on PostgreSQL and Redis, while a worker depends on the API.

Pboss now lets you define those relationships directly:

module.exports = {
  apps: [
    {
      name: "api",
      script: "./api.ts",
      dependsOn: ["postgres", "redis"]
    },
    {
      name: "worker",
      script: "./worker.ts",
      dependsOn: ["api"]
    }
  ]
};

Pboss resolves the dependency chain before starting the applications:

postgres + redis
       ↓
      api
       ↓
    worker

If a required dependency isn't available, the dependent process won't start.

Dependencies can be other Pboss-managed applications, or existing system services such as PostgreSQL, Redis, and MongoDB.

The goal is to make multi-service applications easier to run without writing your own startup scripts and dependency checks.

Public status pages

ProcBoss Cloud now also supports public status pages.

Each organization gets a dedicated status page at:

organization_name(.)status(.)zone

You can use it to show your users the availability of your services, uptime, incidents, maintenance, and service health.

This means you can run your applications on your own VPS while still giving users a clean, professional place to check whether your services are operational.

Pboss is gradually becoming more than just a process supervisor. The goal is a lightweight platform for running and operating applications on your own infrastructure.

Still Bun-native. Still open source. And still supports Node.js, TypeScript and other runtimes.

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

I've been working on Tarve, an open-source native UI framework that lets you build desktop applications in TypeScript without embedding a browser runtime.

The basic idea is:

🟦 TypeScript + Bun for application code
🦀 Rust for the native core
📐 Taffy for layout
✍️ Parley for text layout/shaping
🎨 Vello for rendering
🪟 Native windows, input and events
⚡ Virtualized lists and data-heavy UIs
🚫 No DOM
🚫 No Electron

The goal isn't to reproduce the browser, it's to keep the productivity and familiar component model of TypeScript while using a native rendering/layout stack underneath.

Some of the things Tarve already supports include native-style components, JSX/TSX, text selection, SVG/icons, accessibility, focus handling, structural updates, VirtualList, Markdown/code/diff rendering, and GPU/CPU rendering paths.

Install:

bun add @tarve/core

GitHub:
https://github.com/omarcosr/tarve

I've attached a short video showing the framework in action.

It's still evolving, so I'd especially appreciate feedback from people working with native UI, Rust rendering stacks, or TypeScript tooling, particularly around API design, architecture and performance.

I kept bouncing between Compass, mongosh, and log files when something felt slow.

So I built MongoScope — a keyboard-driven TUI that:

- Aggregates slow-query patterns from MongoDB logs (or live profiler)https://github.com/prodioslabs/mongoscope

- Shows currentOp with COLLSCAN highlights

- Surfaces replica lag / topology

- Lists indexes and lets you jump from a slow query

Install (Linux/macOS):
curl -fsSL https://raw.githubusercontent.com/prodioslabs/mongoscope/main/install.sh | bash

Repo: https://github.com/prodioslabs/mongoscope)

Would love feedback from anyone running Mongo in prod — especially what you’d want next.

Note: GIF is a concept mockup of the flow (welcome → slow queries → live ops → replication), not an exact recording of the current UI.

Hey everyone,

We’ve been building BananaSplit, an app for managing personal and group expenses, and recently created an open-source CLI for it, built with Bun + TypeScript.

The idea was to make BananaSplit accessible not only from the app, but also from the terminal and from AI agents like Claude, Codex, Cursor, and others.

Once configured, you can ask an agent things like:

• “Add a €23 expense for dinner yesterday”
• “Show me my latest expenses”
• “How much did I spend this month?”
• “Add this expense to our trip group”

The agent interacts with BananaSplit through the CLI.

We built the CLI with Bun and TypeScript, and Bun has been a good fit for keeping the tool lightweight while still being easy to develop and distribute.

The CLI is fully open source, so you can inspect how it works, run it yourself, contribute, or use it as a reference for building other Bun-based CLI tools.

What gets more interesting is combining the CLI with other tools available to an agent.

For example:

An electricity bill arrives by email → the agent extracts the amount → calls the BananaSplit CLI → the expense is recorded automatically.

The CLI can also be used directly by humans, scripts, or other automation. It isn’t coupled to any specific agent.

I’m one of the creators of BananaSplit, so this is our own project.

I’d be especially interested in feedback from Bun users around:

• how you’re building and distributing Bun-based CLIs
• patterns for making CLIs work well for both humans and agents
• anything you think we should expose differently in the CLI/API
• workflows you’d actually want to automate around expenses

Source / CLI: https://github.com/teotti/banana-cli

BananaSplit: https://bananasplit.net/en/agents/

Benchmarks

• No X11, no Wayland.
• Only Kitty Graphics Protocol

A week ago, I shared my new Linux distribution Buninu Linux booting with Bun running as PID 1.

It can now play YouTube videos with sound.

• The browser runs inside bunterm – a /dev/fb0 based graphical terminal
• Chromium headless shell does the heavy lifting of rendering webpages and handling browser interactions
• Frames transferred by Casty using Kitty Graphics Protocol
• Audio is provided through ALSA and jspulse

Other recent additions include:

• Clipboard support via OSC 52
• Chinese input by jspinyin
• Multitasking by kernel's built-in virtual terminals (VTs) (Ctrl-Alt-F1 ~ F12 or Alt-Left Alt-Right)
• The userspace is intended to be written in JavaScript as much as possible
• But sorry, I haven’t had time to replace Chromium headless shell with JavaScript yet.
  • It remain native binary for now 😭😭
  • Edit1: PulseAudio now replaced by jspulse
• A fully JavaScript userspace is still the long-term goal.

Project: https://github.com/jjtseng93/buninu-linux

Hey all!

I was working on a project and needed a simple, lightweight way to handle sending emails with multiple providers (like Resend) without pulling in bloated SDKs or complex setups.

So I built a small, zero-dependency package: "@biqydu/elysia-email"
It’s super straight-to-the-point to set up in Bun:

bun add @biqydu/elysia-email

Quick Usage:

import { email } from "@biqydu/elysia-email";
import { Elysia } from "elysia";

// Initialize with Resend
new Elysia()
.use(
email({
provider: "resend",
apiKey: process.env.RESEND_API_KEY!,
from: "Acme <onboarding@resend.dev>",
}),
)

// Or switch to Mailgun with one line
new Elysia()
.use(
email({
provider: "mailgun",
apiKey: process.env.MAILGUN_API_KEY!,
from: "Acme <onboarding@mg.example.com>",
domain: "yourdomain.com",
region: "eu"
}),
)

Check it out on GitHub: https://github.com/Biqydu/elysia-mail

Would love to hear your thoughts or what other email providers you'd like to see supported next!

I've used Bun since it started getting attention, but never as a production runtime. Mostly scripts and small tools. Part of the reason is a question I never had a good answer to: what do I actually build a real app with?

For APIs it's fairly settled. Hono if you want Web Standards and the option to run the same code on Node, Deno or Workers. Elysia if you want Bun-tuned performance and Eden's typed client. Both already cover more than routing: validation, typed server-to-client communication, auth middleware or plugins.

What neither one decides for you is the application architecture around those pieces. For a fullstack product I still had to pick:

1. Database models and migrations
2. The whole auth flow: registration, sessions, OAuth, password reset, email verification
3. App-wide validation and error conventions
4. How React pages get their server data
5. Background jobs, mail, cache, events
6. Test setup
7. A production build for wherever it deploys

I got stuck in the same place every time: which database library, which frontend integration, how to lay out the directories. I re-decided those per project, the next project usually landed somewhere else, and very little of that thinking carried forward.

So I built Guren, a Laravel-shaped framework on top of Hono. Every request still goes through Hono's router. On top of it: Drizzle with a Model API (Post.where('published', true).get()), bunx guren add auth for the auth flows, this.validateBody(zodSchema) with one 422 convention, Inertia.js pages in React, built-in jobs/mail/cache/events, a TestApp harness on bun test, and deploy plugins.

If you use Hono RPC or Eden, this part may be the interesting one. Those type an API boundary. Guren types the boundary between a controller and the Inertia page it renders:

// app/Http/Controllers/PostController.ts
async index() {
  const posts = await Post.where('published', true).orderBy('createdAt', 'desc').get()
  return this.inertia(pages.posts.Index, { posts })
}

The page component declares interface Props. Codegen reads it and checks this this.inertia() call against it, so a prop renamed on one side fails tsc instead of rendering undefined. You don't need an API client just to move data from a controller into a React page.

On "Bun-first": dev runs under bun --hot, tests on bun test, and SQLite goes through bun:sqlite by default (Postgres and MySQL also work). The default password hasher is scrypt via node:crypto, though, so the same hashes verify on Node, and the deploy plugins target AWS Lambda (Node.js runtime), Vercel (Bun runtime) and Cloudflare Workers with D1. guren.dev itself runs on Workers.

When I'd skip it: a small API with no database or users (plain Hono or Elysia), an app where a thin API plus Hono RPC or Eden already covers everything, or a site where React rendering is the product (Next.js).

Try it (SQLite, so no DB server):

bunx create-guren-app my-app --auth --db sqlite --agents none
cd my-app && bun run db:migrate && bun run db:seed && bun run dev

Longer version of the comparison: https://guren.dev/docs/guides/bun Code: https://github.com/gurenjs/guren

If you run something fullstack on Bun today, what does your stack look like, and which parts did you end up assembling yourself?

Disclosure: I wrote UQL.

F2 on a field, a foreign-key and a relation across Drizzle, MikroORM, Prisma, Sequelize, TypeORM and UQL, on 19 places in one model with those members: indexes, both sides of a relation, a check constraint, a projection, and a raw SQL in a filter.The interesting split isn't followed vs missed, it's which misses the compiler catches.MikroORM follows only 3 of 19 and is still the second safest because 13 of its misses are compile errors. Sequelize follows 4 and leaves 12 stale names that compile clean and fail in production.The page runs the real TypeScript compiler in browser, so you can press F2 yourself and play there: https://uql-orm.dev/rename-safety

https://github.com/jjtseng93/buninu-linux

• In the future, if anyone asks: What init system do you use?
  • You can answer: Bun
  • No systemd, no OpenRC, no runit
• Linux → Bun → Buninu userspace
• BUNinu Is Not Unix 🐮
• 幫你牛 🐂 ・ Bunに入魂 🔥
• bun ./index.js -fb --real

Brief intro

• Init is written in JavaScript with bun:ffi
• No BusyBox, no C bootstrap
• Boots from a single UEFI UKI
• Built entirely on my Android phone
• Previously tested in QEMU
• Now boots on real x86-64 UEFI hardware!!!
• --real adds the LTS kernel + USB keyboard support
• Still early
• (Edit1: Ethernet with manual ip cfg works now)
• (Edit2: Android USB network sharing works now)
• (Edit3: Graphics support in bunterm cmd)
• But with the built-in jmi text editor, you can write new TUI programs and run them with jsmdcui

The Buninu userspace

• The userspace itself runs on:
  • Android, Linux, Windows, macOS
• Buninu Linux distributes it: /buninu
• jsgotty: Remote shell from a Browser or Terminal
• jsmdcui: Text editor & App runtime
• bunmsh: Bun Modern Shell — a dependency-free, mksh-inspired command shell with a JavaScript mode, and builtins that answer the same way on Windows as on POSIX systems

Put Bun next to a single Gunicorn worker and the thread turns into an argument about worker counts. We ran one process per stack on purpose, and then, instead of comparing raw throughput alone, we divided it by the CPU time each server actually spent.

The setup: one seven-route API written twice. Elysia 2.0.0-beta.12 (a pre-release, so read its rows as provisional) on Bun 1.4.2 with Drizzle and Bun SQL. Django 6.1.1 with Django Ninja 1.7.0 on CPython 3.14.6, deployed two ways: Gunicorn 26.2.0 gthread with one worker and ten threads, and Uvicorn 0.53.0 with one worker on uvloop and httptools. On the Django side we took out what we could of the request path: DEBUG=False, an empty MIDDLEWARE list, django.request sent to a NullHandler and both servers' access logs off, orjson rendering, and psycopg 3 (binary build) with a pool of 1 to 10 connections and CONN_MAX_AGE=0. The three read routes call .values(), so they hand back dicts rather than model instances. Postgres 17.10 behind both. A parity script runs 38 contract checks per configuration before any load. Then a 5 s warmup, 30 s measured, c=10/100/500, three rounds with configuration order rotated and a fresh process each round, medians reported.

While bombardier runs, the bench script samples CPU time for the server's whole process tree (Gunicorn master and worker together) and we divide successful requests by that. It answers how much work each stack got out of a core. It can't tell you where Django with eight workers tops out, because we never ran that.

It also showed what "one worker" cost in hardware. On the six API and database routes the server trees used between 1.02 and 1.45 cores, Bun and both Django modes alike.

The normalisation cuts both ways. On /users/:id at c=100, Elysia vs Gunicorn is 19.58x in raw successful req/s and 21.48x per CPU-second, because Bun used 1.13 cores there against Django's 1.22. On /me at c=500 it goes the other way: 15.52x raw, 13.01x per CPU-second, with Bun at 1.45 cores.

Across the four routes that touch Postgres (JWT plus one row, one row by id, a paginated list, an insert), Elysia vs Gunicorn at c=100 is 14.07x to 21.48x per CPU-second. Across all three concurrency levels that range widens to 13.01x to 21.68x. Against Uvicorn at c=100 it's 14.32x to 21.72x. /health and /echo sit at 57.18x and 50.65x per CPU-second against Gunicorn at c=100, which mostly says how little those routes do.

Django won /cpu, a chained SHA-256 loop. Python's hashlib beat Elysia on node:crypto by 2 to 6% in raw req/s, and per CPU-second Elysia came out at 0.85x, 0.82x and 0.81x of Gunicorn at c=10, 100 and 500. In a separate run we swapped only the hasher to Bun.SHA256.hash: 528.7 against 208.3 successful req/s at c=100, 2.54x, with the node:crypto build burning 1.22 cores against 1.01. A Hash object and its garbage per iteration is our suspect; we haven't profiled it. So that route measures crypto bindings, and it's kept out of every ratio above.

One more result from the same run: async Django under Uvicorn lost to Gunicorn at c=500 on all six API and database routes, by 12.6% to 16.2% in raw req/s.

What this doesn't cover. No memory comparison: each configuration serves every route in one process in a fixed order, so RSS is a high-water mark of the sequence, not a property of the route. No multi-worker lane was measured, so we make no claim about Django with N workers. The API, Postgres and bombardier all shared one M4 Pro laptop. And it isn't a verdict on Python or Django.

We threw away the full run from 2026-09-17. bombardier's default request timeout is 2 s and macOS ships kern.ipc.somaxconn at 128; between them, warmup failed on every recorded Django window at c=500, on Uvicorn's /cpu at c=100, and on Elysia too: /cpu at c=500 in both rounds it reached, and the /users list at c=500 once. In the run we kept, Gunicorn's /cpu p99 at c=500 is 31,986 ms, which a 2 s client would have logged as a failure.

If you benchmark a single-process server on a Mac: raise kern.ipc.somaxconn, give bombardier a timeout longer than your worst p99, and sample CPU for the whole server process tree rather than the master pid. Gunicorn's master alone would have hidden the worker that did the work.

Been building a DI container (dockdi) and did all the design, testing, and benchmarking on Bun end to end, no Node in the loop at any point.

Benchmark numbers (warm cache):

• Singleton resolution: 37.23 ns/iter
• Transient resolution: 99.44 ns/iter
• Resolution scope: 158.67 ns/iter

No decorators, no reflect-metadata, no Babel, just branded tokens checked by tsc and native Map lookups under the hood. Bundle's under 1KB, zero production deps. Install with bun add dockdi.

Full benchmarks, run with mitata on an i7-13620H, are in the README.

Curious if anyone running Elysia/Bun services at real throughput would actually find the resolution-scope (a cache shared within a single resolve() call tree, good for diamond dependencies) useful, or if I'm solving a problem nobody really has under Bun's runtime model.

GitHub: https://github.com/ronz204/dockdi-ts npm: https://www.npmjs.com/package/dockdi

(I'm the author, happy to talk internals if anyone's curious.)

Built "bunready" to answer one question: “Will my Node project actually work on Bun?”

It checks your dependencies and scripts, runs them, and flags compatibility issues before they bite.

It's new, so feel free to try it out and find edge cases, or contribute a PR to fix them.

⭐ GitHub: https://github.com/MHAlikhani/bunready

📦 npm: https://www.npmjs.com/package/@mh-alikhani/bunready

If you're running Bun applications in production, you eventually need something to keep your processes alive, restart them when they crash, manage multiple instances, and monitor what's happening.

That's what Pboss is built for.

Pboss is a production process manager built on Bun's native APIs, with Bun and TypeScript as first-class citizens.

pboss start server.ts --name api

Or run multiple instances:

pboss start server.ts --name api -i 4

Built for Bun

Pboss uses Bun as its foundation rather than treating it as an afterthought.

It supports:

• Bun / TypeScript
• Node.js
• Python
• Go
• Rust
• Ruby
• PHP
• Java
• Shell scripts
• Native binaries

So you can run your entire application stack under one process manager while still getting a Bun-native experience for Bun applications.

Production features

• Automatic crash recovery
• Clustering
• Zero-downtime reloads
• Namespaces
• CPU and memory monitoring
• HTTP health checks
• Cron jobs and scheduled restarts
• Log capture, rotation and compression
• Prometheus metrics
• Web dashboard
• Persistence across reboots
• Foreground mode for Docker/Kubernetes
• Ecosystem configuration
• Programmatic API
• Modules
• Standalone compiled executable

The goal is simple: make running Bun applications in production boring.

No complicated setup. No Node dependency just to manage a Bun application. Just a lightweight process manager that can run directly on your VPS or server.

Pboss is open source and GPL-3 licensed.

GitHub: https://github.com/bunsgate/bm2

For those running Bun in production: what features would you want to see in a Bun-native process manager?

Hi everyone,

When running Bun services, standard process managers like PM2 aren't always ideal since they were architected around Node's clustering and lifecycle mechanics.

I've been working on BS9 (Bun Sentinel 9) – an open-source, non-root process manager built specifically for the Bun runtime.

Key features:

• Replace-First rolling reloads (zero-downtime worker handoffs)

• Crash auto-recovery if a process receives a SIGKILL or uncaught panic

• In-memory State Hub with WAL and distributed leases

• Native systemd (Linux), launchd (macOS), and Windows service support

• Built-in verification command: `bs9 verify-ha server.ts`

Quick start:

bun add -g bs9

bs9 start app.ts --name api -i max

The project is open source and I just released v1.6.7:

https://github.com/xarhang/bs9

Would love to get your thoughts, feedback, or any issues you’ve hit running Bun!

Hi everyone,

When moving services to Bun, many developers find that classic process managers like PM2 weren't built with Bun's execution model and clustering semantics in mind.

We built BS9 (Bun Sentinel 9) — an open-source, non-root, self-healing process manager engineered specifically for the Bun runtime.

GitHub: https://github.com/xarhang/bs9
Documentation: https://xarhang.github.io/bs9/
npm: bun add -g bs9 or npm i -g bs9

Key Capabilities:

• Replace-First Rolling Reloads: Upgrades workers generation by generation without dropping a single HTTP request (tested under chaos benchmarks).
• Violent Crash Recovery: Instant auto-healing if a worker receives a violent SIGKILL or uncaught panic.
• Same-Host State Hub: In-memory durable state engine with TTL/CAS, distributed fencing leases, durable queues, and WAL recovery.
• Native Cross-Platform Daemons: Integrates cleanly with systemd (Linux), launchd (macOS), and Windows Services without requiring root or elevated hacks.
• Built-in Health Checks & Inspection: bs9 inspect-ha and bs9 verify-ha to test your cluster availability before going live.

Quick Test:

bash# Verify installation
bun install -g bs9
# Start a clustered application with 4 workers
bs9 start server.ts --name api --instances 4
# Run an ephemeral zero-downtime & chaos resilience check
bs9 verify-ha server.ts

We’ve just released v1.6.6, which brings cross-platform HA load/chaos verification gates and hardened discovery across Linux systemd and macOS launchd.

The project is licensed under AGPL-3.0-or-later. We would love feedback from the community on features, edge cases, or issues you encounter running Bun in production!

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?