Buntime

Buntime is a modular runtime for Bun. A single main process accepts every request and routes it, but it never runs your application code itself — that work is isolated in a pool of Bun workers. Around that core sits a plugin system that intercepts requests, registers routes, and exposes UI in a micro-frontend shell.

Isolated worker pool

Each app runs in its own Bun worker — separate heap, module cache, and environment. A crash never takes the runtime down. Workers are reused via an LRU cache, or run ephemerally per request (serverless-style).

Plugin system

Auto-discovered plugins add CORS, rate limiting, key-value storage, durable SQL, proxying, logging, and metrics — loaded in dependency order, with hot reload and no process restart.

Micro-frontend shell

Plugins and apps that ship an HTML entrypoint are exposed as iframes in a framework-agnostic shell via @zomme/frame, with base-path injection so SPAs work under any subpath.

Multi-tenant ready

A reference platform serves many hosts from one runtime — a Keycloak realm per host, per-tenant Turso databases, and self-service provisioning.

Start exploring

Introduction What Buntime is, the problem it solves, and the mental model.

Getting started Run the runtime locally and deploy your first worker.

Core concepts The runtime, the worker pool, and the plugin system in depth.

Write a plugin Persistent vs serverless plugins, hooks, and the manifest.