- How do I install namoshek/laravel-redis-sentinel?
- Install it with Composer using composer require namoshek/laravel-redis-sentinel at ^1.3. The service provider is auto-discovered, so no manual registration in config/app.php is required. There are no migrations or published config files involved; everything is configured through config/database.php. After installing, define a distinct named Redis connection that uses the Sentinel driver.
- Does Laravel support Redis Sentinel natively, and do I still need this package?
- Modern Laravel versions support Sentinel natively through the sentinel key in the redis config for both phpredis and Predis. This package overlaps with that capability, so verify whether your target Laravel version already covers your topology before adding the dependency. If native support works for you, staying on it avoids a maintenance surface you would otherwise own. Choose the package only when it covers a scenario your framework version does not.
- How do I configure the Sentinel connection in config/database.php?
- You add a separate named connection inside the redis array of config/database.php, pointing at your Sentinel host and port set plus the service name for the master. Sentinel-level options belong in that same connection's config. Keeping it as a distinct named connection means rollback is a config change rather than a code revert.
- Which Laravel versions does this package support?
- Release v1.3.0 added explicit Laravel 13 support, and earlier releases tracked previous framework versions. Check the composer.json constraint to confirm it is a range that includes your target version rather than a pinned version. Teams already on v1.2.0 can upgrade in place because v1.3.0 contains no breaking changes, deprecations, or config-key renames.
- Does it work with both phpredis and Predis?
- The package plugs into Laravel's Redis manager, which supports both phpredis and Predis clients. Before relying on it in production, confirm that the specific client you use is exercised by the package's test matrix. That is one of the checks to make during a non-production trial against a real Sentinel quorum, along with verifying the composer.json constraint resolves against your Laravel version.
- How does failover work and will Laravel reconnect to the new master automatically?
- The package resolves the current master through Sentinel and builds the connection against that resolved address, so connections follow a failover instead of pinning to a stale host. Discovery runs through the custom connector and connection class registered by the service provider. Test the behavior against a real Sentinel quorum with an induced master failover before cutting production workloads over.
- Can I use it for cache, queues, and sessions?
- The package is transparent to consumers: cache, queue, and session code keeps using the Redis facade and named connections exactly as before. The recommended rollout is to cut over one workload at a time while keeping the original connection defined for fast rollback. No schema changes, published migrations, or worker restarts beyond a normal deploy are involved.
- How do I test a Sentinel setup without breaking production?
- Validate in a non-production environment against a real Sentinel quorum, including an induced master failover, rather than relying on mocks alone. Keep the existing non-Sentinel connection defined during the trial so you can roll back instantly. A local Docker setup with one Redis master, replicas, and three Sentinels is the usual way to exercise this safely.
- What are the alternatives to namoshek/laravel-redis-sentinel?
- The main alternative is Laravel's native Sentinel support via the sentinel key in config/database.php, which covers both phpredis and Predis. Managed offerings such as AWS ElastiCache or Azure Cache handle failover internally and typically do not need this package at all. Single-node Redis deployments get no value from it either, so it should be rejected on scope grounds there.
- Is this package still maintained?
- Release v1.3.0 is a minor version adding Laravel 13 support, alongside Dependabot bumps to CI actions that have no runtime impact for consumers. That release cadence shows the package is tracking the framework rather than being abandoned. The Laravel 13 compatibility change was contributed by Copilot, so a quick human review of the diff is worthwhile before adopting. Decide internally whether application platform or infrastructure owns future upgrades.