Configuration Devflare

Use to keep and aligned with the project you actually authored

turns config, discovered Durable Objects, named entrypoints, and cross-worker references into one generated TypeScript contract instead of a pile of hand-maintained env guesswork.

The generated file is more than editor garnish. It is the typed mirror of your Devflare config and discovery rules: bindings land on global , named entrypoints become an exported union, and referenced workers can produce typed service interfaces when Devflare can follow them accurately.

Best for: Packages that use bindings, Durable Objects, service bindings, or named worker entrypoints
Main command
Default output: relative to the directory you run the command from unless you override it
Best pairing: on the referenced worker config

Treat the generated file as the typed contract, not as handwritten glue

reads the resolved config, discovers supporting source files, and writes one generated file that says what the package runtime actually exposes. This is more reliable than hand-maintained declarations because the source of truth stays in config and file discovery, not in a second hand-maintained type file.

The result is usually a global interface plus an exported union. That combination is what keeps bindings, cross-worker service calls, and named entrypoints typed without making you manually mirror every config change.

Generated means generated

Do not hand-edit and expect the next run to preserve it. Change config or source files, then rerun .

A generated file should read like output, not a second config file

// Generated by devflare - DO NOT EDIT

// Run devflare types to regenerate

import type { MathServiceInterface } from '../src/math-service.types'

import type { AdminEntrypointInterface } from '../src/math-service.types'

declare global {

interface DevflareEnv {

MATH_SERVICE: MathServiceInterface

ADMIN: AdminEntrypointInterface

}

/**

* Named entrypoints discovered from ep.*.ts files.

* Use with defineConfig() for type-safe cross-worker references.

export type Entrypoints = 'AdminEntrypoint'

The command loop stays intentionally small

bunx --bun devflare types

bunx --bun devflare types --output env.generated.d.ts

Know what the command is actually discovering

If no named entrypoints are discovered yet, stays — the fallback is intentional.
does not take an flag today, so the generated contract reflects the resolved base config rather than a named environment overlay.
If you choose a nested path, create the parent directory first; the command writes the file but does not scaffold missing folders for you.
Discovery follows the configured file patterns first, then falls back to the default Durable Object and entrypoint globs.
The generated types are only as good as the authored config and file naming conventions they can see.

Input Devflare reads	Where it comes from	Typed result
, , and	The resolved top-level from the current working directory or explicit path.	Members on global .
Local Durable Object classes	or the default discovery pattern.	when the class can be located accurately.
Named worker entrypoints	or the default discovery pattern plus exported classes extending .	An exported union for .
references	Imported Devflare configs in other packages or subfolders.	Typed service bindings and cross-worker Durable Object namespaces when Devflare can resolve them.
Unknown or unresolvable service surface	A target worker or entrypoint that cannot be turned into a stable interface.	fallback instead of fake precision.

Typed fallback is still honest typing

Getting for a service binding is not a failure of the generator so much as Devflare refusing to invent a stronger interface than it can justify from the available source.

Type the worker that owns the entrypoints, then let carry that knowledge

The union matters most on the worker being referenced. Import that generated type into the worker's own config and pass it to , then callers that use can ask for named entrypoints without turning those names into loose string conventions.

That keeps the typing relationship honest: the worker that owns files declares which entrypoints exist, and the worker that consumes them gets autocomplete and checking through later.

Put on the referenced worker config, not on every caller in the repo by reflex.
Keep the named entrypoint files boring and explicit: plus classes extending .
Rerun in the worker that owns those entrypoints whenever you rename a class or add another one.

Types are not a substitute for critical deploy validation

Named service entrypoints are modeled at the Devflare layer, but if a particular service path is operationally critical, still inspect the compiled output with or before trusting muscle memory.

One worker declares the entrypoints, another consumes them through `ref()`

import { WorkerEntrypoint } from 'cloudflare:workers'

export class AdminEntrypoint extends WorkerEntrypoint {

async resetStats(): Promise<{ success: boolean }> {

return { success: true }

}

Keep the generated contract boring and rerunnable

Bindings

Need the multi-worker architecture story?

Open the multi-worker page when the question is whether another worker boundary is warranted before you worry about typing that boundary.

Configuration

Need the surface-discovery map?

The worker-surfaces page explains which authored files and discovery globs become part of the worker contract in the first place.

CLI

Need the broader command map?

The CLI page keeps , , , , and config-inspection commands in one everyday workflow map.

1

Run after adding or renaming bindings, Durable Objects, service references, or named entrypoints.
2

Keep the default cwd-relative location unless a custom path truly buys something more than folder aesthetics.
3

Import from the generated file only where the owning worker config needs it.
4

Inspect compiled output when a cross-worker or entrypoint boundary matters operationally, not just ergonomically in the editor.

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 .

Environments

Keep one base config, layer environment-specific overrides with , and let Devflare resolve preview or production details only in the commands that actually need them.