Defaults & overrides

Globally, in config

Set store / deferrer in config/http-client-rate-limits.php: every limit the manager builds uses them — the RateLimits facade, an injected manager, named profiles, compound arrays and every form of Http::rateLimit():

use RoundlyConsulting\HttpClientRateLimits\Store\CacheStore;

// config/http-client-rate-limits.php
'store' => CacheStore::class,
'cache_store' => 'redis',                   // any store from config/cache.php (null = default)
'cache_prefix' => 'http-client-rate-limits',

Per call site

RateLimits::usingStore() / usingDeferrer() return a configured copy of the manager, so the shared singleton is never mutated:

use RoundlyConsulting\HttpClientRateLimits\Facades\RateLimits;
use RoundlyConsulting\HttpClientRateLimits\Store\RedisStore;

$limits = RateLimits::usingStore(new RedisStore('cache'))->usingDeferrer(new MyDeferrer);

$limits->perMinute(30);

A copy that doesn’t override the store keeps sharing the manager’s config-resolved one, so hits still accumulate in one budget per process. RateLimits::releasingJob() is the same kind of copy, with the ReleaseDeferrer.

Per instance

use RoundlyConsulting\HttpClientRateLimits\Facades\RateLimits;
use RoundlyConsulting\HttpClientRateLimits\Store\RedisStore;

$middleware = RateLimits::perMinute(30);

$middleware->setStore(new RedisStore('cache')); // share limits across processes via Redis
$middleware->setDeferrer($myDeferrer);

Resolution order

• setStore() / setDeferrer() on an instance — always wins for that instance.
• RateLimits::usingStore() / usingDeferrer() / releasingJob() — for limits built from that manager copy.
• The store and deferrer config keys — everything else.