Devflare Docs
Why it helps Quickstart

Why Devflare feels better than stitching Cloudflare Worker workflows together by hand

Devflare gives you one clearer story for config, worker compilation, local development, runtime helpers, testing, and deploy flows so a Worker app can stay small at the start and still stay coherent as it grows.

The goal is not to hide Cloudflare. The goal is to keep authored code split by responsibility, let generated output and Rolldown-backed worker compilation stay in their own lane, and give you a smoother path from one worker to routing, bindings, frameworks, previews, and automation.

Best for
Teams that want Cloudflare power without accumulating setup glue
Architecture shape
Config, runtime, tests, framework integration, and Cloudflare ops stay split on purpose
Build lane
Rolldown composes worker and Durable Object artifacts; Vite stays optional
Still true
Cloudflare limits and Wrangler-compatible output still matter

Why teams reach for Devflare in the first place

Most people do not adopt Devflare because they want more abstraction. They adopt it because raw Worker projects can accumulate too many small decisions in too many places.

Without some structure, config lives in one file, generated artifacts in another, tests invent their own fake runtime, and preview or deploy behavior becomes whichever shell snippet the team last copied forward.

Devflare gives those pieces one authored story: readable config, worker-shaped runtime helpers, generated worker composition, a bridge-backed local loop, and deploy or preview flows that stay explicit instead of magical.

Less glue code

Keep stable intent in authored config instead of scattering worker names, resource ids, and generated file edits across the repo.

Split by responsibility

Config authoring, runtime helpers, tests, framework hooks, and Cloudflare operations live in separate lanes instead of one catch-all surface.

Worker-aware compilation

Author routes, surfaces, and Durable Objects as app code, then let Devflare and Rolldown compose the runtime-facing artifacts.

Cleaner local and framework loop

Use one worker-aware development story that can stay worker-only or plug into Vite and SvelteKit when the package actually needs them.

Tests that resemble production

Reach for the built-in runtime-shaped test harness before custom mocks drift away from how the Worker actually behaves.

Why the codebase stays coherent as the app grows

The implementation is split by environment and lifecycle on purpose so the worker story can grow without collapsing into one giant tool blob.

is for authored config, is for worker code, is for harnesses, and or only join the picture when the package grows into a real app host. That split is one of the package's quiet strengths.

The build and local-dev story stays honest too. Rolldown is the worker builder, generated entrypoints keep worker surfaces explicit, and Vite or SvelteKit can sit outside the worker runtime instead of swallowing it.

Split package surfaces

Different public entrypoints exist because config authoring, runtime code, tests, framework hosting, and Cloudflare operations are different jobs.

Rolldown owns worker artifacts

Worker and Durable Object bundles are composed and validated for Cloudflare compatibility instead of being treated as generic JavaScript output.

Bridge-backed framework dev

When a package uses Vite or SvelteKit, Devflare keeps Miniflare or workerd on one side, the app host on the other, and bridges bindings back into the framework dev server.

Framework endpoints can still reach worker bindings

In local dev, the framework lane can read Cloudflare-shaped bindings through the bridge-backed platform surface instead of needing a second fake environment.

Vite is additive here

Vite and SvelteKit are optional outer hosts. The worker runtime, routes, bindings, and generated artifacts remain the core story.

Next step

Want support for your framework of choice?

Open an issue

What Devflare already supports across a real application

Hover a label to see what it means for config, local runtime, tests, previews, and operational guidance.

Full

Fetch, routes, and middleware

HTTP app core

Worker fetch entrypoints, file routing, and middleware are first-class Devflare surfaces with strong local runtime support and clean request-scoped helpers.

Full

KV, D1, and R2

Storage

Devflare gives the main storage bindings a strong local-first story: readable config, generated env typing, local runtime behavior, and realistic tests without losing the Cloudflare shape.

Full

Durable Objects and queues

State and async

Stateful objects and deferred work are treated as real worker surfaces, with config discovery, local runtime wrappers, and test helpers that match the application boundary.

Full

Service bindings and worker composition

Multi-worker

Service bindings and let worker-to-worker dependencies stay explicit enough for local multi-worker runtime, generated types, and real tests through the same env surface the app uses.

Partial

Hyperdrive

Remote database path

Hyperdrive is modeled cleanly in config and generated output, but the local and preview ergonomics are more constrained than KV, D1, or R2 because the real database and credentials stay remote.

Partial

Workers AI

Remote platform service

