Weave Code
Rate Limit Bundle Laravel Package
perimeter/rate-limit-bundle
perimeter/rate-limit-bundle adds configurable rate limiting to Symfony applications, helping protect APIs, controllers, and routes from abuse. Define limits, choose storage, and throttle requests with minimal setup and flexible integration.
Perimeter RateLimitBundle
Frequently asked questions about Rate Limit Bundle
- Can I use perimeter/rate-limit-bundle in a Laravel application?
- No. perimeter/rate-limit-bundle is a Symfony bundle, not a Laravel package. It relies on Symfony bundle registration, the DI container, and kernel.request event listeners, none of which Laravel provides, so there is no drop-in integration path. At most, a small amount of throttling logic could be lifted out and rewritten, which is not worth it. For a Laravel app, use the framework's first-party rate limiter instead.
- Is perimeter/rate-limit-bundle still maintained?
- No. The last tagged release was 2015-02-27, roughly a decade ago, and it targets the PHP 5.x and Symfony 2.x era. The repository has around 41 stars and zero dependents, so there is no production validation and no evidence anyone runs it today. There is also no maintainer answering issues and no CVE disclosure process.
- Does perimeter/rate-limit-bundle support PHP 8 and current Laravel versions?
- No. The code predates PSR-11 adoption, PHP 7 scalar types, and Symfony Flex, so it will not run cleanly on PHP 8.x due to dynamic property deprecations and removed APIs. Laravel support is not a question of version compatibility but of architecture: it is a Symfony bundle and cannot register itself in Laravel at all. Even on Symfony, you would need a compatibility fork spanning autoloading, container compilation, and event dispatcher signatures.
- How do I install perimeter/rate-limit-bundle with Composer?
- You would run composer require perimeter/rate-limit-bundle, but in a Laravel project nothing will happen afterwards. Laravel's package auto-discovery looks for a service provider, and this bundle ships Symfony bundle classes instead. You would have to manually build the entire wiring layer, which is the reason the integration is not feasible. Composer will happily install it; your application still will not use it.
- What is the Laravel equivalent of perimeter/rate-limit-bundle?
- Laravel has shipped a first-party limiter for years: Illuminate\Cache\RateLimiting\RateLimiter, configured with RateLimiter::for() in a service provider and applied with the throttle:<name> middleware. It supports named limiters, per-key segmentation by user ID, API token, IP, or tenant, and returns standard client feedback headers. Back it with Redis for shared state across instances. No third-party package is required.
- How do I add rate limiting to Laravel API routes?
- Define a named limiter in a service provider using RateLimiter::for(), returning a Limit with the max attempts and decay window, then attach throttle:<name> to your API route group in routes/api.php. Derive the limiter key from the request so each user, token, or tenant gets its own bucket. Set the cache driver to Redis or Memcached if limits must be shared across servers. This replaces the entire capability the bundle was meant to provide.
- Can rate limit counters be shared across multiple servers with Redis?
- Yes, in Laravel this is handled by pointing the cache store used by the rate limiter at Redis or Memcached, so counters are shared across all application instances behind your load balancer. This is a configuration change, not a code change. The Symfony bundle had a storage abstraction for similar purposes, but you cannot reuse it in Laravel. Decide early whether per-instance limiting is acceptable or shared state is mandatory, since it changes your infrastructure requirements.
- Does rate limiting return 429 responses with Retry-After and X-RateLimit headers?
- Laravel's throttle middleware returns HTTP 429 with the appropriate retry information when a limit is exceeded, and the RateLimiter exposes the remaining attempts and reset time so you can emit X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers. That standards-compliant feedback is what API consumers and SDKs expect. A 2015-era Symfony bundle predates these conventions being standardised in practice, so you would have to add the headers yourself. Specify the exact header contract before writing any limiter code.
- Is it safe to fork perimeter/rate-limit-bundle since it is MIT licensed?
- The licence is permissive and forking is legally clean, but it is not a good use of engineering time. Modernizing the code to PHP 8 and a supported Symfony release means touching autoloading, container compilation, and event dispatcher signatures. The estimated effort exceeds writing the limiter from scratch against a maintained first-party component. It also leaves you owning the fork forever, with no upstream security response process to rely on.
- What are the best alternatives to perimeter/rate-limit-bundle?
- On Laravel, use the built-in RateLimiter and throttle middleware with a Redis cache store; that is the framework-idiomatic answer and requires no dependency. On Symfony, use symfony/rate-limiter with a RateLimiterFactory and a request listener, available first-party since Symfony 5.2. Both options support current PHP versions, are actively maintained, and give you a disclosure process for security issues. The bundle only made sense on a legacy Symfony 2.x application, which is itself worth flagging.
Weaver
How can I help you explore Laravel packages today?