How Devflare wires Services from config to runtime
Service bindings let one Worker call another Worker without routing through a public URL.
Devflare resolves referenced worker configs, bundles the linked worker surfaces, and then exposes those services as local multi-worker bindings.
Service bindings feel more than cosmetic: the tooling follows the relationship far enough to keep local tests, type generation, and compiled output aligned.
- Normalization
- Plain objects and values normalize into one service-binding model
- Compile target
- Wrangler
- Preview note
- Preview can rewrite service names, but service bindings are not preview-managed resources like KV or D1
How authored config becomes Wrangler config
Service bindings can be authored as plain binding objects or as results. Devflare normalizes those into one shape so compiler, type generation, and test setup can all reason about them consistently.
When a binding comes from , Devflare can follow the referenced config, discover the relevant worker surface, and keep that relationship visible in local tooling.
Services config and emitted Wrangler output
Use this when you need to check how the Devflare config becomes Wrangler-compatible config.
What local runtime support covers
- is responsible for following referenced configs and bundling the default export or named entrypoints as needed.
- Local multi-worker Miniflare wiring uses the resolved service metadata so a gateway worker can call another worker naturally in tests.
- Type generation can emit service-specific interfaces; if that is not possible, the binding falls back to a generic contract.
Compile, preview, and cleanup behavior
- Compile emits the standard array that Wrangler expects.
- Preview flows can rewrite service names when the preview naming rules say they should, but there is no separate resource-provisioning lifecycle for services themselves.
- Critical production wiring is still worth checking through , , or dry-run deploy output.
This is configuration as architecture, not just syntax
Service bindings work well in Devflare because the relationships are explicit enough for tooling to follow, type, and test.
Cloudflare docs vs the Devflare layer
Cloudflare Service bindings docs is the platform reference. Use this internals page when you need to compare Cloudflare's product docs with Devflare config, generated env types, local support, and preview behavior for .
| Question | Cloudflare docs | This Devflare page |
|---|---|---|
| Primary focus | Platform reference for worker-to-worker bindings, service entrypoints, and the underlying runtime contract. | How to author , what the runtime surface looks like, and how Services fits a Devflare project. |
| Testing and runtime lens | Cloudflare’s docs focus on the raw binding API, product semantics, and platform limits for the binding itself. | Local runtime and multi-worker tests. Use the Devflare guidance when you need the honest local harness or the right remote gate instead of only the product API shape. |
| When to open it | When you need the platform contract, limits, APIs, or account-level product details. | When you are wiring, testing, previewing, or reviewing the binding inside a Devflare app. |
Previous
Services
The fast Devflare payoff is simple: wire one worker to another with , call it through , and prove the same relationship locally in one test.
Next
Testing Services
Service bindings are one of the clearest Devflare wins in multi-worker apps: you can keep the real worker boundary and still prove it through the default local harness.