E se um único processo pudesse hospedar uma frota inteira de aplicações sem que nenhuma delas conseguisse derrubar as outras? O Buntime é um runtime Bun modular, desenvolvido na Zomme, em que um processo orquestra várias aplicações isoladas — cada uma em seu próprio worker Bun, com heap e cache de módulos próprios. Uma falha continua sendo só uma falha: ela nunca se espalha para o runtime.
O problema que ele resolve
Rodar muitas aplicações pequenas costuma forçar uma escolha ruim. Junte todas em um processo e uma única requisição problemática contamina todo mundo; separe em servidores distintos e você paga por capacidade ociosa, roteamento duplicado e complexidade operacional. O Buntime mantém a densidade de um processo só e o isolamento de raio de impacto de servidores separados: os workers são reaproveitados via cache LRU enquanto o tráfego está quente, ou rodam de forma efêmera por requisição quando você quer comportamento serverless, com escala-a-zero. Você ganha isolamento sem o custo de um servidor por aplicação.
Uma plataforma feita de plugins
flowchart LR in([Request]) --> onreq["onRequest hooks"] onreq --> worker["App worker"] worker --> onres["onResponse hooks"] onres --> out([Response])
Quase tudo o que o Buntime faz é um plugin, e os plugins são descobertos
automaticamente — basta adicionar um e ele se conecta sozinho. Cada plugin recebe
o ciclo de vida completo da requisição por meio dos hooks onInit / onRequest
/ onResponse / onShutdown, pode publicar capacidades em um registro de
serviços compartilhado, declarar ordem de dependências, fazer hot reload no lugar
e rodar em modo persistente ou serverless. O conjunto que já vem incluído cobre o
que uma plataforma de verdade precisa: gateway, proxy, deployments, vhosts,
autenticação (OIDC/JWT), autorização (XACML), logs, métricas, CORS, rate limiting,
key-value e SQL.
Um shell para várias interfaces
O Buntime traz um shell de micro-frontends construído sobre o
Frame (@zomme/frame) que hospeda tanto as
interfaces do operador quanto as das aplicações — qualquer app com entrypoint
HTML — como iframes, injetando o base path correto para que SPAs simplesmente
funcionem por trás do shell. No dia a dia, você controla tudo por um painel de
controle web (CPanel): uma SPA do operador em React + TanStack Router para
gerenciar workers, plugins e chaves 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 — o pool de workers, roteamento em múltiplas camadas, API REST e descoberta de serviços.
- CPanel — a SPA do operador para workers, plugins e chaves de API.
- Plugins — o conjunto de capacidades descobertas automaticamente, do gateway e da autenticação aos logs e rate limiting.
- Dados —
@buntime/keyval(um store similar ao Deno KV), Turso/libSQL e uma camada de banco de dados com múltiplos adaptadores. - Operação — Helm charts, imagens Docker, versionamento duplo e fluxos de release em CI.
Sobre o runtime há uma plataforma multi-tenant de referência: uma implementação funcional com provisionamento self-service e gerenciamento de banco de dados por tenant, mostrando como transformar o Buntime em um produto de verdade.
Stack
Bun, Hono, TypeScript, Biome e Playwright, com pacotes compartilhados publicados
no npm (@zomme/bun-plugin-*) e no JSR (@buntime/shared). Roda em Kubernetes,
implantado via Helm.
Disponibilidade
- Site: buntime.djalmajr.dev
- Código: github.com/djalmajr/buntime
- Relacionado: Frame — o shell de micro-frontends sobre o qual ele é construído
Source-available sob a licença O’Saasy.