Zenbu.js

Zenbu.js is an open-source TypeScript framework, built by Y Combinator-backed Zenbu Labs (P2026), for building Electron applications that are designed from the ground up to be hacked, extended, and modified by their own end users — not just their original developers. Instead of compiling and bundling an app into an opaque binary, Zenbu.js ships the raw, uncompiled TypeScript source alongside the packaged app. On first launch, that source is copied into a git-tracked directory on the user’s machine (~/.zenbu/<app-name>), where it is watched, dynamically compiled, and hot-reloaded through Electron’s Node.js runtime — in both the main and renderer processes.

Under the hood, a Zenbu.js app is composed of Service classes that run in the main process, expose their public methods to the renderer automatically over a type-safe RPC layer (the in-house zenrpc package), and read/write a reactive JSON database (kyju) that keeps every connected process in sync. The framework’s most distinctive piece is @zenbu/advice, a custom Babel transform that rewrites every top-level function and binding in a plugin’s source into an indirection table, so third-party plugins can intercept, replace, or “advise” running application code at runtime without restarting the process — the same mechanism that makes the framework’s own hot reload possible is exposed to plugin authors as a first-class extensibility primitive.

Zenbu.js is the underlying engine for Zenbu Labs’ own product, Zenbu, described in the repo as “a highly extensible development environment,” but the framework itself is a general-purpose, standalone way to build any Electron app that wants this level of end-user hackability. The project is openly in alpha (per its own README and status badge) — Electron is the only supported runtime today, with Tauri, plain Node.js, and browser-native targets still marked as work in progress — and its API surface is expected to keep changing.

What You Get

• A Service base class with dependency injection for main-process business logic, auto-exposed to the renderer via type-safe RPC
• A reactive JSON database (kyju) that keeps main, renderer, and any connected replicas in sync, with React hooks (useDb, useCollection) that re-render on change
• Instant hot reload for both processes, including an evaluate()/dispose lifecycle so services re-run cleanly on save without a full app restart
• A Babel-powered advice transform (@zenbu/advice) that lets plugins intercept and replace any top-level function or binding in the app at runtime
• The create-zenbu-app CLI for scaffolding a new project in seconds, plus create-desktop-app for the Electron shell
• Zod-based schema authoring (createSchema) for typed, migratable database schemas

Common Use Cases

• Coding agents generating and customizing bespoke desktop software on demand for a single user’s workflow
• Vendors shipping Electron apps that power users are expected to fork, theme, or extend without waiting on an official plugin API
• Teams building internal tools where different departments need slightly different behavior from the same base app
• Plugin ecosystems where third parties need to patch or extend app behavior live, without the host app pre-defining every extension point

Under The Hood

Architecture Zenbu.js apps are organized around a fundamental unit, the Service class (Service.create({ key })), resolved through a dependency-map style dependency injection, evaluated once, and hot-swappable on save via an evaluate()/dispose lifecycle keyed by reload reason (‘reload’ vs ‘shutdown’). Public service methods are automatically bridged to the renderer process through the in-house zenrpc client/server/transport layers rather than raw Electron IPC, and application state flows through kyju, a reactive JSON database with its own client, replica, and core-plugins layers so every connected process observes the same data. The framework’s most structurally significant piece is @zenbu/advice, a Babel transform that rewrites every top-level binding in application and plugin code into a __def/__ref indirection table; this is the load-bearing abstraction the rest of the system depends on — hot reload, live plugin patching, and the “ship raw source, compile at runtime” model would all collapse without it. The layering (services, RPC, reactive db, React hooks) is clean and consistently applied across the sampled source, though heavy reliance on generated files (registry-generated.ts) and a still-evolving public API mark this as an early-stage, actively-shifting architecture rather than a stabilized one.

Tech Stack The framework is written in TypeScript across a pnpm workspace monorepo, targeting Electron as its only production-ready runtime today (Tauri, plain Node.js, and browser-native are explicitly marked work-in-progress in the README). Application state and schemas are authored with Zod v4 (createSchema), the dev server and HMR pipeline are built on Vite with custom Vite plugins, and library builds are produced with tsdown. The Effect-TS library appears as a shared dependency across several packages for typed, composable main-process logic, isomorphic-git tracks and merges user edits to the on-disk app source, and the plugin-advice mechanism is implemented as a custom Babel plugin rather than an existing AOP or hot-module-replacement library. CLI tooling (create-zenbu-app, create-desktop-app) scaffolds new projects, and a zen CLI binary handles schema migrations and builds.

Code Quality The monorepo contains a meaningful body of colocated Vitest test files across its core packages (runtime, database, RPC, and the Babel advice transform, including a dedicated snapshot suite for the transform’s generated output), indicating real attention to correctness for the trickiest pieces of the system. However, the project’s own CI workflow only runs a type-check job and a custom script that caps the number of @ts-ignore/@ts-expect-error/@ts-nocheck directives allowed in tracked source — it does not appear to execute the test suite automatically, so the existing tests currently function as a local safety net rather than a CI-enforced gate. Naming and file organization are consistent (kebab-case directories, one class or concern per file), and the ts-ignore budget script shows a deliberate, if partial, commitment to type-safety discipline over ad hoc escape hatches.

What Makes It Unique The genuinely unusual choice here is shipping an app’s raw, uncompiled source to end users and dynamically compiling and hot-reloading it on their machine via Electron’s own Node.js runtime, rather than shipping a bundled binary — combined with tracking that on-disk source with git so a user’s local edits can be pulled-and-merged against upstream updates instead of being silently overwritten. Layered on top of that, the advice transform turns ordinary application code into something any plugin can intercept or replace at runtime, without the host app needing to pre-declare a plugin API surface for every extension point. Together these choices treat hackability as a first-class architectural property of the framework rather than a bolt-on plugin system, a distinctly different bet than the sandboxed-extension or fixed-plugin-API models used by most extensible desktop software.

Self-Hosting

Licensing Model MIT licensed — all features available in self-hosted deployments with no restrictions or license keys required.

Self-Hosting Restrictions None found. No ee/, enterprise/, pro/, or cloud/ directories exist in the repository, and no license-gating code (requiresLicense, isPro, isEnterprise, feature-flag checks) was found in the source.

License Key Required No — the framework has no license-key mechanism of any kind.