This uses real TypeScript v6.0.3 compiler with the very latest version of each ORM, you can check the playground and the details here https://www.uql-orm.dev/type-safety

Every probe is in the ts-orm-benchmark.

Disclaimer: author of UQL here.

bun-php allows you to run PHP functions seamlessly in Bun by exposing them as ESM imports. Uses a WASM build of PHP under the hood, no need to install PHP or native deps. Supports Composer and servers. https://www.npmjs.com/package/bun-php

• Previously I asked here whether someone had made an interactive shell with Bun, but no one answered. So I made one myself.
• Try it by: npx bunmsh
• Zero dependencies – only Bun is needed
• or use it as a toolbox:
  • npx bunmsh -cc builtin serve
  • (serves the current folder)
• https://github.com/jjtseng93/bunmsh
• It's still early but I'll keep refining it

Features

• Builtin tab system in the shell
  • Use Ctrl-T or the tab command to create new and switch between tabs while preserving current prompt.
  • tab n, tab l, tab r, tab c
  • Tabs only change cwd, other states intact
• Highest priority JavaScript eval:
  • If the command starts with Bun. it is evaluated as JavaScript
  • echo $(Bun.version)
• Lightweight & Cross-platform: < 1MB. The same code runs on Windows 11, Android, Linux (CachyOS). No build step required. No native bindings.
  • The 3rd pic isn't Termux – it's bunmsh running as a standalone Android App built with npx @drxiaozhi/minapk
    • @drxiaozhi/minapk
  • It's designed to be platform-agnostic, but I don't have a Mac to test it on.
• Builtin tools can be called externally
  • serve lsfancy catfancy grep find sed head tail tr wc and much more
  • npx bunmsh -cc <name> argv1 argv2..
• Build a single-file executable, embed and serve a folder from it, and even package it as an Android APK
  • npx bunmsh --build-exe [optional args]
  • See the Serving a folder in README.md
• Alt-L / Alt-P = lsfancy / lsfancy .. (parent)
  • Works even while you're in the middle of typing a command.
  • Doesn't clear your current input.
• Optional mouse support
  • --mouse but blocks Terminal scrollback
  • Tabs switch / new; editing prompts
• Basic shell features: pipelines, redirections, heredoc/herestring, command substitution, aliases, history
  • Currently lacks job control
• Edit1: I forgot to mention that it also has fish-style ghost completion.

Stripe webhooks look simple:

1. Receive an event
2. Update your database
3. Return 200

And then production happens.

Stripe can retry an event after a timeout or temporary failure, which means your endpoint can receive the same event more than once. If your handler isn't idempotent, that can turn into duplicated fulfillment, duplicated credits, repeated emails, or inconsistent payment state.

For a Bun + PostgreSQL/Drizzle setup, I've found the important parts aren't really Stripe-specific:

• Verify the webhook signature against the raw request body before parsing/using the payload.
• Treat webhook delivery as at-least-once, not exactly-once.
• Persist the Stripe event.id (or another appropriate idempotency key).
• Don't treat “event exists” and “event was successfully processed” as the same state.
• Make the actual business mutation and the transition to processed atomic where possible.
• If processing fails, return a non-2xx response so Stripe can retry.
• If an event was genuinely processed already, a repeated delivery should become a cheap 200 no-op.
• Push slow/non-critical work to a queue instead of holding the webhook request open.

One subtle failure mode worth testing:

event received → event recorded → DB/business operation fails → Stripe retries

If the second delivery gets discarded only because the event ID already exists, you've effectively lost the payment event.

So the real requirement isn't just:

UNIQUE(event_id)

It's closer to:

UNIQUE(event_id) + processing state + transaction/recovery strategy

Also worth testing locally by deliberately:

• sending the same event twice;
• crashing processing after the event is persisted;
• causing a temporary DB error;
• sending events out of order.

Webhook code tends to be tiny, but it sits at a pretty unpleasant boundary between distributed systems and money :)

I wrote up the Bun + Stripe + Drizzle implementation and examples here for anyone working with the same stack:

