Laravel Horizon is coming, so I'm looking to switch my queues from beanstalkd to Redis to take advantage of better queue monitoring.

However, occasionally I have to perform php artisan cache:clear. But if I do so, since my queue is now in Redis, it will wipe out all my jobs, as discussed in this GitHub issue.

The suggestion was to make a separate Redis instance. Here are my questions:

1. How do I create multiple Redis server instances in my Laravel Forge managed server?
2. What should I change in my config files so that session and cache point to one Redis server instance, and my queue points to a different Redis server instance? (now know the answer to this, see link in edit)
3. Is it correct that php artisan cache:clear will now only wipe out data in the Redis instance that my cache is using, and my queue worker Redis server will not be affected?

Edit

Upon searching the internet further, I've come across this discussion.

4. So I think I do not really need to create a separate Redis server instance, just use a different Redis DB number. Is this correct?
5. Does php artisan cache:clear wipe out only that DB number? Other DB numbers on the same instance are not affected?

Does php artisan cache:clear wipe out only that DB number?

This is accurate. The cache:clear command sends a FLUSHDB command to Redis under the hood which only erases the data in the Redis database selected for storing cache data.

The standard way to isolate data in a single Redis instance for each of Laravel's services is to assign a different database for each service in config/database.php:

'redis' => [ 
    'default' => [
        ... 
        'database' => 0, 
    ], 
    'cache' => [ 
        ...
        'database' => 1, 
    ], 
], 

The configuration above instructs Laravel to use database 1 for storing cache data, and database 0 for all other Redis operations. Then, when we want to clear the cache—using php artisan cache:clear or app('cache')->flush(), etc.—Laravel won't erase the other data stored in Redis.

We can extend this configuration pattern by creating separate connections that specify different Redis databases for each of the session, queue, and broadcasting APIs. This provides more flexibility to manage the data as our application grows.

Of course, for large applications, we might even use different Redis servers for each of these services to improve scalability as our application data exceeds the limitations of a single Redis server.