Frameworks Devflare

Compose Devflare with SvelteKit by letting SvelteKit host the app and Devflare supply the Worker platform

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.

This is the path for full SvelteKit apps where the framework owns the outer shell and Devflare keeps the Worker-facing platform story coherent. It matches the repository’s real documentation app and the SvelteKit integration example in the public docs.

Best for: Full SvelteKit apps that deploy through Devflare
Worker entry: The adapter worker output your package actually emits, commonly or a repo-specific path such as , wired via
Hook helper

Wire the SvelteKit package like a SvelteKit app first

SvelteKit still owns the app shell, routing, and framework build. Devflare plugs Worker-aware config, generated Wrangler output, and any Durable Object discovery into that Vite-driven flow.

The adapter worker is a **build artifact** — only writes (or your repo's equivalent, like ) during . Devflare resolves handler paths *before* the framework build runs, so pointing at that path fails on a clean checkout with . Use instead: devflare skips composition entirely for the worker entry, and wrangler picks up the adapter output post-build.

If you also have queue handlers, scheduled handlers, durable objects, or routes, keep those in / / / as normal source files — composition still applies to those surfaces.

`devflare.config.ts`

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'notes-app',

files: {

// fetch is supplied by SvelteKit's adapter output below;

// keep this false so devflare does not try to compose around an unbuilt artifact.

fetch: false,

durableObjects: 'src/do/**/*.ts'

wrangler: {

passthrough: {

// SvelteKit's @sveltejs/adapter-cloudflare writes this file during vite build.

main: '.svelte-kit/cloudflare/_worker.js'

}

})

`vite.config.ts`

import { defineConfig } from 'vite'

import { sveltekit } from '@sveltejs/kit/vite'

import { devflarePlugin } from 'devflare/vite'

export default defineConfig({

plugins: [devflarePlugin(), sveltekit()]

})

Put the Devflare handle at the front of

Why the order matters

The Devflare handle is the piece that prepares in local dev. Put it first so later middleware sees the same platform shape the app expects.

Simple composed handle

import { sequence } from '@sveltejs/kit/hooks'

import { handle as devflareHandle } from 'devflare/sveltekit'

const authHandle = async ({ event, resolve }) => resolve(event)

export const handle = sequence(devflareHandle, authHandle)

Custom handle with explicit binding hints

import { sequence } from '@sveltejs/kit/hooks'

import { createHandle } from 'devflare/sveltekit'

const devflareHandle = createHandle({

hints: {

DB: 'd1',

CACHE: 'kv',

CHAT_ROOM: 'do'

}

})

export const handle = sequence(devflareHandle)

Reach for only when the simple handle is not enough

Use the exported from when auto-loaded binding hints from are enough.
Use when you need custom binding hints, a custom bridge URL, or a custom rule.
If your repo already points at the adapter worker, keep that path authoritative instead of duplicating it in .
Keep the rest of the app in normal SvelteKit patterns; Devflare is there to supply the Worker platform and config alignment, not to replace SvelteKit itself.

Vite standalone

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.

GitHub workflows

Devflare ships reusable GitHub Actions for setup, impact checks, deploy execution, and feedback, plus supported workflow strategies for validation, previews, production, and cleanup.

Wire the SvelteKit package like a SvelteKit app first

Put the Devflare handle at the front of hooks.server.ts

Reach for createHandle() only when the simple handle is not enough

Vite standalone

GitHub workflows

Put the Devflare handle at the front of

Reach for only when the simple handle is not enough