Application example Bindings

Use Worker Loaders in a real application path

Worker Loader bindings let a Worker load additional dynamic Workers at runtime.

A compact Worker Loaders recipe with config and worker usage in one application path.

Use this as the copyable starter before threading the feature into a larger application.

Config focus: bindings.workerLoaders
Runtime shape
Best use: Dynamic Workers where the app loads Worker code at runtime from an explicit source

Start by wiring the binding clearly in config

Smallest Worker Loader config

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'loader-worker',

bindings: {

workerLoaders: {

LOADER: {}

}

})

Build the application flow around the binding

Treat this as the app-level Worker Loaders path: the route, event handler, or service module receives a real request and uses the binding to do useful work.

Keep product limits, remote ownership, and fallback behavior visible in the code around the binding instead of hiding everything behind a vague utility too early.

Keep the first example short enough to paste into a new Worker.
Cloudflare owns dynamic Worker upload, discovery, and hosted lifecycle; local code should pass explicit payloads or stubs.

Load an explicit Worker payload

import { env } from 'devflare/runtime'

export async function fetch(request: Request): Promise<Response> {

const stub = env.LOADER.get('tenant-a', () => ({

compatibilityDate: '2026-04-26',

mainModule: 'index.js',

modules: {

'index.js': 'export default { fetch() { return new Response("ok") } }'

}

}))

return stub.fetch(request)

}

Keep production boundaries visible

Config focus: bindings.workerLoaders.
Runtime shape: .
Best use: Dynamic Workers where the app loads Worker code at runtime from an explicit source.

Thread this into the next recipe

Once this smallest path works, add routing, generated types, and feature-specific abstraction in that order.

Testing Worker Loaders

Test Worker Loaders by choosing the local harness that matches the product boundary instead of reaching for Cloudflare by default.

Secrets Store

Add the Secrets Store config, call from worker code, and start with the local test path Devflare supports.