Frameworks Devflare

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

Point Devflare at SvelteKit’s Cloudflare worker output—often via , but sometimes by handing the adapter worker directly—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
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.

Keep Devflare aligned with the adapter output your package actually emits. Many packages do that with and an adapter default such as . The documentation app in this repository instead points at its configured output, which is equally valid when the package already owns the adapter worker directly.

`devflare.config.ts`

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'notes-app',

files: {

fetch: '.svelte-kit/cloudflare/_worker.js',

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

}

})

`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

This repository keeps GitHub workflows small on purpose: caller workflows own triggers, permissions, and package selection, while shared Devflare actions handle impact checks, deploy execution, and feedback publishing.