Binding reference Bindings

Use Queues when work should happen later, in batches, or with retries

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

The config shape keeps the relationship visible: which bindings can enqueue work, which consumer handles that queue, and how retries or dead-letter behavior should look.

Config key: bindings.queues
Authoring shape: { producers?: Record<string, string>; consumers?: QueueConsumer[] }
Best for: Background jobs, async processing, fan-out work, and controlled retry behavior

Author it in the simplest shape that still says what you mean

Queues are easiest to understand when the producer names and consumer config live together in the same authored source of truth.

That way the code review already shows who sends messages, who processes them, and where failures go when retries run out.

Queue producer and consumer authoring

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

}

]

}

})

When this binding fits best

Use Queues when the worker should hand work off instead of blocking the original request.
They are a good fit for batch processing, notifications, post-request writes, and work that deserves retry control.
If the task must happen synchronously in the request path, a queue is probably the wrong tool.

Notes worth keeping visible

Keep producer and consumer intent explicit so dead-letter and retry behavior is reviewable.
Preview-scoped queues and DLQs are possible, but they should be created only when the preview really owns separate async infrastructure.
Queue tests should separate handler behavior from wider route or scheduling concerns.

The queue rule of thumb

If a request can safely say “I accepted the work” before the work is complete, queues are a good candidate. If not, keep it in the request path.

Cloudflare docs vs the Devflare layer

Cloudflare Queues docs is the platform reference. This page is the Devflare translation layer: keep readable in source, understand the typed env surface, and know which local, preview, or remote lane actually matches the binding.

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.	First-class 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.

Go deeper only if this one-page guide stops being enough

Subpage

Queues internals

Internals

See normalization, Wrangler and , and the preview or runtime details behind the authored shape.

Subpage

Testing Queues

Testing

Start from plus and only escalate when the binding or deployment model genuinely needs it.

Subpage

Queues example

Example

Adapt one small end-to-end path before you hide the binding behind a bigger abstraction.