Configuration Devflare

Configure the project shape around explicit file surfaces before the package gets noisy

Start with one fetch file, then add routes, background handlers, Durable Objects, assets, and transport rules only when the project genuinely needs them.

The config keys that shape a Devflare project are mostly about which files or globs Devflare should treat as real runtime surfaces. Keep that shape small at first, then expand it deliberately instead of letting autodiscovery and generated output become the accidental architecture.

Best for: Teams deciding how many runtime surfaces one package actually needs
Primary shape keys: , , , and
Safest habit: Add one surface only when the current project shape truly asks for it

Start with the smallest honest project shape

Devflare does not ask you to configure every possible Worker surface up front. The clean starting point is one fetch entry, then a route tree, a queue consumer, Durable Objects, or other surfaces only when the package actually needs them.

That keeps the authored config readable in code review and stops the project structure from silently inheriting complexity just because a default glob or generated file happened to exist.

1

Start with for the main HTTP Worker surface.
2

Add when multiple URLs deserve their own modules.
3

Add background surfaces such as , , or only when the package truly owns those events.
4

Add , , , or only when the runtime contract calls for them.
5

Keep static assets, deployment routes, and WebSocket proxy rules in their own config lanes instead of smuggling them into file conventions.

Project shape is part of architecture

If the config says one package owns five runtime surfaces, reviewers should be able to see why. Devflare works best when that shape is explicit instead of accidental.

Know which keys actually shape the project

Config lane	Use it when	Project effect
	One main Worker surface should own request-wide behavior.	Points Devflare at the fetch entry you author directly.
	The project needs route modules or a mounted route prefix.	Lets a route tree sit beside or replace the main fetch file.
, ,	The package consumes background or platform-triggered events.	Adds separate handler files for those runtime surfaces.
, ,	The project needs stateful classes, named entrypoints, or workflow definitions.	Turns globs into additional Worker-owned code surfaces Devflare can discover and bundle.
	Custom value transport is needed for richer Worker or Durable Object contracts.	Lets you point at one explicit transport file, or disable autodiscovery with .
, ,	Static files, deployment routing, or dev WebSocket proxy behavior need their own config.	Keeps non-handler project concerns out of the file-surface lane.

One config can stay readable even when the package grows a few real surfaces

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'notes-api',

files: {

fetch: 'src/fetch.ts',

routes: {

dir: 'src/routes',

prefix: '/api'

queue: 'src/queue.ts',

scheduled: 'src/scheduled.ts',

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

transport: null

assets: {

directory: 'public'

}

})

Use autodiscovery deliberately, and disable it explicitly when you mean it

Omit when the default location is already the right fit.
Use an explicit object when the route root or prefix should be obvious in config review.
Set when the package should not use file-route discovery at all.
Set when you want transport autodiscovery disabled instead of guessed.
Use explicit file or glob paths when the project layout is non-standard enough that the default convention would hide intent.

Conventions are only helpful when they still describe the project accurately

As soon as a default convention stops being obvious, move back to explicit config. That is usually the more maintainable choice.

Open the deeper page for the shape you just introduced

Architecture

Need the broader package setup map?

Open project architecture when the question is the full package layout — authored config, runtime files, generated output, hosted app files, or monorepo boundaries.

Routing

Need route modules?

Open the HTTP routing page when becomes part of the project shape.

Runtime

Need transport?

Read the transport page when a custom transport file becomes part of the contract between worker code and stateful surfaces.

Configuration

Need generated env types?

Open the generated types page when bindings, Durable Objects, or named entrypoints become part of the package contract.

Frameworks

Need a host shell?

Open the framework pages only when the package truly becomes a Vite or SvelteKit app instead of a worker-first package.

Full config

See one canonical that touches the main current config lanes in a single file, with hover coverage on every property shown in the example.

Worker surfaces

Devflare can compose or wrap several Worker surfaces into one generated entrypoint, but the authored source of truth should stay in explicit files such as , , , and .