The AI binding is supported in config, types, and deployment flows, but meaningful tests are remote-oriented because real inference still lives on Cloudflare infrastructure.

Partial

Vectorize

Remote platform service

Vectorize is fully modeled in config and preview-aware naming, but real inserts and similarity queries still need remote infrastructure and honest remote-mode tests.

Full

Browser Rendering

Bridge-backed browser lane

Browser Rendering is fully supported through Devflare's bridge-backed local dev story, config model, generated typing, and runtime integration. The main platform caveat is still the Cloudflare one: exactly one browser binding.

What Devflare adds on top of raw Cloudflare workflows

These are the parts that feel distinctly like Devflare rather than just a thinner wrapper around Wrangler. They are implemented features in their own right, and each one has deeper docs when you want the full story.

Runtime

AsyncLocalStorage-backed context

Devflare stores the active event, env, ctx, request, and locals so helper code can recover the current Worker context without threading it through every function call.

Runtime

middleware

Request-wide middleware becomes a first-class pattern instead of something every app reinvents in a slightly different fetch wrapper.

Testing

Runtime-shaped unit testing and the smart bridge

The default test harness boots a real worker-shaped environment and uses the bridge so tests can talk to workers, bindings, queues, services, and other surfaces without inventing a second fake runtime.

Runtime

Custom bridge-backed values can round-trip as real classes instead of collapsing into plain JSON when the worker boundary needs richer types.

Composition

Multi-worker config references

and service bindings let one worker depend on another explicitly so config, generated types, local tests, and compiled output all follow the same relationship.

Configuration

Preview scopes and preview bindings

Preview environments can get their own scoped bindings and disposable infrastructure instead of borrowing production resources and hoping everyone remembers that later.

Types

Generated types

Generate and typed service contracts from the config so the worker surface, bindings, and entrypoints stay aligned with the app you actually run.

Operations

Binding-aware deploys

Build, preview, and production commands compile the same binding-aware config into Wrangler-compatible output instead of making you maintain a second deploy-only definition.

Configuration

config-time variables

Devflare reads while evaluating , which keeps build-time inputs available without blurring them together with runtime and .

Frameworks

Full Vite support

If the package is genuinely a Vite app, Devflare plugs into Vite as the outer host while still keeping worker-aware config, bindings, and generated Cloudflare output aligned underneath it.

This is the real distinction

Cloudflare gives you the platform primitives. Devflare adds the authored config model, runtime helpers, bridge-backed local dev, test harnesses, typed generation, and preview-aware workflows that make those primitives feel like one coherent application story.

Composable infrastructure is intentional

Devflare is designed around small, explicit files and runtime surfaces: , , , route modules, and runtime APIs that let those pieces compose cleanly instead of collapsing into one monolithic worker file.

That same shape works for a tiny project and for a larger enterprise repo. You can keep responsibilities split by surface, file, and package without losing the thread of one coherent Cloudflare application.

Next step

Want to see the package and repo shape Devflare is optimized for?

Open the project architecture guide

What you get on day one

  1. 1

    Author one readable instead of reverse-engineering a generated deployment shape.

  2. 2

    Point at one small handler and let Devflare manage the worker-oriented plumbing around it.

  3. 3

    Generate so bindings and helper surfaces stay typed without hand-maintained drift.

  4. 4

    Use the built-in test harness so your first tests look like the runtime you will actually ship.

  5. 5

    Add routes, bindings, frameworks, or preview flows only when the package truly needs them.

The point is fast confidence, not more ceremony

If Devflare is helping, your first win should be a small Worker you can understand, run, and test quickly — not a larger setup burden.

The smallest Devflare project still looks like a real project

Two authored files teach the whole loop, while generated pieces stay visible without becoming your source of truth.

Where it keeps paying off later

  • The package surface stays split by job as the app grows, so config authoring, runtime code, tests, framework hooks, and Cloudflare operations do not collapse into one file or one import path.
  • Rolldown keeps owning worker and Durable Object compilation, which is why the app can grow new surfaces without hand-maintaining a giant entrypoint.
  • If the package later needs Vite or SvelteKit, Devflare layers that in as an outer host and uses the bridge-backed platform surface so framework endpoints can still interact with worker bindings in local dev.
  • Preview scopes, cleanup flows, production operations, and testing helpers stay connected to the same authored config and CLI instead of branching into separate half-documented workflows.

Previous

Contract map

The documentation site now owns the authored docs model, while remains the generated one-file export shipped with the package.

Next

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.