- How do I install nabilhassen/laravel-usage-limiter in Laravel?
- Run composer require nabilhassen/laravel-usage-limiter, publish the config and migration files with php artisan vendor:publish --provider="NabilHassen\LaravelUsageLimiter\ServiceProvider", then run php artisan migrate. The package creates new tables only and does not modify existing ones. Add the HasLimits trait to the model that will consume limits.
- Does laravel-usage-limiter work with Laravel 10 or Laravel 11?
- No. The package requires Laravel 12.0 or higher, with v1.1.0 targeting Laravel 12.x and v2.0.0 targeting 13.x. Applications on Laravel 10 or 11 cannot use it without forking. Confirm your fleet's Laravel version before evaluating the package further.
- How do I define per-plan usage limits with Laravel Usage Limiter?
- Create Limit records with name, allowed_amount, plan, and reset_frequency using Eloquent, such as a projects limit of 5 per month on the standard plan. Limits are data rather than config, so plan catalog changes become data migrations or seed updates. Use the package's model paths or run limit:cache-reset after changes so cached quotas are refreshed.
- How do I check whether a user can consume more usage before creating a resource?
- Use hasEnoughLimit() for read-only pre-flight checks in controllers or UI, and useLimit() when you actually consume quota. useLimit() throws an exception when the allowed amount is exceeded. The package does not provide middleware, gates, or policies, so you wire enforcement into your own services, controllers, or handlers.
- How do usage limits reset in laravel-usage-limiter?
- Each limit has a reset_frequency such as every second, minute, hour, day, or month, implemented as fixed-window counters that reset to zero. Schedule the package's built-in artisan command to reset consumed usage automatically. You can also manually reset a model's consumed limits. This is not a rolling or sliding window model.
- Is nabilhassen/laravel-usage-limiter safe for concurrent requests?
- The package performs a check-then-consume flow in useLimit(), reading cached limit state and then incrementing the used amount. The documentation does not describe lockForUpdate, an atomic increment, or a unique-counter guarantee, so concurrent requests can both pass the check and overshoot allowed_amount. This is a correctness concern for per-second or per-minute API limits, so load-test before relying on it there. Monthly project quotas carry lower risk but still benefit from reconciliation.
- How do I handle quota when a tracked resource is deleted?
- Call unuseLimit() whenever a tracked resource is deleted so the consumed counter is decremented. This is the only decrement path, and deletes that bypass it such as admin hard deletes, cascade deletes, GDPR purges, imports, restores, or direct SQL will leak quota until the next reset or permanently if reset_frequency is null. A reconciliation job comparing counters to actual resource counts is prudent. Plan for that in production.
- Can I customize the Limit model, table names, or relationship name?
- Yes. The package supports a swappable Limit model, a configurable relationship name to avoid collisions with an existing limits() relationship, renameable tables, and a configurable cache store. These extension seams are exposed in the published config. For a package of this size, they cover the customization most Laravel teams need.
- Does laravel-usage-limiter handle billing, invoices, or Stripe metering?
- No. It deliberately stops at counting and does not bill, invoice, prorate, or prorate on upgrade. If Cashier or another Stripe metering system already tracks usage, this package becomes a duplicate source of truth rather than a building block. Use it where quotas are a product gate, not a revenue ledger.
- Why are my updated limits not taking effect immediately?
- Limit definitions are cached for 24 hours and are only invalidated by the package's own create, update, and delete paths or by running limit:cache-reset. A DBA hotfix, seeder run, or rollback that bypasses the model can leave incorrect quotas in force for up to a day. Make cache reset a mandatory post-deploy step when quota data changes outside the package.