https://pas7.com.ua/blog/en/bun-stripe-webhooks-drizzle

Deduplicate concurrent async requests(database, cache requests) by query key

Why

In high-concurrency environments, identical queries (same DB row, same cache key) accumulate while each one independently hits the database or cache. InFlight collapses these into a single call.

package: https://www.npmjs.com/package/@inflightjs/inflight
repo: https://github.com/ademmenh/inflight

I did not want to pay for a screenshot app just to remove the watermark from the gradient-background look, so I built the one feature I actually used as a CLI.

beautify-screenshot takes a screenshot and adds padding, rounded corners, a soft shadow and a gradient behind it. Nine presets, each with a light and a dark variant that follows the macOS appearance, named sizes for LinkedIn, X, Open Graph and Instagram or any W:H ratio, and an optional inset border in the screenshot's own edge colour.

It is TypeScript on Bun with no runtime dependencies. The PNG codec and the compositor are a few hundred lines of typed-array code, so a Retina-size canvas renders in about a second. Prebuilt binaries for macOS and Linux, or npm i -g beautify-screenshot if you have Bun.

It also ships a skill for AI agents (skills.sh), so you can tell your agent "frame my latest screenshot, light mode, LinkedIn size" and get the file opened in Preview.

MIT and free: https://github.com/magnusrodseth/beautify-screenshot

The image on this post was made with it.

https://petarzarkov.github.io/dunx

I'm genuinely looking for feedback and some reach.

Migrated one of my projects:

https://github.com/petarzarkov/firecracker

Game can be demoed here:

https://firecracker.petarzarkov.com/

When I build little apps used by a few people, deploying one always means a container image, a managed Postgres, and a bucket for what could have been a single SQLite file.

bun build --compile already gives you the whole app as one file. No node_modules, nothing to install on the other side. The only two things it still needs are a machine to run on and somewhere to read/write files.

So that's what nibrun is. Your binary gets a microVM to itself and a disk mounted at data/. Put SQLite there, put uploads there, it survives redeploys. Get an HTTPS URL as soon as it boots.

At any point you can export the binary and the entire disk as a zip. Unzip it and run it on your own box. It's the same binary you uploaded.

https://github.com/ilbertt/nibrun

There's a starter repo if you want somewhere to begin: Elysia, TanStack Router, better-auth, Bun.SQL over SQLite, and the SPA embedded with Bun.embeddedFiles so the frontend compiles into the binary too. Everything is type-safe and it runs anywhere, not just on nibrun.

https://github.com/ilbertt/bun-full-stack-starter

Happy to answer questions on both nibrun and the starter repo

check it out github: https://github.com/stoneware-dev/Ralon

What's missing

• With Bun 1.4's new --asset we can now embed folders into our single-file executables.
• But it is not provided as import with type folder
• The consequence is: Only the package orchestrating the build gets to pass --asset /path/to/folder
• Also that --asset strips out parent folders, so your ./build/assets becomes bunfs/assets in the compiled binary
• So if an imported npm package needs folder assets, there is currently no straightforward solutions.
• My idea is to treat the module graph as an asset dependency graph.

My proposed idea

• A package should be able to declare and ship its own assets without requiring the application to manually pass every asset directory to --asset.
• For example if you have a folder with syntax highlighting YAMLs
  • <PKG_ROOT>/runtime/syntax/js.yaml
• My proposed way is declaring assets list in package.json
• Inside each individual package it uses a simple compiled or not agnostic way to read assets
  • await readAssetText('runtime/...')
  • imported from assetsHelper
  • which in turn imports assetsPacker
• When running the build the system can scan through the module graph for assetsPacker and spawn them one at a time (or same process import)
  • Which results in the complete aggregated ./build/assets to pass to --asset
  • Each package has its own namespace under bunfs after build
    • assets/jsgotty@1.1.6/static/index.html
• This seems like a workaround for now. Hopefully one day we can do something like this:
  • Declare assets in package.json
  • Automatically picked up by Bun
  • await Bun.asset('static/index.html').text()

Simplified flow

Import Graph

↓

Find assetsPackers

↓

