Using config to determine whether to use ThrottleRequests or ThrottleRequestsWithRedis

[Propaganistas]

How would you go to make the throttle middleware dynamic based on its environment (availability of redis)?
ThrottleRequests vs ThrottleRequestsWithRedis

This blows everything up:

->withMiddleware(function (Middleware $middleware) {
   if (config('cache.default') === 'redis') {
      $middleware->throttleWithRedis();
   }
})

This works, but I'm wondering if directly calling env() is desired...

->withMiddleware(function (Middleware $middleware) {
   if (env('CACHE_STORE') === 'redis') {
      $middleware->throttleWithRedis();
   }
})

The above is Laravel 11 code, but it applies as well to older Laravel versions using a HttpKernel.
I know it could be done in a ServiceProvider's boot() method by revisiting and replacing the already registered throttle alias, but I'm somehow tempted to try to register it early on properly...

[schonhoff]

Did you find a solution here?

[AmirHkrg]

Hi @Propaganistas

This fails because of a timing issue in the Laravel application lifecycle. Route files (and the bootstrap/app.php file that loads them) are parsed and registered before all the service providers have been booted.

The configuration for the cache driver (cache.default) is set up within a service provider (Illuminate\Cache\CacheServiceProvider). When your withMiddleware closure is executed, that service provider likely hasn't run yet, so config('cache.default') might not have its final, correct value. It might be null or the default from the base framework, causing your condition to fail.

You were on the right track thinking about a Service Provider. This is the cleanest, most robust, and idiomatic way to handle this. It ensures your logic runs at the correct point in the application lifecycle and respects the configuration system.

->withMiddleware(function (Middleware $middleware) {
   if (env('CACHE_STORE') === 'redis') { 
      $middleware->throttleWithRedis();
   }
})

This works because env() directly reads from your .env file (or the server's environment variables). This data is loaded very early in the bootstrap process via Dotenv.

However, as you suspected, this is considered bad practice in Laravel. The official documentation strongly advises against using the env() helper anywhere outside of your config/*.php files.

The main reason is configuration caching. When you run php artisan config:cache in production, Laravel compiles all your config files into a single cached file for performance. Once this cache exists, Laravel stops loading the .env file entirely, and any call to env() will return null. Your dynamic middleware would suddenly break in production.

Another method that comes to my mind is creating a custom middleware.
This approach creates a unified middleware that acts as a proxy. Its sole responsibility is to check the configuration during the request and delegate the task to the appropriate built-in Laravel throttle middleware.

public function handle(Request $request, Closure $next, ...$parameters): Response
{
    $throttleClass = config('cache.default') === 'redis'
        ? ThrottleRequestsWithRedis::class
        : ThrottleRequests::class;
    $throttleMiddleware = $this->container->make($throttleClass);

    return $throttleMiddleware->handle($request, $next, ...$parameters);
}

I hope I've provided some ideas; however, the provider approach is probably the best method.