Laravel 13.26 Made Queue Rerouting Much Cleaner

Queue::forward()

At first glance, it looked like one of those small additions you could easily scroll past. But once I understood the problem it was solving, it started making a lot more sense.

Laravel 13.26 now lets you redirect jobs from one queue to another, or even move them to another connection from one central place.

The Problem It Solves

So imagine you have jobs being sent to a queue called reports.

Over time, that queue name can start appearing everywhere. Inside job classes, dispatch calls, queue attributes, worker configurations and possibly even packages you did not write yourself.

Then one day, reports becomes too heavy and you decide it should run on a different Redis connection.

Previously, that could mean going through different parts of the application to change where those jobs were sent.

That sounds manageable until you have a large application and reportshas quietly made itself comfortable in twenty different places.

This is where Queue::forward() comes in.

Instead of changing all those places, you can define the new destination once.

Now jobs targeting reports can be forwarded to reports.fifo on the cloud connection. The forwarding rule belongs in a service provider, so the rest of the application can continue using the original queue name.

I kinda like this part.

The jobs do not necessarily need to know that your infrastructure has changed.

It Can Be Simpler Than That Too

You do not always have to change both the queue name and connection.

If you only want to move a queue to another connection, you can do this.

Or if you just want to rename the queue while keeping the same connection.

You can also forward multiple queues together.

Laravel also supports backed enums for the queue names.

This Is Different From Queue::route()

This confused me briefly because Laravel 13 already introduced Queue::route().

The easiest way I now understand the difference is this.

Queue::route() decides where a particular job class should go.

Queue::forward() works from the other direction.

Instead of saying where a particular job should go, you are saying that anything currently targeting a particular queue destination should be redirected somewhere else.

So one is mainly about routing jobs.

The other is about rerouting queues.

That distinction made the feature click for me 🤔

Where I Think This Gets Really Useful

The environment-specific use case is probably my favourite.

You might use Redis locally but use a managed queue service in production.

Instead of adding environment checks around your jobs, you can put the forwarding logic inside your service provider.

You might use Redis locally but use a managed queue service in production.

Instead of adding environment checks around your jobs, you can put the forwarding logic inside your service provider.

Your application keeps dispatching the same jobs, while Laravel handles where they eventually land. It also means experimenting with another queue connection becomes less invasive. You can move one queue, monitor it, and roll it back without rewriting the jobs themselves.

One Important Catch Though

Queue::forward() only affects newly dispatched jobs. Anything already sitting in the old queue stays there, so those jobs still need to be processed before you retire that queue.

Also, this is different from the pause feature in Laravel 13.25. Queue::forward() changes where jobs go, while the pause API controls whether queues are being consumed.

Same queue system, different job.