Binding reference Bindings

Use service bindings to keep multi-worker apps explicit instead of magical

Service bindings let one Worker call another Worker without routing through a public URL.

The fast Devflare payoff is simple: wire one worker to another with , call it through , and prove the same relationship locally in one test.

This is the clean lane for apps that genuinely need more than one worker. Devflare keeps the worker family explicit in config, resolves the referenced surface, and lets local tests use the same service binding contract instead of copied worker names or hand-built internal URLs.

Config key
Authoring shape
Best for: Multi-worker systems, internal RPC boundaries, and explicit service composition

Add the binding to config

The easiest honest starting point is one gateway worker, one referenced worker, and one service binding in config.

is especially useful because it keeps the dependency explicit while still giving Devflare enough structure to resolve, type, and boot the linked worker locally later.

Service binding authoring with `ref()`

import { defineConfig, ref } from 'devflare/config'

const mathService = ref(() => import('../math-service/devflare.config'))

export default defineConfig({

name: 'gateway',

bindings: {

services: {

MATH_SERVICE: mathService.worker,

ADMIN: mathService.worker('AdminEntrypoint')

}

})

Use the binding from application code

After Devflare generates the worker env, import from and keep the first Services path close to the route, handler, or service method that needs it.

Keep this first path small enough that the config, env binding, and user-visible behavior are easy to review together.

Use the service in the gateway worker

import { env } from 'devflare/runtime'

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

const result = await env.MATH_SERVICE.add(4, 5)

return Response.json({ result })

}

Local and Remote Support

Devflare can run useful Services application behavior locally for ordinary development and tests. Cloudflare still owns production limits, quotas, billing, and deployed account behavior.

Local runtime and multi-worker tests. Start locally with plus ; that lane should cover the normal Services application flow without requiring a Cloudflare connection.

Use Cloudflare when the assertion depends on deployed limits, account state, lifecycle behavior, billing, or other production-only Services details.

When this binding fits best

Use service bindings when another worker is a real dependency, not when one large worker is merely inconvenient to think about.
They are a strong fit for internal APIs, admin surfaces, search workers, and explicit worker-family boundaries.
If the dependency is actually shared data rather than another service boundary, a direct binding like D1, KV, or DO may stay simpler.

Testing path

Preview isolation follows resolved worker names, not just whatever branch or alias string you passed to a deploy command.
Named entrypoints are modeled, but critical production wiring is still worth validating in compiled output.
Service bindings are references, not preview-managed account resources like KV, D1, or queues.

A very good review question

Ask which worker names a preview will actually deploy before you assume the worker family is isolated.

Open the next page when you need it

Subpage

Services internals

Internals

Check emitted Wrangler , preview behavior, and Cloudflare-specific details.

Subpage

Testing Services

Testing

Pick the plus path first, then move to remote checks only when the test needs them.

Subpage

Services example

Example

Copy a fuller application path when the quick example is too small.