¿Y si un solo proceso pudiera alojar toda una flota de aplicaciones sin que ninguna de ellas pudiera derribar a las demás? Buntime es un runtime Bun modular, desarrollado en Zomme, en el que un proceso orquesta varias aplicaciones aisladas — cada una en su propio worker Bun, con su propio heap y caché de módulos. Un fallo sigue siendo solo un fallo: nunca se propaga al runtime.
El problema que resuelve
Ejecutar muchas aplicaciones pequeñas suele forzar una mala decisión. Júntalas todas en un proceso y una sola petición defectuosa contamina a todas; sepáralas en servidores distintos y pagas por capacidad ociosa, enrutamiento duplicado y complejidad operativa. Buntime mantiene la densidad de un solo proceso y el aislamiento de radio de impacto de servidores separados: los workers se reutilizan mediante una caché LRU mientras el tráfico está caliente, o se ejecutan de forma efímera por petición cuando quieres un comportamiento serverless, con escalado a cero. Obtienes aislamiento sin el coste de un servidor por aplicación.
Una plataforma hecha de plugins
flowchart LR in([Request]) --> onreq["onRequest hooks"] onreq --> worker["App worker"] worker --> onres["onResponse hooks"] onres --> out([Response])
Casi todo lo que hace Buntime es un plugin, y los plugins se descubren
automáticamente — basta con añadir uno y se conecta solo. Cada plugin recibe el
ciclo de vida completo de la petición mediante los hooks onInit / onRequest
/ onResponse / onShutdown, puede publicar capacidades en un registro de
servicios compartido, declarar el orden de dependencias, hacer hot reload en el
sitio y ejecutarse en modo persistente o serverless. El conjunto que ya viene
incluido cubre lo que una plataforma de verdad necesita: gateway, proxy,
deployments, vhosts, autenticación (OIDC/JWT), autorización (XACML), logs,
métricas, CORS, rate limiting, key-value y SQL.
Un shell para varias interfaces
Buntime incluye un shell de micro-frontends construido sobre
Frame (@zomme/frame) que aloja tanto las
interfaces del operador como las de las aplicaciones — cualquier app con
entrypoint HTML — como iframes, inyectando el base path correcto para que las
SPAs simplemente funcionen detrás del shell. En el día a día, lo controlas todo
desde un panel de control web (CPanel): una SPA del operador en React +
TanStack Router para gestionar workers, plugins y claves de API.
Componentes
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 — el pool de workers, enrutamiento multicapa, API REST y descubrimiento de servicios.
- CPanel — la SPA del operador para workers, plugins y claves de API.
- Plugins — el conjunto de capacidades descubiertas automáticamente, desde gateway y autenticación hasta logs y rate limiting.
- Datos —
@buntime/keyval(un store similar a Deno KV), Turso/libSQL y una capa de base de datos con múltiples adaptadores. - Operaciones — Helm charts, imágenes Docker, versionado dual y flujos de release en CI.
Sobre el runtime se asienta una plataforma multi-tenant de referencia: una implementación funcional con aprovisionamiento self-service y gestión de base de datos por tenant, que muestra cómo convertir Buntime en un producto real.
Stack
Bun, Hono, TypeScript, Biome y Playwright, con paquetes compartidos publicados
en npm (@zomme/bun-plugin-*) y en JSR (@buntime/shared). Se ejecuta en
Kubernetes, desplegado mediante Helm.
Disponibilidad
- Sitio: buntime.djalmajr.dev
- Código: github.com/djalmajr/buntime
- Relacionado: Frame — el shell de micro-frontends sobre el que se construye
Source-available bajo la licencia O’Saasy.