Laravel Redis Advisor Laravel Package

Getting Started

Install the package and run the report once before touching any config:

composer require --dev <vendor>/laravel-redis-advisor
php artisan vendor:publish   # pick the redis-advisor config tag
php artisan redis-advisor:report

Decide up front whether this belongs in require-dev (local triage + CI) or require (you intend to schedule it in production). The checks are read-only, so running it in production is viable, but the package only earns its place in production if you actually schedule it or gate the dashboard there.

Look at these first, in order:

1. The published config file — it defines which Redis connections get audited and the thresholds for big keys, TTL and backlog checks. Laravel's default setup routes cache, queue and session through the same default connection, which defeats several checks; add explicit connections here before you trust the output.
2. php artisan redis-advisor:report in text mode — this is your first real use case: a five-minute audit of an existing app. Read the "skipped" lines as carefully as the failures.
3. --format=json — the stable-ish machine interface you'll build CI and alerting on.
4. The Blade dashboard at /redis-advisor — local-only by default via the viewRedisAdvisor gate, so it works immediately in local and 403s everywhere else until you opt in.

Implementation Patterns

Local triage loop. Run text output, fix in severity order: eviction policy and reachability first (they invalidate everything downstream), then cache:clear blast radius and prefix collisions, then TTL and big-key hygiene. Re-run after each change — the checks are cheap.

CI gate. Add a step that runs redis-advisor:report --format=json --fail-on=<threshold> against a throwaway Redis service container, and archive the JSON as a build artifact. Do not append || true; the exit code is the entire point of --fail-on. Because the report describes the runtime environment of the process, CI against an ephemeral Redis mostly catches configuration drift in your committed config, not production reality — run it against a real staging instance on a schedule for the latter.

Split connections per concern. Configure cache, queue and session as distinct Redis connections (separate DBs or instances) in config/database.php, then list them all in the advisor config. This is what makes the cache:clear blast-radius and prefix-collision checks meaningful, and it mirrors the architecture you should have anyway.

Scheduled JSON report + notification. Wrap redis-advisor:report --format=json in your own artisan command, parse it, and push only fail/warn entries to Slack or your alerting channel. Keeping your own wrapper insulates you from pre-1.0 changes to the JSON shape and lets you add an allowlist for known-intentional findings.

Managed Redis (ElastiCache, MemoryDB, Upstash). These hosts disable CONFIG. The package reads settings from INFO first and skips checks it cannot perform, recording the reason. Treat this as the normal operating mode, not a degraded one — but make sure your parsing distinguishes skipped from pass.

Pair with Horizon. The queue checks (backlog, Horizon trimming) are most useful next to your Horizon config; set trim values deliberately and re-run to confirm the advisor agrees.

Gotchas and Tips

• skipped is not pass. On managed Redis a meaningful fraction of checks may not run. Surface skips in your alerting output or you'll get false confidence from a clean-looking report.
• Gate defaults to local only. In staging you'll get a 403 on /redis-advisor. Override viewRedisAdvisor in a service provider (or via the config) rather than editing the package's default, and never widen it to unauthenticated production access — the report leaks hostnames, key names and memory topology.
• Not free, just read-only. Big-key and TTL checks scan the keyspace. On a large instance, run off-peak or against a replica, and check whether the package samples rather than exhausts.
• "Keys without TTL" produces legitimate noise. Intentionally persistent keys (leaderboards, feature-flag snapshots, some lock implementations) will be flagged. Tune thresholds or maintain an ignore list; don't let it drown the real findings.
• The SESSION_LIFETIME comparison reads your runtime config. If your config cache in the audited environment differs from production, the session TTL check is comparing against the wrong number. Run it in an environment whose config:cache matches prod.
• cache:clear blast radius is the highest-value check. If cache and queue share a DB, a routine deploy can wipe queued jobs. This is worth verifying by hand once, not just trusting the report.
• Pin the version. v0.1.0 is pre-1.0: expect config keys, check names, JSON fields and --fail-on level names to shift. Use an exact constraint (0.1.*) and re-read the release notes on upgrade.
• Tune big-key thresholds before gating CI. Defaults that are reasonable for one app will fail the build on another; set them from a baseline run on a known-good environment.