Devflare documentation

Build Cloudflare apps with less setup drag.

Start with one Worker. Add bindings, testing, previews, and framework support only when the project actually needs them.

Build your first Worker

Need the context first? See why Devflare exists

Worker-first by default Typed env from real config Bindings, testing, and previews when you need them

Starter commands

Three commands to get moving

1 bun add -d devflare

2 bunx --bun devflare types

3 bunx --bun devflare dev

You do not need the whole docs tree on day one. Get a Worker running, generate env types, and add the next capability when the code asks for it.

What Devflare gives you

The library should stand out before the setup lore does.

These are the capabilities most teams reach for first.

Config

Readable config

Author devflare.config.ts for humans and keep generated Wrangler output in the output lane.

Bindings

Typed bindings

Generate env.d.ts, work with KV, D1, R2, Durable Objects, and queues, and keep the runtime surface aligned.

Testing

Runtime-shaped tests

createTestContext() and cf.* let you test the worker you actually ship, not a hand-made imitation.

Deploys

Explicit previews

Separate preview and production on purpose, with names and cleanup paths that are easy to review.

Composition

Worker composition

Use service bindings and ref() when the app grows into more than one worker.

Frameworks

Frameworks when needed

Stay worker-first until the package genuinely needs Vite or SvelteKit around it.

Take action

Pick the next thing you want to do.

These are the fastest useful paths through the docs.

Quickstart

Your first worker

Start with one config file, one fetch handler, and generated types before you branch into routes, bindings, frameworks, or a deeper test setup.

Quickstart

Your first bindings

Take the same starter worker, split it into routes and helpers, then add one binding-backed route at a time so can stay small.

Quickstart

Your first unit test

Take the same starter worker from the previous page and add one request test through so the first check uses the same runtime shape the worker will actually run.

Quickstart

Deploy and Preview

Take the same starter worker and ship one named preview on purpose, then remove that same preview scope cleanly when you are done.