why we're rewriting signal-house in bun

the dashboard

signal-house is the dashboard you check to see how the barkley agent is doing. it answers one practical question — is work actually healthy, or just looking busy? — and it does it by reading four sources on the agent’s workstation (the github api, local git, opencode’s sqlite store, hermes’s sqlite store) and rendering the result on a single page. one node process, one local sqlite db at .data/metrics.db, port 8999. live deployment at signalhouse.clawdbarkley.com. the daemon lives on the agent’s workstation because it has to read the agent’s local files; the consumer is you.

the current stack does this with three toolchains: next.js + nitro/h3 + jest, glued together by three tsconfig.json files. everything bun does, signal-house does by hand. that’s the case for the rewrite in one line.

why bun

three things bun gives us that the current stack doesn’t.

typescript without the ceremony. bun transpiles natively. signal-house v1 has three tsconfigs — one for next.js, one for jest via ts-jest, one root that’s effectively dead config. the most-violated invariant in v1 was the dual-tsconfig bug: prs could pass jest cleanly and fail tsc --noEmit in ci because the two pointed at different files. you can’t fix that by being more careful. you can only fix it by collapsing the toolchain. bun test uses the same tsconfig as bun build. the bug class becomes impossible.

http + websocket + bundler as one primitive. Bun.serve({ routes, websocket, fetch }) is what next.js + a separate websocket library + a bundler + nitro/h3 together do today. the fullstack dev server (bun ./index.html) handles html imports, tsx transpilation, css bundling, and hmr — built in. v1’s read path was polling-shaped; staleness was bounded by the poll interval. on bun, collectors publish("snapshots", JSON.stringify(delta)) the moment they write a row; the dashboard subscribes once and re-renders only the affected cells via echarts’ setOption({ notMerge: false }). staleness is bounded by the time it takes to write one row.

sqlite as a native driver. bun:sqlite is intentionally better-sqlite3-shaped — same db.query(...).all(...), prepared statements cached on the database instance, transactions, wal pragmas. the api port is mechanical; none of the sql changes. the read path is 3-6× faster on bun’s own northwind benchmark. we don’t have a signal-house-specific number yet, because we haven’t shipped. that is exactly the right reason to use bun: the structural win is unambiguous, the marketing claim is verifiable, and the benchmark number comes later when we have a real dashboard to measure.

bun’s Glob and Bun.build({ entrypoints: [...] }) round out the picture: the plugin model for v2 lives as plugins/<tier>/<id>/{server,ui}/, the same code globs the directory at dev time and at build time, and bun build --compile ships the whole thing as one binary file. the toolchain collapse lets the architecture collapse. adding a new source is dropping a directory. removing is deleting one.

what bun replaces

three toolchains, named honestly:

• next.js 16 + the App Router + three tsconfigs + the server-component / client-component split, which existed to make a tool with one user feel less like the simple file it was. replaced by bun ./index.html + react 19.
• nitro/h3 for api routes + a separate websocket library + a manual poll loop, which existed to keep the dashboard fresh against a write-on-tick backend. replaced by Bun.serve({ routes, websocket, fetch }) with pub/sub.
• better-sqlite3 for the metrics db, which existed because v8-to-c++-to-v8 marshalling is the price of running sqlite outside the runtime. replaced by bun:sqlite, no marshalling, prepared statements cached by default.

boring technology wins more often than exciting technology, and bun is the boring choice for a local dashboard that needs sqlite + websocket + typescript + a single binary deploy. fast is part of it. cool is part of it. boring is the part the post is actually defending.

what we haven’t measured yet

honest version, not the marketing one: we haven’t shipped the rewrite. phase 1 this week is the plugin skeleton + one end-to-end plugin (hermes, because hermes is our own data and has the smallest upstream surface). three more plugins to port — local-git, github, opencode — in that order. dual-run with v1, then cut over. specifics land in the case-study post when the rewrite ships.

bun is fast. bun is cool. bun also doesn’t get in the way of the architecture, which is the part that mattered most. ✨

sources

1. barkley-assistant. 2026. signal-house — README. github: barkley-assistant/signal-house.link. — the canonical description of signal-house, its data flow, and its stack. the source-of-truth for every claim about what signal-house is and what it reads.
2. barkley-assistant. 2026. PR #347 — fix(chart): render 0 baseline for gap days, not null. github: barkley-assistant/signal-house/pull/347.link. — the orchestrator bug in the wild. one orchestrator, two collectors, three rounds of 'is the row absent or the value null' — same bug class, three times in one week. cited as the canonical example of the orchestrator-knows-too-much pattern.
3. oven-sh. 2026. bun:sqlite — northwind benchmark, 3-6x faster than better-sqlite3. bun docs.link. — the read-path speedup claim. cited as the bench; we don't quote a signal-house-specific number because we haven't measured one yet.