webman-tech/laravel-cache
Brings Laravel's cache component to webman, letting you use familiar Cache facades, stores, and drivers inside webman applications. Bridges existing Laravel cache code and configuration into webman's runtime so you can reuse what you already know instead of rewriting caching logic.
webman-tech/laravel-cache ports Laravel's Illuminate\Cache repository into the webman runtime, so you get Laravel's cache API (get/put/remember/tags/locks) backed by drivers you configure in a Laravel-style stores array.
Minimal setup:
composer require webman-tech/laravel-cache
Then install the plugin config so it lands under the webman plugin config path (webman-tech packages follow the config/plugin/webman-tech/<package>/ convention):
php webman plugin:install webman-tech/laravel-cache
Where to look first: the published config file. It mirrors config/cache.php from a Laravel app — a default key plus a stores map (array, file, redis, etc.) and a prefix. Read that file before anything else; it tells you which driver is active, whether keys are namespaced, and where the file store writes.
First use case: replace an ad-hoc file_get_contents/apcu_fetch cache in one hot endpoint with a Redis store and remember():
$config = Cache::store('redis')->remember('home:stats', 300, fn () => buildStats());
Start with the array store in a worker so you can validate your key/TTL logic without touching Redis, then flip default to redis.
Repository-first usage. Resolve a store once and reuse it for the request; keep the remember / rememberForever idiom rather than manual has/get/put triples — the callback form is where most of the value is, and it avoids the classic if (!isset($x)) race.
Tags for grouped invalidation. If you invalidate by domain ("all product listings"), reach for tags(['products'])->flush() rather than tracking key names. Note this constrains you to tag-capable drivers (redis, memcached, array) — the file and database stores throw on tags(), so don't design a tag-based invalidation scheme and then deploy on file.
Atomic locks for stampede protection. The expensive-query case is the one that bites in production: N workers all miss and all hit the database simultaneously. Wrap it:
Cache::lock('rebuild:stats', 10)->block(5, fn () => Cache::store('redis')->remember(...));
Locks only work on drivers that support them (redis, memcached, database, dynamodb) — the array Lock is a no-op that always "acquires".
Per-process memoization vs. shared cache. webman keeps workers alive across requests, so a two-tier pattern pays off: an array store as a request-local L1 in front of a Redis L2. Don't accidentally treat the array store as a real cache — it dies with the worker.
Warm up in onWorkerStart. Anything you'd normally warm in a Laravel service provider (config resolution, connection sanity check, preloading hot keys) belongs in onWorkerStart, not at file scope, so a bad Redis host fails at boot with a clear log line instead of on a user request.
Custom drivers. Use the manager's extend() to register a project-specific store rather than forking the package — the extension point is the same one Laravel exposes, and it keeps you upgradeable.
Pair with Eloquent caching. If you also run webman-tech/laravel-eloquent-style DB integration, cache repository-level results (query builders, DTOs), not Eloquent model instances with live relations — serialized models rehydrate inconsistently and bloat the payload.
12.0.0 shipped with no changelog body. The release is a bare compare link (11.0.0...12.0.0); a major bump on this package almost always means a bumped illuminate/* constraint or a PHP floor change, both of which can silently conflict with other illuminate components in a webman app. Pin "webman-tech/laravel-cache": "^12.0" only after diffing the tag yourself, and confirm your illuminate/cache/illuminate/support versions resolve to a single major — composer will happily install two and you'll get Class not found on facades or confusing interface mismatches.
Two Redis connection pools. webman's own redis plugin and this package's redis store each open their own connections, multiplied by worker count. On 8 workers you can double your connection footprint without noticing. Point the store at the same host but budget accordingly, and set pool limits deliberately.
Key prefixing is not automatic per app. If several services share a Redis instance and you haven't set prefix, remember('stats') in one app will collide with another's. Set the prefix explicitly in config; it's the cheapest bug you'll ever prevent.
TTL units. This is a Laravel-version-dependent footgun: modern put/remember take seconds, older codebases were written assuming minutes. Audit any ported code that passes 60 meaning "an hour". DateInterval is accepted and unambiguous — prefer it in shared libraries.
remember() re-executes on null and false. If your callback legitimately returns null ("no record"), it will run on every request. Wrap the result (['found' => false]) or use rememberForever with an explicit sentinel.
File store in a daemonized worker. The file store resolves paths relative to the app base path; under a supervisor/systemd cwd this can differ from what you tested. Use an absolute path and confirm the worker user owns it, or just use Redis in anything long-running.
Debugging resolution failures. When a driver misbehaves, inspect the resolved store rather than the facade: dump the manager's default store name and its underlying handler. Most "cache isn't working" reports in webman turn out to be a config file that wasn't picked up (plugin config not installed, or cached) rather than a driver fault.
Extension points worth knowing: custom driver via extend(), a custom serializer if you cache large objects, and the store's setEventDispatcher if you want hit/miss metrics wired into webman's event loop. These are usually enough to avoid patching the package — keep your changes on the outside so 13.0.0 is a one-line composer bump.
How can I help you explore Laravel packages today?