Laravel Valkey Glide Laravel Package

Product Decisions This Supports

• Cache/session backend strategy (Valkey vs. Redis). The package is a Laravel driver/adapter over Valkey Glide (AWS's Rust-based, multi-threaded Valkey/Redis client). It makes "move our cache/session layer to Valkey" a configuration change rather than an application rewrite — relevant if you're hedging against Redis licensing (RSALv2/SSPL history) or standardizing on ElastiCache/MemoryDB for Valkey.
• Framework upgrade roadmap. Laravel 13 support landed in v1.1.0 and the package has since shipped two further releases (v1.1.1, and v1.2.0 on 2026-10-21), so it is tracking current Laravel rather than pinning it. If Redis/Valkey sits on the critical path of your Laravel upgrade, this package is not the blocker — keep it as a line item in upgrade planning and the dependency-risk register, but not a red one.
• Build vs. buy on the driver layer. The alternative is maintaining a bespoke Valkey client wrapper plus its cluster/TLS/auth handling. This is a thin adapter that keeps your existing Cache::, Session, and queue configuration semantics — a "buy" with low switching cost (config swap back to predis/phpredis is a rollback path).
• Infrastructure choices that depend on client capabilities. Cluster mode, TLS, IAM authentication, and connection pooling are the differentiators of Glide over a plain PHP extension. v1.2.0 deepens exactly this: cluster connections can now configure periodic topology checks (#78) and executeRaw is correctly routed on cluster connections (#80) — both are prerequisites for cluster-mode ElastiCache/MemoryDB Serverless, not nice-to-haves.
• Operational resilience / on-call burden. v1.2.0 adds client lifecycle and reconnect control: replaced clients are closed on reconnect and Glide's reconnect strategy is now exposed as configuration (#82). That turns "how does the app behave during a Valkey failover or node replacement" from opaque library behavior into something we can tune, test, and document in a runbook.
• Configuration safety and blast-radius. v1.2.0 rejects an incomplete iam block instead of silently dropping IAM auth (#84). This is a fail-fast correctness fix — previously a partially specified IAM config could quietly fall back to unauthenticated connectivity. Good for production safety; a config-compat item to check on upgrade (see below).
• Performance/latency SLO work. Glide's Rust core and multi-threaded connection handling is a candidate lever for p99 cache latency under high fan-out, though this must be benchmarked in your own environment before it's used as a justification.
• Use-case fit: high-throughput cache, session store, and simple queue/pub-sub workloads, now with meaningfully better cluster and reconnect ergonomics. Still not a fit for teams relying on Redis module features (search, JSON, time series) or Sentinel-based failover.

When to Consider This Package

Adopt / pilot when:

• You're on a supported Laravel version (including Laravel 13) and run — or plan to run — Valkey, including AWS-managed Valkey.
• You need cluster-mode, TLS, or IAM-auth connectivity that would otherwise require custom client work. v1.2.0's cluster topology-check configuration and cluster-safe executeRaw routing remove two of the more common "just write it ourselves" arguments.
• Failover behavior is a review question. The exposed reconnect strategy and replaced-client cleanup mean you can specify and test reconnect semantics rather than accept defaults.
• You want to remove the operational burden of the phpredis C extension (build/deploy consistency across images, version drift between app and server).
• You've already decided Valkey is the target and the remaining question is only "how do we wire it into Laravel."

Look elsewhere when:

• You depend on Redis modules (RediSearch, RedisJSON, RedisTimeSeries) — Glide targets core Valkey, and the Laravel ecosystem around modules is thin.
• You need Sentinel-based HA or a non-managed, self-run topology where predis/phpredis are the well-trodden path. (v1.2.0 improves cluster behavior; it does not add a Sentinel story.)
• You require vendor SLAs, security review artifacts, or long-term support commitments. This remains a young, single-maintainer package — the correct posture is a time-boxed pilot behind a feature flag with a documented rollback to predis, not a default in the base image.
• Your Laravel version is outside the supported matrix, or you need Horizon/Telescope edge behaviors that assume a first-class Redis connection driver — validate those explicitly during the pilot.
• Cache is not on your critical path and the migration cost buys you nothing commercially.

Upgrade caveat for anyone already piloting (v1.1.x → v1.2.0): the IAM validation fix is intentionally a behavior change — an incomplete iam block now fails loudly rather than silently dropping IAM auth. Audit any environment where IAM config is assembled partially (env-var gaps, per-environment overrides) before upgrading; those will now error instead of degrading. Treat cluster topology-check and reconnect-strategy settings as new knobs to set deliberately and record in the runbook, not defaults to inherit silently.

Adoption gate (unchanged, now more testable): run a load test in staging against your actual Valkey topology, and confirm cluster failover, TLS, and reconnect behavior under fault injection before promoting past one non-critical service. v1.2.0 makes the reconnect half of that gate configurable, so it should be an explicit part of the pilot's exit criteria rather than an assumption.

How to Pitch It (Stakeholders)

For executives: We have an open question about our Redis dependency — licensing exposure and which managed cache we standardize on. This package lets us answer it with a configuration change instead of an engineering project: it plugs Laravel directly into Valkey, the open-source Redis fork our cloud provider now offers as a managed service. It also removes a recurring source of deploy friction (the compiled PHP Redis extension). The project is actively maintained — v1.2.0 shipped 2026-10-21, roughly three months after v1.1.0, and the recent work is concentrated on exactly the things that make a cache migration safe at scale: cluster topology awareness, reconnect behavior, and failing fast on misconfigured authentication. Cost to evaluate is still small — a time-boxed pilot on one non-critical service with a one-line rollback — and continued releases on the current Laravel line mean adopting it doesn't pin our framework upgrade.

For engineering: sinemacula/laravel-valkey-glide is a thin Laravel adapter over Valkey Glide, AWS's Rust-based client. You keep the existing Cache/Session/queue APIs and swap the connection config; you gain cluster-mode, TLS, and IAM auth support without hand-rolling a client, and you can drop the phpredis build step from our images. v1.2.0 (2026-10-21) is the most substantive release since we started tracking it: it closes replaced clients on reconnect and exposes Glide's reconnect strategy as config (#82), lets cluster connections configure periodic topology checks (#78), routes executeRaw correctly on cluster connections (#80), and rejects incomplete iam blocks instead of silently dropping IAM auth (#84). Read that last one as a hardening fix with upgrade implications — partial IAM configs that previously degraded silently will now error, so audit env-var gaps before bumping.

Caveats to plan around: single-maintainer project, small install base, no Sentinel story, and no Redis-module support. Proposal is a scoped pilot behind a flag with predis as the documented fallback, plus a benchmark and a failover test — with the new reconnect and topology settings explicitly configured and recorded as part of the pilot's exit criteria.