Frameworks Devflare

Use Devflare with a standalone Vite app when Vite is the outer host and Devflare owns Worker config underneath

An effective Vite config is what opts the package into Vite-backed flows: a local , a non-empty , or both together. Use when the package really is a Vite app and you want Devflare to keep Worker config, Durable Objects, and generated Wrangler output aligned underneath it.

This is the lane for frontend-first packages that already have a real Vite app shell. Vite keeps HMR and the app build. Devflare plugs generated Worker config, Durable Object discovery, bridge behavior, and Worker-aware artifacts into that pipeline.

Best for: Standalone Vite apps that still ship Worker-aware runtime pieces
Mode switch: Local or non-empty
Primary helper

Know what actually enables Vite-backed mode

A local opts the current package into Vite-backed flows.
A non-empty also opts the package into Vite-backed flows.
Vite dependencies by themselves do not switch the package out of worker-only mode.
Without an effective Vite config, , , and stay worker-only.

Worker-only is still the default

Use Vite because the package has a real Vite host, not because it feels like every modern project should have one glued on top.

Choose the lightest wiring that fits the app

Use the minimal plugin shape when this file only needs to add Devflare’s Worker-aware behavior and the rest of the Cloudflare Vite wiring already lives elsewhere. Reach for when this file should own the Cloudflare plugin configuration explicitly too.

Minimal Devflare-side Vite integration

import { defineConfig } from 'vite'

import { devflarePlugin } from 'devflare/vite'

export default defineConfig({

plugins: [devflarePlugin()]

})

Explicit Cloudflare plugin wiring

import { defineConfig } from 'vite'

import { cloudflare } from '@cloudflare/vite-plugin'

import { devflarePlugin, getDevflareConfigs } from 'devflare/vite'

export default defineConfig(async () => {

const { cloudflareConfig, auxiliaryWorkers } = await getDevflareConfigs()

return {

plugins: [

devflarePlugin(),

cloudflare({

config: cloudflareConfig,

auxiliaryWorkers: auxiliaryWorkers.length > 0 ? auxiliaryWorkers : undefined

})

]

}

})

options

Option	Type	Default	Description
			Path to the Devflare config file.
		—	Named environment from config to resolve.
			Enable Durable Object code transforms.
			Watch the config file for changes in dev mode.
			Miniflare bridge port for WebSocket proxying.
			Additional patterns to proxy WebSocket requests to Miniflare. Patterns from in config are included automatically.

Know what changes once Vite is actually active

The package still uses the same Devflare command loop. What changes is the outer host: Vite takes over the app shell while Devflare keeps resolving worker config, generated Wrangler output, Durable Object discovery, and composed worker entrypoints underneath it.

That means you should think in terms of host ownership, not a separate CLI mode. Reach for this page when the package genuinely became a Vite app, not when you just need one more bundler-shaped knob.

1

Devflare loads and validates first.
2

If a local exists, Devflare loads it and overlays on top; otherwise it can synthesize from alone. That merged result is the effective Vite config.
3

Devflare still compiles worker-aware config into generated Wrangler output and may generate when worker surfaces need wrapper glue or composition.
4

Build and deploy use the current package's installed Vite so the outer app build and the inner worker plumbing stay aligned.

Same commands, different host

You do not learn a second CLI vocabulary for Vite-backed packages. The config decides who hosts the outer app, while the Devflare commands stay familiar.

Keep ownership lines obvious

Vite owns

The outer app dev server, HMR, and the app build for packages that are truly Vite apps.

Devflare owns

Generated Wrangler config, composed worker entrypoints, Durable Object discovery, bridge behavior, and worker-aware build glue.

Generated output

Treat and as output, not as the source of truth you maintain by hand.

If both and exist, Devflare merges first and then overlays .
is the explicit opt-out if you want to own the Worker main entry completely.

Svelte in workers

When a worker-only fetch surface or Durable Object imports , add the Svelte compiler to . That compilation belongs to Devflare’s worker bundler, not the main Vite plugin chain.

SvelteKit

Hand SvelteKit's Cloudflare adapter output to Devflare via (the adapter worker is a build artifact and does not exist until runs), keep in , and compose into so local platform bindings line up with the Worker runtime Devflare manages.