- What is oro/redis-config used for in a Laravel application?
- It is intended to centralize Redis configuration so you define connections, key prefixes, and client options in one place instead of hand-editing the redis block in config/database.php. The goal is predictable, environment-aware switching between local, staging, and production Redis instances for cache, session, and queue backends. It is a configuration and wiring layer, not a Redis client or cache implementation, so it still delegates to Predis or the phpredis extension underneath.
- How do I install oro/redis-config with Composer?
- Add it with composer require oro/redis-config and rely on Laravel package auto-discovery to register the service provider. Publish the bundled configuration with php artisan vendor:publish and then drive the values from your .env file per environment. Because the package has had no releases for several years, run the install in a throwaway branch first and confirm Composer resolves against your current Laravel and PHP baseline before committing.
- Does oro/redis-config support multiple Redis connections such as cache, session, and queue?
- Yes, the package is built around defining multiple named connections so the default, cache, session, and queue consumers can each point at a different Redis database or host. That separation matters because it lets you size and failure-isolate each workload independently instead of sharing one logical database across everything. Keep in mind that splitting connections does not by itself give you failover; each endpoint still needs its own availability plan.
- Which Laravel and PHP versions does oro/redis-config support?
- There is no published compatibility matrix, and the most recent release dates to August 2020, so no current Laravel or PHP version can be assumed to work from the version constraint alone. Package auto-discovery support implies Laravel 5.5 or newer, but that is an inference, not a guarantee. Prove support with a spike on your exact target stack, and add a regression test that boots the app and writes and reads a key through each configured connection.
- Is oro/redis-config a Laravel package or an OroPlatform Symfony bundle?
- The package description and auto-discovery notes position it as a Laravel package, but the repository belongs to the Oro organization and technical review of its history and structure identifies it as an OroPlatform Symfony bundle that wires Redis as an application cache backend. Treat that discrepancy as a red flag and inspect the source before adopting it. If your application is Laravel rather than OroPlatform, the package's value drops to a small amount of configuration you can reproduce directly.
- How does automatic key prefixing work and why does it matter?
- The package applies a configurable prefix to every Redis key so two applications, or two environments, can share a Redis instance without overwriting each other's cache and session data. This is the same option Laravel exposes as options.prefix in the redis configuration, so the package is mainly standardizing where that value comes from. Set a distinct prefix per environment and per app, and be aware that changing a prefix invalidates all previously cached keys.
- Does oro/redis-config support Redis Cluster, Sentinel, TLS, and ACL authentication?
- The package description states compatibility with cluster and sentinel configurations, but it does not document TLS or ACL username and password support, and the underlying client version effectively determines what is possible. Verify against your actual Redis server version rather than relying on the overview text, since cache misconfiguration tends to surface as silent serialization errors instead of clean exceptions. If you need ACL or TLS today, test the specific client binding the package uses before you depend on it.
- How should I test a Redis configuration change before it reaches production?
- Introduce it cold and reversibly: enable Redis for one low-consequence cache pool in a non-production environment while keeping the existing file or APCu cache configured as a fallback, then expand pool by pool in ascending order of blast radius. Validate that cache reads, writes, TTLs, and prefix behavior all work, and confirm what happens when Redis is unreachable, because a misconfigured cache layer can prevent the application from booting or serving requests. Leave sessions on their current backend until the cache rollout has run cleanly in production for a while.
- What are the alternatives to oro/redis-config for configuring Redis in Laravel?
- Laravel's built-in redis configuration block in config/database.php already supports multiple connections, prefixes, clusters, and both phpredis and Predis with no extra dependency. For most Laravel projects the native configuration plus a config caching step in deployment covers everything this package advertises. If you are on Symfony instead, use symfony/cache with the Redis adapter and framework.cache configuration directly rather than introducing a bundle with unclear maintenance.
- Is oro/redis-config actively maintained, and what license does it use?
- No releases have shipped since August 2020, it has a single-vendor provenance tied to Oro's internal release cadence, and the repository carries no recognized SPDX license identifier. That last point is a legal gate rather than a code-quality nit, so get written clarification from the maintainer or treat the package as non-redistributable until it is resolved. For new work, prefer an actively maintained path unless you are already inside an OroPlatform application where this is the first-party option.