Weave Code
Laravel Permanent Cache Laravel Package
backstage/laravel-permanent-cache
A Laravel package for permanent caching: store values indefinitely and retrieve them until explicitly cleared, with a simple API for persistent, long-lived cache entries across your application.
backstage/laravel-permanent-cache provides a permanent cache store for Laravel applications, enabling you to cache values indefinitely without a time-to-live. It’s designed for data that rarely changes—such as application settings, lookup tables, or expensive computed results—so you can avoid repeated database queries or API calls while retaining explicit control over when values are refreshed.
- No TTL expiration — items remain cached until you remove them.
- Laravel-native — integrates with the
Cachefacade and standard cache methods. - Manual invalidation — clear individual keys or flush the entire store.
- Simple setup — publish configuration and register the driver.
- Predictable persistence — ideal for stable, read-heavy data.
Frequently asked questions about Laravel Permanent Cache
- How do I install backstage/laravel-permanent-cache in a Laravel app?
- Install it with Composer: composer require backstage/laravel-permanent-cache. Laravel package auto-discovery registers the service provider, so there is no schema change or data migration to run. After that you wrap individual expensive call sites rather than replacing your existing cache layer, which keeps adoption additive and reversible.
- What is the difference between Laravel's permanent cache and Cache::remember?
- Cache::remember still expires: once the TTL lapses the next request pays the full cost again. backstage/laravel-permanent-cache keeps the stored value until you explicitly clear it, so expensive query results and rarely changing data stay warm indefinitely. That trades TTL-based freshness for predictable latency, so you need a deliberate invalidation policy. It is not a drop-in replacement for short-lived caches such as session or rate-limit data.
- Does backstage/laravel-permanent-cache support cache tags?
- Yes, tags are part of the advertised API, which lets you group related entries and invalidate them together instead of tracking individual keys. Tag support depends on the underlying store, so confirm your configured store handles tags before relying on them. On stores without tag support, fall back to explicit key-based clearing.
- Which Laravel and PHP versions does this package support?
- The package overview does not publish a Laravel or PHP version matrix, so check composer.json and the repository before committing. Pin an exact version and verify the require constraints against your application's PHP and Laravel versions. If the constraint range looks broad, test on your actual framework version rather than assuming compatibility.
- Which cache stores work with the permanent cache package (Redis, database, file, array)?
- The description names the database and filesystem as storage targets, and the package sits on top of Laravel's cache repository, so other configured stores may work as well. Redis and array stores are worth verifying directly in the repository if you need them, especially for tag support and eviction behavior. Test the exact store you plan to run in production.
- How do I clear a permanent cache entry, and can stale data live forever?
- Because entries never expire, invalidation is entirely your responsibility: clear individual keys or whole tags when the underlying data changes. Decide your eviction policy up front, since a failed refresh or stalled writer can leave users on stale data indefinitely. A configurable max-stale age or TTL fallback is worth confirming; if it does not exist, build one around the wrapper.
- Does this package require a queue worker to refresh cached values?
- The design serves the last-known value immediately and recomputes expensive data in the background, which per the technical evaluation depends on a healthy queue and worker pool. Without workers, the background half degrades into a permanently stale cache with no self-healing. Confirm the package provides stampede protection so overlapping refresh jobs do not duplicate one recompute for the same key.
- Can I use permanent caching for balances, inventory counts or entitlement checks?
- No. Balances, inventory counts and entitlement checks need strong read consistency, and serving a stale value there is a correctness bug rather than a latency tradeoff. Use it for read-heavy, tolerant data such as dashboards, catalog pages, aggregated reports and third-party API fan-out. Keep anything transactional on a normal, TTL-bounded cache or direct queries.
- How is this different from Laravel 11's Cache::flexible()?
- Laravel 11 ships Cache::flexible(), which already implements stale-while-revalidate natively. The real question is what this package adds beyond the framework primitive, such as never-expiring keys, tags and a simplified API. Run a time-boxed spike comparing both plus a hand-rolled remember-and-dispatch pattern, and choose based on measured latency and code delta.
- Is backstage/laravel-permanent-cache safe to use in production, and how is it maintained?
- The package has very few stars and no dependents, so production validation is thin and the bus factor is likely one. The MIT license at least lets you fork it if maintenance stops. Adopt behind a feature flag on one non-critical, high-traffic read path first, with queue alerting enabled, before expanding to your top expensive call sites.
Weaver
How can I help you explore Laravel packages today?