Redis Manager Laravel Package

Getting Started

• Confirm the stack first. This extension targets encore/laravel-admin 1.x and Laravel 5.5–7.x. Last tagged release is 2019-12-11 and the repo has no dependents, so treat it as a frozen artifact: verify PHP version compatibility before adding it to a working project.
• Install and import the menu/permissions in one pass:

  composer require laravel-admin-ext/redis-manager
  php artisan admin:import redis-manager
  

• Enable it in config/admin.php under the extensions key — it ships disabled by default ('enable' => false). Gate it on an env var so production stays closed unless you explicitly open it:

  'extensions' => [
      'redis-manager' => [
          'enable' => env('ADMIN_REDIS_MANAGER', false),
      ],
  ],
  

• Read the package source before configuring. vendor/laravel-admin-ext/redis-manager/src is small; the service provider, the controller, and the config keys it actually reads are the fastest source of truth. Config key names and the multi-server shape differed between the 2018 and 2019 tags, so don't trust blog posts.
• Look first at: routes.php (to see the URI it registers, typically under /admin/redis-manager), the RedisManagerServiceProvider (menu + permissions registration), and the blade views (to see which Redis client API is used — phpredis vs predis).
• First real use case: open the panel, hit the Keys browser, and search a concrete pattern you care about right now — e.g. laravel_cache:* for cache, laravel_database_queues:* for queues, or *session*. Inspect one key's TTL and value, then go to the server Info tab and check used_memory_human and evicted_keys. That 60-second loop is the whole value proposition of the package.

Implementation Patterns

• Treat it as an ops console, not a data editor for application models. The strongest day-to-day pattern is: cache/queue/session triage, TTL inspection, and running read-only INFO-family commands. Reach for the value editor only on small, human-readable keys (feature flags, config blobs, counters).
• Point the panel at the same connection the app uses. If the extension reads the redis connection from config/database.php, keep host/port/password/database aligned with REDIS_HOST / REDIS_PORT / REDIS_PASSWORD / REDIS_DB env vars. A panel that shows DB 0 while the app writes to DB 1 will cost you an hour of confusion.
• Scope it per role via laravel-admin permissions. admin:import registers the menu and permission entries; assign the Redis menu only to a ops or dev role. If you need finer control, add middleware to the extension route in app/Admin/routes.php (or override the route entirely with your own controller pointing at the package views).
• Use a restricted Redis user (Redis 6+ ACL) for the panel. Create a user with +@read +info +scan +slowlog and no +@write +@dangerous. This is the cheapest way to neutralize the FLUSHDB / DEL buttons, and it survives anyone forgetting the permission config.
• Console-first debugging. The command runner is the fastest way to answer "is this Redis healthy": INFO memory, INFO stats, SLOWLOG GET 10, CLIENT LIST, DBSIZE, SCAN 0 MATCH prefix:* COUNT 100. Keep a small runbook of these in your team wiki rather than clicking through tabs.
• Pattern workflow for key hunting: search with a narrow prefix and a COUNT, not *. Confirm you're on SCAN rather than KEYS by watching Redis INFO commandstats while you type — if cmdstat_keys climbs, stop searching broadly.
• Pair it with Horizon/Telescope, don't replace them. Horizon shows queue workers; redis-manager shows the raw queues:* payloads and their TTLs. Together they resolve stuck-job incidents much faster than either alone.

Gotchas and Tips

• KEYS on a large dataset will stall your app. Some versions of the key browser fall back to KEYS pattern for searches. On any Redis holding more than a few hundred thousand keys, use a prefix that the index can narrow, or drop into the console and run SCAN manually. Never demo a * search against production.
• Laravel-serialized values look like garbage. Cache and session entries are PHP-serialized (and often compressed if cache.serializer is set), so the value pane shows binary noise. That's expected — use php artisan tinker + Cache::get() when you actually need to read the decoded payload, or check the laravel_cache: prefix and strip it mentally.
• The DB index matters more than anything else. Cache, sessions, queues, and Horizon each commonly live in different logical DBs. If a key "doesn't exist," check the selected DB before you check the connection.
• Destructive buttons are one click away. FLUSHDB and key deletion have no confirmation worth relying on. Either restrict with ACLs (above) or only enable the extension on a staging host.
• Not maintained → expect friction on modern stacks. PHP 8 typed-property issues, str_* helper removals, and newer Laravel container signatures are plausible failure points. If the panel 500s, check storage/logs/laravel.log first; keep APP_DEBUG=true only in local/staging while diagnosing.
• admin:import can duplicate menu entries if run twice. Clean up admin_menu rows rather than re-importing.
• Broken styling = unpublished assets. If the panel renders unstyled, publish the package assets to public/vendor/laravel-admin-ext/redis-manager and confirm config/admin.php's asset path isn't rewritten by your deploy.
• No cluster or Sentinel support. If you're on Redis Cluster, this panel will connect to one node and show you a partial keyspace. That's a hard limitation, not a config bug — use redis-cli --cluster instead.
• Extension points are thin by design. The practical overrides are: (a) swap the route in app/Admin/routes.php to your own controller, (b) publish/copy the package's views and edit them in place, (c) replace the config source by binding your own array. There's no plugin architecture — don't plan around one.