Laravel Rate Limiter Laravel Package

Product Decisions This Supports

• Abuse and quota enforcement roadmap: Supports decisions on login throttling, API rate limits, per-tenant quotas, and burst protection with atomic multi-window checks. The v6 fix preventing refused requests from consuming other windows directly reduces false lockouts and support burden.
• Build vs. buy: A Laravel-native limiter with Redis-backed atomicity, Laravel Redis manager support, cluster hash tags, TLS, REDIS_URL, Octane safety, and framework events is likely cheaper and lower-risk than building distributed multi-window limiting in-house unless requirements are highly custom.
• Customer-facing API contracts: Header changes in v6 (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) and new Retry-After on 429s are product-visible. This drives decisions on API documentation, SDK compatibility, and client retry behavior.
• Reliability and SLA posture: on_redis_failure (open / closed → 503) with backoff lets product teams choose between availability and strict enforcement during Redis incidents. This should be an explicit product risk decision, not an infrastructure default.
• Security defaults: The v6 default whitelist change from 10.0.0.0/8 to loopback only closes a serious bypass behind load balancers. This supports decisions on secure-by-default configuration and review of proxy/trusted-IP assumptions.
• Observability and incident response: RateLimitExceeded and IpBlocked events, plus reduced 429 error logging, enable alerting and analytics without flooding logs with request input/headers.
• Platform modernization: PHP 8.3+ and optional ext-redis align the limiter with current Laravel/PHP support and either phpredis or predis. This affects upgrade timing and platform roadmap.
• Use cases: Public API quotas, authenticated user limits, per-route limits, IP blocking, multi-window policies such as per-second/minute/hourly/daily, and tenant-aware limiting via middleware parameters or RateLimit::with().

When to Consider This Package

• Consider it when the product is a Laravel application using Redis and needs accurate distributed rate limiting across multiple windows, especially where a refused burst must not consume hourly/daily quota.
• Consider it when the team needs Laravel middleware ergonomics such as rate.limiter:60,1 or named windows (second=, minute=, hourly=, daily=) and key strategies like IP, user, route, or combinations.
• Consider it when running Laravel Octane, Redis clusters, TLS, REDIS_URL, phpredis or predis, and needing configuration that does not leak request state across workers.
• Consider it when product requirements include explicit fail-open/fail-closed behavior, rate-limit headers, retry guidance, events for monitoring, and safe handling of missing client IPs.
• Look elsewhere when the system is not Laravel/PHP, cannot standardize on Redis, or only needs trivial per-route throttling already covered by Laravel’s built-in limiter with no multi-window or atomicity requirements.
• Look elsewhere when the organization requires rate limiting at the edge/API gateway/WAF layer, needs non-Redis distributed backends, or cannot meet PHP 8.3+.
• Migration caution: v6 is breaking. Teams on v5 must budget for PHP 8.3+, renamed headers, removed methods (withRateLimitHeaders(), setRequestTag(), getRequestTag(), checkIpAddress()), removed redis.* connection settings, changed whitelist/default logging behavior, and middleware parameter validation. If a near-term upgrade is not feasible, defer adoption until the platform upgrade is scheduled.

How to Pitch It (Stakeholders)

• Executive summary: This package gives our Laravel services a hardened, Redis-backed rate limiter for protecting APIs, logins, and tenant quotas. v6 fixes several correctness and security issues that could otherwise cause unjustified lockouts or bypasses behind load balancers.
• Engineering summary: v6 makes multi-window checks atomic, prevents refused requests from draining other windows, honors named Redis connections, adds Laravel Redis manager support including cluster/TLS/REDIS_URL, makes builders immutable, and adds middleware parameters, events, LimitResult, RateLimiter::attempt(), and blockedFor(). It requires PHP 8.3+, renames headers, removes legacy methods/settings, and changes defaults to safer values.
• Product value: Better customer experience through fewer false lockouts, clearer 429 responses with retry guidance, and configurable fail-open/fail-closed behavior during Redis incidents. Security defaults improve without custom proxy logic.
• Cost/risk framing: Adopting v6 is a platform upgrade as well as a package upgrade. The main effort is PHP 8.3+, header contract updates, removal of deprecated APIs, and validating Redis configuration. The payoff is reduced abuse-handling bugs, safer defaults, and stronger operational controls.
• Recommendation: Approve evaluation for services already on PHP 8.3+ and Redis, with a migration spike for v5 users. Treat header changes and fail-open/fail-closed policy as product decisions requiring API documentation and incident-response alignment.