Rocketflare: a multi-tenant SaaS starter kit for Cloudflare Workers (and why I built it)

Every internal tool or B2B product I have started in the last couple of years has begun the same way. Tenancy, sign-in, roles, an admin area, a jobs queue, file storage, some dashboards - and lately an AI layer and a CLI on top. None of it is the product. All of it has to exist before the product can.

It came out of two internal apps: one had the structure, auth, tenancy and AI layer, the other the Cloudflare plumbing and analytics. I pulled the two together into one kit and wrote down why each piece is the way it is. Here is Rocketflare.

What it is

One repository that runs as a single Cloudflare Worker over Postgres, with a React UI, a CLI, and a shared contract package that keeps all three in agreement. You copy it, cut it loose from its history, rename it, and start on your first real feature. It is MIT licensed and there is nothing to merge back.

Terminal window
git clone https://github.com/rocketflare-dev/rocketflare.git myapp && cd myapp
rm -rf .git && git init
corepack enable && pnpm install
pnpm dev:db:up && pnpm db:migrate && pnpm seed
pnpm dev

The first run needs no API keys. Magic links are printed to the console, and chat, agents and embeddings fall back to Workers AI through the binding.

The sign-in page, with the seeded dev accounts available on a local run

What you get

  • Tenancy and access - multi- or single-tenant from one schema, owner / admin / member roles, invitations, an audit log and an admin area.
  • Auth - magic link, Google and Microsoft OAuth, tenant API keys.
  • Background work and realtime - a typed jobs queue, durable Workflows, cron, and one Durable Object per tenant that nudges the UI to re-query.
  • AI layer - streamed chat, agents on Workflows, hybrid retrieval over pgvector, and a usage ledger.
  • Analytics - a tenant-scoped semantic layer built on drizzle-cube, my other open source project, with dashboards and an MCP endpoint for free.

Agents running on Cloudflare Workflows, with a durable run history

The other reason

Most of the code I write from here on will be written with a coding agent in the loop, and that changes what a good starting point looks like. An agent arrives with an empty head and acts on what it reads. Whatever you did not write down, it will invent - plausibly, consistently, and wrong.

So the conventions are files placed where the agent will read them - a root CLAUDE.md, rules that load by path, a guide in every significant directory, a decision record per subsystem - and each one that matters is backed by a test that fails when it is ignored. If you have read my recent posts on harness engineering you will recognise the idea. This is the same thing applied to the codebase itself.

The organisation overview dashboard from the drizzle-cube semantic layer

Caveats

It is brand new, so expect rough edges. Running it locally needs a free Cloudflare account for the Workers AI binding, or you comment that binding out. Deploying for real needs a Workers Paid plan, because Hyperdrive and Workflows do. Billing and any actual product domain are deliberately not included.

Site and concept write-ups: rocketflare.dev

The code (MIT licensed): GitHub Repository