Cloudflare Queues
Cloudflare Queues
Role
The family's primary durable message queue. Producer + consumer are
both Cloudflare Workers, bound at deploy time via wrangler.toml —
no extra service to provision, no separate dashboard. Used by the
api.oriz.in umbrella Worker for: cross-post fan-out (oriz-omnipost
adapter dispatch), webhook back-pressure relief downstream of
Hookdeck, retry buffers for any flaky
external API.
Free tier
- 1,000,000 operations / month
- Native binding from any Worker — no HTTP hop
- Built-in retry + dead-letter queue support
- Up to 100 queues per account
Card / subscription required?
NO for free tier sign-up. Cloudflare Queues is part of the same account as Pages / Workers / R2 / DNS — adding it does not require a billing method.
Alternatives
- Upstash QStash — deferred fallback (HTTP queue)
- Inngest — deferred fallback (durable functions)
Swap cost
Medium — producer/consumer code uses the Cloudflare-native binding API; swapping to QStash or Inngest means swapping the binding for an HTTP call and re-modelling the consumer.
Why this is our pick
Stack cohesion, not feature richness. Every other layer of the family runs on Cloudflare (Pages, Workers, DNS, Registrar, R2). A queue that is bound natively to the Worker producing and consuming messages eliminates an HTTP round-trip and an extra credentials surface. The 1M ops/month cap is an order of magnitude above realistic family traffic.
Cross-refs
- Cloudflare-native queue decision
- Cloudflare Pages for all sites
- Upstash QStash — deferred alternative
- Inngest — deferred alternative
- Hookdeck — webhook reliability layer that pushes into this queue
- No card-on-file rule