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 the files you edit small and obvious, then 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 separate
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 splits by environment and lifecycle 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 supports across Cloudflare platform features

Every native binding or platform lane in the binding docs is listed here with its current Devflare support level and a direct link to the page with config, examples, tests, and boundary notes. Hover a label to see what that support level means.

Full

KV

Storage

Named config, generated types, local runtime behavior, and or tests for lookup state and lightweight shared data.

Full

D1

Storage

SQLite-style local behavior, id or name-based config, generated env typing, and realistic query tests through the same binding shape used in Workers.

Full

R2

Storage

Object storage config, local bucket behavior, generated env typing, and runtime-shaped tests. The caveat is Cloudflare object delivery URLs, not the binding itself.

Full

Durable Objects

State

Stateful object wiring, discovery, generated config, local namespaces, and test access, including cross-worker references. Preview lifecycle still follows Cloudflare limits.

Full

Queues

Async

Producer and consumer config, local queue-trigger tests, generated env typing, and worker-surface composition for background work.

Full

Services

Multi-worker

service bindings, typed worker-to-worker env contracts, local multi-worker runtime, and tests that call the same service binding the app uses.

Remote

AI

Remote AI

Native config, generated types, deploy support, and AI Gateway method coverage are present. Real inference, model behavior, billing, and most meaningful tests remain Cloudflare remote behavior.

Remote

Vectorize

Remote vector search

Native config, generated types, preview-aware resource naming, and remote-mode tests are supported. Real index semantics and similarity results require Cloudflare.

Full

Hyperdrive

Database path

Config, name resolution, local connection strings, and Miniflare-backed Hyperdrive bindings support ordinary app queries without Cloudflare. Hosted pooling, placement, credentials, and production routing remain Cloudflare behavior.

Full

Browser Rendering

Browser runtime

Native config, generated typing, route examples, and bridge-backed dev-server support through the local browser-rendering shim. Cloudflare still owns hosted session limits, live/HITL behavior, recordings, and billing.

Remote

Analytics Engine

Analytics

Dataset bindings are configured in Devflare, and app code can be thin-tested around . Production ingestion and analytics behavior remain hosted.

Full

Send Email

Email

Outbound email bindings have native config, local support, and test access through the env binding. Inbound email handlers are a separate Worker surface.

Full

Rate Limiting

Rate limits

Native fixed-window config, Miniflare-backed local behavior, generated typing, and pure mocks support deterministic application-level rate-limit tests.

Full

Version Metadata

Deployment metadata

Native config, deterministic local metadata, and test helpers support version-aware responses and diagnostics without requiring Cloudflare state.

Full

Worker Loaders

Dynamic workers

Devflare wires Worker Loader bindings through Miniflare and pure test stubs, so local apps can load explicit Worker payloads without Cloudflare. Upload, discovery, and hosted lifecycle stay on the platform.

Full

Secrets Store

Secrets

Native config, Miniflare wiring, and explicit local fixtures cover app code that reads Secrets Store values. Devflare still does not read, provision, or sync account secret values.

Remote

AI Search

Hosted search

Native instance and namespace config plus deterministic fixtures can test application flow. Crawling, indexing, ranking, and hosted model behavior stay in Cloudflare.

Remote

mTLS Certificates

Outbound TLS

Native config and Fetcher-shaped local fixtures are supported. Real client-certificate presentation and certificate lifecycle remain Wrangler and Cloudflare remote behavior.

Remote

Dispatch Namespaces

Workers for Platforms

Native dispatch namespace bindings and tenant Fetcher fixtures are supported. Devflare does not upload tenant Workers or emulate the Workers for Platforms control plane.

Full

Workflows

Long-running work

Native config, Miniflare workflow bindings, deterministic mocks, and real WorkflowEntrypoint examples cover the local app loop. Production lifecycle, durability, retries, and scheduling remain Cloudflare-owned.

Remote

Pipelines

Event ingestion

Native config and local send-recording tests are supported for producer code. Pipeline creation, batching, transformations, sinks, and delivery are Cloudflare-managed.

Full

Images

Image processing

Native singleton config, Miniflare image bindings, persisted local state, and deterministic pure mocks cover Worker image transform flows. Hosted storage, variants, delivery rules, billing, and final transform fidelity remain remote.

Full

Media Transformations

Media processing

Native config, Miniflare media bindings, and deterministic pure mocks cover Worker media transform chains locally. Real codecs, output fidelity, duration handling, cache behavior, and billing remain hosted Cloudflare behavior.

Remote

Artifacts

Git-like artifacts

Native config and in-memory repo or token fixtures are supported for app flow. Durable storage, Git-over-HTTPS remotes, namespace creation, and permissions are Cloudflare-owned.

Full

Containers

Containers

Native top-level container config has full local support through Docker or Podman: Devflare can build Dockerfile paths offline-first, run prebuilt image tags, and interact with launched instances. Deployed rollout, registry availability, SSH, scaling, and hosted platform behavior remain Cloudflare-owned.

What Devflare adds on top of raw Cloudflare workflows

These are the pieces you use while building an app, not concepts you need to memorize before the first route works.

Runtime

Runtime context helpers

Helper code can read the active request, env, ctx, event, and without threading the event through every function call.

Runtime

middleware

Request-wide middleware gets a named helper instead of forcing every app to reinvent the same 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.

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.