efforge

The problem

Starting a new Effect project on Cloudflare means making the same dozen decisions every time: which database and ORM, how auth plugs in, how Worker bindings reach application code, and how to keep all of it testable. Existing starters cover parts of this. create-effect-app gives you an Effect project, and npm create cloudflare gives you a TanStack Start app on Workers, but nothing wires the whole server side in Effect.

What it does

npm create efforge generates a TypeScript monorepo with a TanStack Start app on Cloudflare Workers. You choose the database, ORM, auth, infrastructure tool, AI, and extras up front, and efforge add adds more later.

npm create efforge my-app -- --database=d1 --orm=effect-sql --auth=better-auth

Architecture

• Each capability (database, auth, mail, storage, AI) is an Effect service with tagged errors in packages/core, implemented as a layer and composed in one file.
• Only apps/web/src/server/cloudflare.ts reads the Worker environment. Everything else receives bindings through layers, so code that uses them can be tested with @effect/vitest.
• efforge add edits the generated project with AST transforms, wiring a new add-on into the layers, exports, bindings, and secrets instead of asking you to paste code.

Decisions and trade-offs

• Narrow on purpose. efforge is for writing the whole server side in Effect, on Cloudflare. If you want Next.js, another runtime, or plain async code, a different starter is a better fit.
• Agent-ready output. The generated project includes an AGENTS.md with the same layout and rules, and pnpm check runs formatting, linting with Effect diagnostics, and type checking.
• Early dependencies. The default ORM is pinned to a release candidate and the optional Alchemy support uses a beta. That is a deliberate choice for an early project and a cost for anyone adopting it today.

Status

Version 0.1, early, and MIT licensed.