Under the hood Bindings

How Devflare wires Queues from config to runtime

Queues let Workers send messages to background consumers with retries, batching, and dead-letter handling.

Queue config is compiled into explicit producer and consumer blocks, with preview resource materialization available for both queue names and DLQs.

This is one of the clearer compiler paths in Devflare: producers become env bindings, consumers become worker-side queue listeners, and preview lifecycle code can materialize names when the preview should own separate queues.

Normalization: Producer and consumer config is split into one normalized queue model before compile
Compile target: Wrangler and
Preview note: Preview queue names and DLQs can be provisioned and cleaned up when the preview owns them

How authored config becomes Wrangler config

Devflare does not treat queue producers and queue consumers as unrelated configuration fragments. It keeps them in one coherent config namespace so later compile and preview code can see the whole story.

Review and runtime stay aligned: the config already names the queue, the producer binding, the consumer, and the dead-letter relationship in one place.

Queues config and emitted Wrangler output

Use this when you need to check how the Devflare config becomes Wrangler-compatible config.

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'queue-worker',

bindings: {

queues: {

producers: {

JOBS: 'jobs-queue'

consumers: [

{

queue: 'jobs-queue',

deadLetterQueue: 'jobs-dlq',

maxRetries: 3

}

]

}

})

What local runtime support covers

The local harness can stand up queue producers as real env bindings and trigger the queue handler through test helpers.
Queue helper behavior is different from plain worker fetch behavior because waits for queued background work before returning.
That makes queue tests a good place to assert post-processing side effects directly.

Compile, preview, and cleanup behavior

Compile converts consumer options into the output shape Wrangler expects, including retry and dead-letter fields.
Preview materialization can generate branch-specific queue and DLQ names when the preview environment should own separate async infrastructure.
This lifecycle support covers queue resources more directly than service bindings, which mostly stay name-based references.

Queues stay reviewable when the config stays explicit

The combination of producers, consumers, and dead-letter settings is much easier to trust when it lives in one visible authored shape.

Cloudflare docs vs the Devflare layer

Cloudflare Queues 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 .

Reference

Cloudflare Queues docs

Cloudflare Docs

Platform reference for queue producers, consumers, delivery guarantees, retries, batching, and DLQs.

Question	Cloudflare docs	This Devflare page
Primary focus	Platform reference for queue producers, consumers, delivery guarantees, retries, batching, and DLQs.	How to author , what the runtime surface looks like, and how Queues 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 queue-trigger 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.

Queues

Devflare models Queue producers and consumers explicitly, which makes local tests and preview naming much easier to reason about.

Testing Queues

Queue testing is one of the places where Devflare’s helper surface feels especially good because the queue trigger already knows how to drive the real handler shape.