I was moving a heavy queue consumer off a Cloudflare Worker and onto a long-lived Node process on my own server — the Worker’s memory budget is a bad place for batch work, and Cloudflare Queues supports an HTTP pull mode built for exactly this.
The thing that isn’t obvious until you try it: a queue has exactly one consumer mode at a time. You cannot keep the Worker push consumer attached while you stand up the pull consumer next to it and cut over gracefully. The migration is a hard switch:
wrangler queues consumer worker remove <queue> <worker>
wrangler queues consumer http add <queue>
Until you run the second command, messages simply accumulate; after it, your Worker will never see another message from that queue. That shapes the rollout plan: the pull consumer has to be deployed, configured, and proven able to authenticate before you flip the mode, and you should pick a quiet window because there is no dual-running period.
Two follow-on notes from doing this twice (a billing consumer, then an evaluation consumer):
- The producer side doesn’t change at all — the Worker keeps calling
queue.send(). Only consumption moves. - Sharing the actual processing logic matters more than the transport. I imported the same handler code the Worker used into the Node consumer rather than reimplementing it, so the migration changed where messages are processed and nothing about how.
The payoff is real: batch sizes, concurrency, and DB pool sizing become your decisions on your hardware, instead of negotiations with a 128 MB isolate.