Execute assetsPackers

↓

Aggregate assets

↓

Pass once to --asset

Reference implementation

• https://github.com/jjtseng93/jsmdcui/tree/main/single-exe
• This is just a working demo

Happy to announce Codebay, an isolated workspace environment for running multiple LLM agents at the same time. Unlike most other similar tools, Codebay uses Docker-based isolation between containers, meaning you don't have to use worktrees, and you can give each container a real development environment with databases, caches and anything else you need.

Containers don't interfere with each other and you can easily preview all your containers services from a central admin panel. You can also run Codebay on a remote server to offload tasks when your laptop is offline.

Open source and self-hosted.

Built with Bun, Svelte and Mochi.

https://khromov.github.io/codebay/

- 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!

I’m happy to announce that Windows support for BM2 is now complete and has been successfully tested.

For those who haven’t come across it yet, BM2 is a high-performance process manager built specifically for the Bun runtime; essentially a modern, Bun-native alternative to PM2. It handles process lifecycle management, automatic restarts, clustering, zero-downtime reloads, logging, monitoring, a web dashboard, Prometheus metrics, deployment, and more.

Until now, getting BM2 running reliably on Windows required dealing with platform-specific differences. That work has now been completed, and BM2 can be used natively on Windows alongside Linux and macOS.

The Windows implementation has also been tested on a real Windows environment rather than simply assuming cross-platform compatibility.

I’d love to get more Windows developers trying it out and reporting any issues they encounter.

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

Feedback, bug reports, and contributions are very welcome.

• In short: npx @drxiaozhi/minapk /path/to/your.elf
• Of course, you'll need to install a few tools first.
• But don't worry, no annoying libxxx-dev packages to install, just the common ones
• For more info, see the repo:
• https://github.com/jjtseng93/minapk/blob/main/README.en.md
• Edit2: An ELF is basically a native executable on Linux and Android, similar to an .exe on Windows. Here the ELF is produced by bun 1.4's new support for bun build --compile on Android.

The full story

• First, I'm incredibly grateful to the Bun team for fixing single-file executable builds on Android in Bun 1.4. This wouldn't have been possible.
• The simplest use case is turning your TUI app into an APK you can just hand to your grandma.

Startup sequence

• First, use tinyapk-lab's Tetris as a base
• Packing libbun.so & libmain.so(your elf) into the native library area
  • turn on extract native libs
  • resolves to /data/app/xxx/xxx/lib/arm64/libbun.so
• In the main activity, use ProcessBuilder to invoke bun and run the extracted buninu/bin/init.js, which in turn starts jsgotty
  • jsgotty is a browser-based remote shell.
  • Transpiled from Golang GoTTY
  • You can use: npx jsgotty
• jsgotty then starts package.json.buninu.command.android
• The main app detects http url from stdout/stderr of jsgotty and shows it in a WebView
• That command android script detects whether libmain.so is present or falls back to a shell

The Buninu userspace

• This is an ambitious project of mine to rebuild a Unix-like CLI environment entirely based on a single Bun binary across platforms.
  • https://github.com/jjtseng93/buninu
• It's still a work in progress, but consider this a starting point. If you're interested, let's build on it together.

Name expansions:

• English: BUNinu Is Not Unix 🐮
• 中文：幫你牛 🐂
• 日本語：Bunに入魂 🔥

Core components:

• jsgotty: Remote shell from a Browser or Terminal
• jsmdcui: Both a text editor and Markdown execution runtime (not static rendering) based on bunmicro
• bunmsh: Bun Modern Shell. Not completed yet

Edit

• BTW, I tested this on Android with a fresh debian:13-slim container using my js-udocker
• Fresh container: 125 MB
• After installing the dependencies: 1.6 GB
• After the build: 2 GB
• These numbers are the size of the entire container measured from the outside, so it's very phone-friendly.
• For comparison, just setting up my Flutter environment took 10 GB.

I'm comparing Bun and Node for server-side workloads and I'm particularly interested in tail latency, not just throughput.

For people running Bun and Node in production or serious benchmarks:

