Binding reference Bindings

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

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

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
Authoring shape
Best for: Background jobs, async processing, fan-out work, and controlled retry behavior

Add the binding to config

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

}

]

}

})

Use the binding from application code

After Devflare generates the worker env, import from and keep the first Queues 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.

One fetch path and one queue consumer

import { env } from 'devflare/runtime'

import type { MessageBatch } from '@cloudflare/workers-types'

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

await env.JOBS.send({ id: 'job-1', createdAt: Date.now() })

return new Response('queued', { status: 202 })

}

export async function queue(batch: MessageBatch<{ id: string }>): Promise<void> {

for (const message of batch.messages) {

await env.RESULTS.put('job:' + message.body.id, 'done')

message.ack()

}

Local and Remote Support

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

Local runtime and queue-trigger tests. Start locally with plus ; that lane should cover the normal Queues 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 Queues details.

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.

Testing path

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.

Open the next page when you need it

Subpage

Queues internals

Internals

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

Subpage

Testing Queues

Testing

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

Subpage

Queues example

Example

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