- What does the laravel-cache-evict package do?
- Laravel treats cache expiry as logical: once a TTL elapses the key is unreadable, but for stores like database, file and DynamoDB the underlying row, file or item can stay behind. laravel-cache-evict adds a scheduled housekeeping command that physically removes those already-expired entries, reclaiming storage. It is not a cache store of its own and should not sit on the read/write path, so it can be removed without touching application code.
- How do I install laravel-cache-evict?
- Install it with Composer, for example composer require vectorial1024/laravel-cache-evict. The service provider is expected to be auto-discovered; if the package ships a config file, publish it with php artisan vendor:publish and adjust the store and prefix settings. Then register the eviction command in the scheduler. Realistic integration effort is measured in hours, not sprints.
- How do I schedule the cache eviction command in Laravel?
- Register the package's artisan command from your scheduler, either in routes/console.php on Laravel 11+ or in app/Console/Kernel.php on older versions. Chain withoutOverlapping() so a slow sweep cannot start again while the previous one is still running, and run it off-peak because deletion contends with traffic on the cache table or directory. Daily or hourly is usually enough, since the entries being removed have already expired.
- Which cache drivers does laravel-cache-evict support?
- It is aimed at drivers where expired entries persist as real storage cost, primarily database and file, and to a lesser degree DynamoDB. For Redis and Memcached the backend already reclaims expired keys, so the package adds little. Confirm the supported driver list and the enumeration strategy in the package source before relying on it, because that detail decides whether a sweep is cheap or dangerous.
- Is laravel-cache-evict safe to run in production?
- Deletion is the point of the package, so the risk to weigh is an over-broad sweep that also removes live entries and triggers a thundering herd against your origin database. Run it in staging against a representative dataset first, verify that deletion is conditional on expiry, and schedule it off-peak with overlap protection. A correctly scoped run only removes keys whose TTL has already elapsed.
- Does laravel-cache-evict work with Redis or Memcached?
- There is little value there. Redis and Memcached already reclaim expired keys themselves, whether lazily on access or through active expiry cycles. The package exists for stores that persist expired data as files or rows and therefore accumulate garbage. If you use only Redis, the backend's own eviction policy plus Laravel's cache commands cover you.
- Will evicting expired cache entries cause a cold cache?
- Not if deletion is conditional on the entry having actually expired, which is the behavior to verify in the source. Removing an already-unreadable key changes nothing for reads, because Laravel would have treated it as a miss anyway. The danger only appears if the sweep is too broad and clears still-valid entries, so test that case explicitly and watch the cache hit rate after the first runs.
- Which Laravel and PHP versions does laravel-cache-evict support?
- Release 2.1.2 relaxed the PHP version floor, which helps if your estate runs mixed runtimes, but that says nothing about Laravel compatibility. Check the illuminate/support and illuminate/contracts constraints in the package's composer.json against your own Laravel version. Verify against the repository rather than the release notes, since the notes are terse.
- Does it respect the cache prefix and multiple stores in multi-tenant apps?
- That is a question to answer from the source before adopting. A safe implementation goes through Laravel's cache store contracts so it honors the configured key prefix and store name, and cannot reach another tenant's keyspace. If it uses raw driver access instead, confirm the prefix is applied explicitly. In a multi-tenant deployment, test that every sweep is scoped to the intended store only.
- Is laravel-cache-evict actively maintained, or should I write my own command?
- Adoption is very low, at roughly 59 stars, so expect de facto self-support and audit the code yourself. The feature is small enough to review in an afternoon and cheap enough to replace with an in-house artisan command if maintenance stalls, which caps the downside. Also verify the stated last release date against the repository's tag history before treating it as evidence of activity.