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.

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

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

Bindings

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

Testing

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

Deploys

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

Composition

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

Frameworks

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

Pick the job in front of you, open the shortest working path, then follow the deeper reference only when you need it.

A route-tree path you can copy after the first worker runs

One config, one request-wide handler, one route leaf, and one test that exercises the route through the worker.

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'notes-api',

compatibilityDate: '2026-03-17',

files: {

fetch: 'src/fetch.ts',

routes: {

dir: 'src/routes',

prefix: '/api'

}

})