Buntime

What if a single process could host a whole fleet of apps without any one of them being able to take the others down? Buntime is a modular Bun runtime, built at Zomme, where one process orchestrates many isolated applications — each in its own Bun worker, with its own heap and module cache. A crash stays a crash: it never spreads to the runtime.

The problem it solves

Running many small apps usually forces a bad trade-off. Pack them into one process and a single bad request can poison everyone; split them into separate servers and you pay for idle capacity, duplicated routing, and operational sprawl. Buntime keeps the density of one process and the blast-radius isolation of separate ones: workers are reused through an LRU cache while traffic is warm, or run ephemerally per request when you want serverless-style, scale-to-zero behaviour. You get isolation without the overhead of one server per app.

A platform built from plugins

flowchart LR
  in([Request]) --> onreq["onRequest hooks"]
  onreq --> worker["App worker"]
  worker --> onres["onResponse hooks"]
  onres --> out([Response])

Almost everything Buntime does is a plugin, and plugins are auto-discovered — drop one in and it wires itself up. Each gets the full request lifecycle through onInit / onRequest / onResponse / onShutdown hooks, can publish capabilities to a shared service registry, declare dependency ordering, hot-reload in place, and run in persistent or serverless mode. The bundled set already covers what a real platform needs: gateway, proxy, deployments, vhosts, authentication (OIDC/JWT), authorization (XACML), logs, metrics, CORS, rate limiting, key-value, and SQL.

A shell for many UIs

Buntime ships a micro-frontend shell built on Frame (@zomme/frame) that hosts both operator and application UIs — any app with an HTML entrypoint — as iframes, injecting the right base path so SPAs just work behind the shell. Day-to-day, you drive the whole thing from a web control panel (CPanel): an operator SPA in React + TanStack Router for managing workers, plugins, and API keys.

Components

flowchart TD
  req([Request]) --> main["Main process · Hono router"]
  main --> pool["Worker pool · LRU"]
  pool --> w1["App worker (isolated)"]
  pool --> w2["App worker (isolated)"]
  main --> plugins["Plugins · gateway, authn, proxy …"]
  main --> shell["Micro-frontend shell · Frame"]
  cpanel["CPanel · operator SPA"] --> main

• Runtime — the worker pool, multi-layer routing, REST API, and service discovery.
• CPanel — the operator SPA for workers, plugins, and API keys.
• Plugins — the auto-discovered capability set, from gateway and auth to logs and rate limiting.
• Data — @buntime/keyval (a Deno KV-like store), Turso/libSQL, and a multi-adapter database layer.
• Ops — Helm charts, Docker images, dual versioning, and CI release flows.

On top of the runtime sits a multi-tenant reference platform: a working implementation with self-service provisioning and per-tenant database management, showing how to turn Buntime into an actual product.

Stack

Bun, Hono, TypeScript, Biome, and Playwright, with shared packages published to npm (@zomme/bun-plugin-*) and JSR (@buntime/shared). It runs on Kubernetes, deployed via Helm.

Availability

• Website: buntime.djalmajr.dev
• Source: github.com/djalmajr/buntime
• Related: Frame — the micro-frontend shell it builds on

Source-available under the O’Saasy license.