Full-stack TypeScript · One Cloudflare Worker

One runtime for your server, your site, and your service worker

Compose your platform from typed modules and ship all of it as a single Worker. One repo. One deploy.

Registration & sign-in OAuth One-time passcodes Sessions & JWTs Account recovery Per-user storage KV caches R2 buckets D1 databases Queues

Transactional email Web push Scheduled routines Traffic & audits Insights API Admin screens i18n Sitemaps & SEO Offline rendering Install prompts

Get started

bun firebrand/cli/build.ts --link
firebrand setup
firebrand deploy --skip-build

The server

import { useFirebrand } from 'firebrand'
import { core } from 'firebrand/core/api'
import { stripe } from
  'firebrand/modules/stripe/api'
import { cloudflare } from
  'firebrand/modules/cloudflare/api'

export default {
  async fetch(request, env, ctx) {
    const firebrand = useFirebrand(
      'api', [core, cloudflare, stripe], { env }
    )
    const server = useServer(firebrand)
    return server.fetch(request, env, ctx)
  }
}

An endpoint

makeSignal('api', '/ping', {
  middleware: [],
  handler: async (firebrand) => {
    const { responses } = firebrand.helpers
    return responses.json({ ok: true })
  }
})

A page

makeView({
  name: 'PricingView',
  tag: 'pricing-view',
  pathname: '/pricing',
  template,
  style,
  logic,
  layouts: ['site-layout']
})

How it works

Write a module once. It runs in three places.

A module bundles its routes, pages, elements, jobs and helpers. Register it once and every runtime it targets picks up its part — there is no second project to keep in step.

Core

A whole platform, before you write a line

Core is not a starter template you grow out of. It is the base module every Firebrand app is composed on, and it arrives with the parts you would otherwise be buying, wiring and keeping current.

The alternative

What you would otherwise be assembling

Nothing here is impossible without Firebrand. It is the assembling, the invoices and the version drift that the modular monolith is a bet against.

Quickstart

From cold start to fully lit

Three commands. The CLI resolves the project root by walking up from wherever you run it, so each one works from anywhere in the tree.

Straight answers

Before you commit a project to it

Request access

Tell me what you are building

Whether it is a project you want built on Firebrand or a question about whether it fits, write and I will answer.

Follow the build

Release notes from the person writing it

New modules, release notes and the occasional post-mortem. No more than monthly.

Ship the whole thing this week

Start from a platform that already has auth, storage, notifications, tests and a deploy pipeline, and spend the week on the part only you can build.

Request access