What is Blaze? Express-style Framework for CF Workers

Learn what Blaze is and why it exists: an Express-compatible, zero-dependency web framework built natively for Cloudflare Workers.

Blaze is a lightweight, Express-style web framework purpose-built for Cloudflare Workers. It combines the familiar (req, res, next) middleware convention, Router, and route chaining that Express developers already know with first-class support for every Cloudflare primitive — KV, D1, R2, Durable Objects, Queues, and Workers AI. If you’re building APIs or backend services on Cloudflare Workers and want a framework that feels immediately familiar without forcing you to learn a new programming model, Blaze is designed for you.

Why Blaze?

Blaze makes deliberate tradeoffs that separate it from the alternatives. The table below compares Blaze against Hono (the most popular CF-native framework) and Express (the most popular Node.js framework):

Feature	Blaze	Hono	Express
Middleware signature	(req, res, next) — Express compatible	async (c, next) — custom Context	(req, res, next) — Node.js only
Bindings access	req.env.KV — on the request object	c.env.KV — on the context wrapper	Not applicable (Node.js)
Error handling	4-arg (err, req, res, next) — Express convention	app.onError((err, c)) — custom API	4-arg (err, req, res, next)
Bundle size	~11 KB minified + gzip	~14 KB gzip (tiny preset)	~572 KB (Node.js, not CF-compatible)
Express middleware compat	✅ Full — same (req, res, next) arity	❌ None — different signatures	✅ Native

Unlike Hono, which wraps everything in a custom Context object (c), Blaze enriches the standard Web Platform Request and Response objects and injects Cloudflare bindings directly onto a typed env object on the request. The result is that existing Express knowledge transfers directly, and middleware packages that follow the (req, res, next) convention work without modification.

Design goals

Blaze is guided by seven design goals that inform every architectural decision:

• Express parity — app.get / post / use / Router() feel identical to Express. The middleware signature is (req, res, next) throughout.
• CF-native bindings — env and ctx are promoted to first-class properties on the request: req.env.KV, req.env.DB, req.ctx.waitUntil().
• Zero dependencies — the core ships with no npm runtime dependencies. The TrieRouter, middleware compose, and response helpers are all hand-rolled.
• Full TypeScript — the Env generic on createApp<Env>() propagates type information through the entire application. Every req.env property is type-safe with zero casting.
• Performance — a hand-rolled TrieRouter provides O(log n) matching and a bundle size of ~11 KB gzip, smaller than Hono at an equivalent feature set.
• Testability — app.fetch(req, env, ctx) is the single test seam. You pass a mocked env in unit tests without needing a Worker runtime.
• Composability — sub-routers, middleware-level error boundaries, and per-route middleware stacks compose cleanly via the Layer abstraction.

When to use Blaze

You’re already an Express developer. Blaze’s (req, res, next) middleware signature, Router, and route chaining are intentionally identical to Express. You can transfer your knowledge directly and reuse compatible middleware packages without wrapping or adapting them.

You want the req.env.KV access pattern. Blaze places Cloudflare bindings directly on the request object rather than on a separate context wrapper. Any function that receives req can access req.env.KV, req.env.DB, or req.env.AI — no prop-drilling, no context imports.

You want Express middleware compatibility. If you rely on existing Express middleware packages (body parsers, validators, auth libraries), Blaze’s identical middleware arity means those packages work without modification. Hono’s async (c, next) signature is incompatible with the Express ecosystem.

Get Started in 5 Minutes

Build your first Blaze Worker →