- Is webman/redis a Laravel package I can drop into a Laravel app?
- No. webman/redis is the Redis component for the webman framework, which runs on Workerman worker processes, not Laravel. It ships no service provider, no Laravel facade, and no integration with Laravel's RedisManager, Horizon, queue worker, session, or broadcast drivers. It may sit on top of illuminate/redis internally, but the configuration surface and connection lifecycle are webman-specific. For a Laravel application, use Laravel's first-party phpredis or predis driver instead.
- How do I install and configure webman/redis?
- Install it with Composer inside a webman project and define your connections in config/redis.php. Once configured, commands are issued through the support\Redis static API, so calls like Redis::set() or selecting a named connection look familiar to anyone used to Laravel's Redis facade. There is no service provider registration step because webman bootstraps the component itself. Confirm the exact Packagist vendor name and composer.json before adding it to a lockfile.
- Does webman/redis work with Laravel's RedisManager, Horizon, queues, or sessions?
- No. Laravel's queue, session, cache, and broadcast integrations are wired to Laravel's own RedisManager and its connection lifecycle, which webman/redis does not implement. There is no adapter shipped for those contracts, and writing one would mean maintaining a parallel Redis layer with its own config surface and failure modes. If your service is a Laravel service, the native driver is the documented and battle-tested path.
- Which Redis client does webman/redis wrap — phpredis, Predis, or both?
- The package is documented as compatible with the native phpredis extension, while the broader description also references ext-redis or Predis support. Because the underlying client determines TLS behavior, cluster redirect handling, and reconnect semantics, confirm explicitly which client is used in your configuration. Mixing phpredis in one service and Predis in another across an estate creates behavioral drift that tends to surface during incidents. Verify this with the maintainer or by reading the source before committing.
- How does the connection pool in webman/redis work and why does it matter?
- webman runs PHP in long-running Worker processes, so a Redis socket opened once can be reused across many requests instead of being reconnected per request. webman/redis provides a built-in pool that hands out and returns connections to avoid exhausting Redis under concurrency. That pooling is the main reason the component exists, and it is also the reason lifecycle bugs are subtle: a stale or half-closed connection surfaces only under sustained load. Validate reconnect behavior explicitly in staging.
- Does webman/redis support multiple connections, clusters, and Sentinel?
- Multiple named connections and multiple Redis databases are supported, and the package documents cluster and sentinel configurations plus lazy connections. Whether failover, CLUSTER/MOVED redirects, and reconnect-after-idle are handled natively or delegated to the underlying client is not clearly specified. Given the near-zero community validation on this repository, assume these paths are untested at scale and prove them yourself. Force a failover and a redis-cli CLIENT KILL in staging before relying on them.
- What PHP and Workerman versions does webman/redis support?
- The package does not publish a clearly documented tested matrix covering PHP versions, Workerman 4 versus 5, or Swoole and Swow coroutine runtimes versus vanilla Workerman. Since the coroutine model changes how connections are shared across concurrent tasks, an untested combination is a real risk. Check the composer.json constraints directly rather than trusting release metadata. If you run a coroutine runtime, benchmark pool behavior under concurrency before rollout.
- Is webman/redis production-ready, and who maintains it?
- It is the canonical Redis component for the webman ecosystem and is published under the webman-php GitHub organization, which is the right provenance signal. However, this particular repository shows a single maintainer, around one star, and zero dependents, which is inconsistent with the visibility you would expect from the official component. Before adopting, verify the Packagist vendor entry, the composer.json name and homepage, the commit history, and the release tags. Pin an exact version in composer.lock and keep a documented upgrade ritual rather than floating a caret constraint.
- Should I standardize on webman/redis across my Laravel services too?
- No. Introducing a second Redis client into a Laravel service buys you nothing and costs you two configuration surfaces, two failure modes, and two upgrade paths. Laravel's predis and phpredis integration is first-party, documented, and widely exercised, including by Horizon and the queue workers. If you operate mixed runtimes, accept two Redis layers rather than forcing one, and align on the underlying client type per runtime so TLS and cluster behavior stay predictable.
- How should I safely test or migrate to webman/redis?
- Work on a spike branch, never main: install the package, point it at a staging Redis instance, and exercise read/write, a pipeline, a pub/sub subscribe loop, and a forced redis-cli CLIENT KILL to observe reconnect behavior. Wrap the package behind an internal CacheClient or QueueClient interface so swapping back to raw illuminate/redis or a fork is a one-file change. Run it in parallel with your existing client before cutting over, and only proceed if the target runtime is genuinely webman. If the target is Laravel, stop here and use the native driver.