Redis Manager Laravel Package

Getting Started

encore/redis-manager is an admin-panel-style Redis browser for Laravel, built by the author of laravel-admin. It is not a Redis client abstraction — your application code still uses Illuminate\Support\Facades\Redis as normal. The package just bolts a web UI onto the connections already declared in config/database.php.

Minimal setup:

composer require encore/redis-manager

It expects laravel-admin (encore/laravel-admin) to already be installed and bootstrapped in the project — this is the single biggest prerequisite and the reason most people bounce off it. Then:

php artisan vendor:publish --provider="Encore\RedisManager\RedisManagerServiceProvider"

On Laravel <5.5, or if auto-discovery is disabled, add Encore\RedisManager\RedisManagerServiceProvider::class to config/app.php. Confirm the routes registered correctly before hunting for a menu item:

php artisan route:list | grep -i redis

Where to look first:

1. The published config file (route prefix, middleware, and which Redis connections are exposed).
2. The laravel-admin sidebar — the package typically registers itself as a menu entry, so you log in as an admin user rather than hitting a bare URL.
3. config/database.php → redis — the manager reads these connections verbatim, including options.prefix.

First use case: open the panel, pick the default connection, browse keys, click into a hash or sorted set, and use the built-in console to run a GET/TTL/HGETALL against a key you're debugging. That replaces an SSH session for the 90% case of "what is actually in this cache key?"

Implementation Patterns

Treat it as an internal dev/staging tool, not application code. Nothing in your models, jobs, or service providers should ever import from Encore\RedisManager. It's a sidecar UI. The healthiest pattern is: add it to require-dev, install it on staging, and keep it out of the production dependency graph entirely.

Scope which connections are visible. The manager exposes whatever Redis connections you point it at. If you have a cache, session, and queue connection plus a separate analytics Redis, explicitly limit the config to the ones you want browsable — otherwise a junior dev can FLUSHDB the session store while trying to clear a cache key.

Lock it down with middleware. The published config lets you set middleware on the package routes. Stack your admin auth guard plus an IP allowlist:

// in the package config, something like:
'middleware' => ['web', 'admin', 'can:manage-redis'],

Register a can:manage-redis gate that checks app()->environment(['local', 'staging']) and the admin user's role. This is a one-line guard against the classic "Redis browser left open on the internet" incident.

Debugging queue and cache behaviour. The day-to-day win is inspecting Laravel's own key shapes. Because Laravel prefixes keys with the connection's options.prefix (often derived from APP_NAME), search for laravel_database_ or your app prefix rather than the raw key. This is the fastest way to answer "did the job actually dispatch onto the queue?" or "is this cache tag being invalidated?"

Pair it with redis-cli for anything scripted. The manager is for eyeballing and one-off edits. Bulk operations, SCAN-based cleanup, and anything reproducible belongs in a command or a tinker session. Don't let the UI become the runbook.

Use laravel-admin's permission system if you already run that panel — it gives you per-role access to the Redis menu without writing custom middleware, which is the main integration payoff of the package.

Gotchas and Tips

It is effectively unmaintained. Last release April 2018, zero dependents, and it targets the Laravel 5.x / laravel-admin 1.x era. On PHP 8 and Laravel 9+, expect fatal errors from removed framework APIs and the encore/laravel-admin transitive dependency. Before committing, test composer require on a throwaway branch and check whether it resolves at all. If it doesn't, the realistic options are (a) fork and patch, or (b) use redis-cli, RedisInsight, or phpredisadmin instead. Be honest with your team about this — a package that costs two days of patching to save ten minutes a week is a bad trade.

KEYS * will hurt you. Key listing against a production Redis with hundreds of thousands of keys can block the single-threaded server and time out the request. If the key browser hangs, that's why. Prefer browsing on staging, or narrow down by pattern before loading a list.

The console is a loaded gun. Anything the UI can do, it can do destructively — FLUSHALL, CONFIG SET, DEL on a range. There is no read-only mode shipped. If you need one, fork the controllers and strip the write endpoints, or put the routes behind a gate that only allows GET-style operations for non-owner roles.

Route and asset caching bite after deploy. Run php artisan config:cache and php artisan route:clear after publishing config, and re-publish assets (vendor:publish --tag=... --force) after any package update — the panel's JS/CSS lives in public/vendor/ and stale assets produce a blank page with no obvious error.

Debugging checklist when the panel is blank or 404s: route:list to confirm registration, check config/app.php for the provider, check the laravel-admin admin guard is authenticated, then storage/logs/laravel.log. Nine times out of ten it's the provider not registered or the admin middleware rejecting you.

phpredis vs Predis matters. If the underlying connection uses the Predis client, some command/response handling in an old UI can misbehave on binary values or non-string types. Switch the connection to the phpredis extension for the cleanest results.

Extension point worth knowing: the package is thin — controllers, a service provider, a couple of views. If you need to add features (key TTL editing, export to JSON, a read-only toggle), forking and editing the controllers directly is far faster than trying to extend it through config. There is no meaningful public API to hook into.