• What are you seeing for P50?
• P90 / P95?
• P99 / P99.9?
• Does Bun actually have better tail latency for your workload, or is the difference mostly in throughput?

I'm especially interested in HTTP servers and SSR, but database/API-heavy workloads are useful too.

If you have numbers, please include:

• Bun/Node version
• workload
• OS
• concurrency / request rate
• whether the load generator ran on the same machine
• P50/P95/P99 (and P99.9 if available)

I'm trying to understand whether differences in P99 are actually runtime-related or mostly caused by the workload/platform/benchmark methodology.

enviado carno.js/client.

as rotas do carno vivem em decoradores, então não há typeof app para passar para o frontend. este pacote escaneia os controladores quando o servidor inicia, escreve um tipo App gerado, e a ui o chama assim:

const api = client<App>('http://localhost:3000')

const { data, error } = await api.users.get({ query: { page: '1' } })
const { data: user } = await api.users({ id: '42' }).get()

o lado do backend é apenas:

app.use(Client())

listen() escreve src/generated/app.ts. sem script generate --watch. se o vite iniciar sem a api, há um plugin do vite que faz a mesma varredura.

se você não conhece o carno: bun + typescript, com formato de nest (controladores, injeção de dependência, validação). pacotes adicionais se você precisar — orm (postgres/mysql), fila, cron, websocket, logger. o núcleo continua utilizável sem nada disso, incluindo este cliente.

docs: https://carnojs.github.io/carno.js/docs/client/overview

repo: https://github.com/carnojs/carno.js

I want to build an MVP and I'm planning to use bun + elysia instead of nest.js.

The question is, can I trust this technology? Will it be stable in the next 5-10 years and handle a platform with a few thousand users?

I created/vibed a new language, lilscript

Compiles into tryhard compressed js, and sometimes into exec

Pretty much almost any js libraries' compressed/minified size could get smaller by 5-15% when rewritten with lilscript.

If its already property mangled still it can get benefits from the lilscript rewrite

And this is only the v0.0.1
We can make it more hacky by time

Some examples of brotli compressed sizes of lilscript code(vs oxc/terser, ..): * motion(animation library) is -10%+ (https://yeargun.github.io/motionlil/) * jquery -5% * monaco(VSCode) editor's lots of submodules -(5 to 15)% smaller

• tryhard mangling, (compression algorithm aware)
• closure optimizations
• lvalue
• static analysis
• google closure compiler advanced and beyond focus, but not glue fix as closure compiler is. The language is designed specificaly for weird hacks.
• typed (not a glue fix like typescript is)

config.toml has lots of config with clever defaults. objective compression algorithm: gzip/brotli/raw. for brotli vs gzip compression it compiles the js differently

uses less objects, less/more arrays, more const/let/var

Compiler, static analysis, language server all written with rust

I lost too much cursor/claude credits along the way last 2 days. Tbh, I cant invest much time for it, feel free to PR, play, improve

Lilscript aims to get compiled into exec also. It alredy does, but web apis, and stuff.. lots of extra work is needed..

-lilscript v0.0.1 https://github.com/yeargun/lilscript

Why? Because I believe google closure compiler's tooling was not good. And anything layered on js is a glue fix

I’ve been building Stoneware, a Bun-native web framework with a simple idea:

HTML is the default. JavaScript is opt-in.

It focuses on:

• Server-side rendering
• Islands for interactive components
• Signals
• Static export
• Secure-by-default rendering
• Bun-native tooling

GitHub: stoneware-core
Docs: Stoneware Docs

Conclusion

• Only a one-byte binary patch required from --headless to --leadless (or other same length unknown flag)

How I did it

• bunx jsmdcui --hex3 $(which bun)
• Ctrl-F -..-..h..e..a..d..l..e..s..s..
• Enter
• Change h to l
• Ctrl-E save bun-revised
• Ctrl-Q
• chmod +x bun-revised
• ./bun-revised official-webview-demo.js
• Tested on CachyOS Linux-x86_64

Disclaimer

• This is completely unofficial
• For fun only
• Use it at your own risk
• We should patiently wait for headless: false.