Skip to content
Flare

Flare

A batteries-included, generator-driven fullstack framework for Cloudflare Workers — auth, database, storage, mail, and an admin dashboard, wired together and ready in minutes.
QuickstartWhy Flare?

The five-minute loop

Section titled “The five-minute loop”
Terminal window
npx @flare/cli create myapp
cd myapp
npx flare gen resource Contact --fields "name:string, email:string"
npx flare deploy

That’s a live, authenticated CRUD app on Cloudflare Workers with a working admin dashboard — no hand-wired D1 bindings, no auth library to pick, no admin UI to build by hand.

Flare’s packages aren’t published to npm yet; until they are, run the CLI from a checkout of the repo.

Why Flare

Section titled “Why Flare”

Building a fullstack CRUD app on Cloudflare today means hand-wiring D1 bindings, picking an auth library, writing an admin UI from scratch, and gluing together R2, KV, and Durable Objects yourself — every time, for every project. Rails, Laravel, and Filament solved this decades ago for their ecosystems. Flare solves it for the Cloudflare edge.

One resource, everything generated

A single <resource>.resource.ts descriptor drives the Drizzle schema, migration, Zod validators, REST API, typed client, and the admin list/create/edit pages — all regenerated in place as the descriptor changes.

Batteries included

D1 + Drizzle, Better Auth (email/password and OAuth), R2 file storage, Resend email, a KV data cache, and realtime channels on Durable Objects — wired on flare create, not left for you to assemble.

A real admin dashboard

Filament-style: <ResourceTable>, <ResourceForm>, and <ResourceNav> read resource metadata at runtime. Editing a field’s label or validation doesn’t require touching the UI.

Roles and policies enforced twice

flare gen policy writes a resource-level policy that the API and the admin UI both enforce server-side — never UI-only.

Where to go next

Section titled “Where to go next”