Gentle Force Bundle Laravel Package

Product Decisions This Supports

• Security hardening roadmap. Brute-force protection for authentication surfaces (login, registration, password reset, OTP verification) is a recurring compliance and trust requirement. This bundle packages that as configuration rather than custom middleware, which shortens the path from "we should throttle logins" to a shippable control.
• API abuse and cost governance. Request rate limiting maps directly to product decisions about tiering (free vs paid quotas), protecting downstream spend on metered third-party APIs, and mitigating scraping — all of which are roadmap items with revenue and margin implications, not just infrastructure chores.
• Error-rate limiting is the genuine differentiator. Most throttling only counts successful or total requests. Limiting on error volume is a distinct capability: it targets enumeration, credential stuffing, and fuzzing that generate 4xx/5xx noise rather than load. Worth evaluating if your abuse model is "attackers probing" rather than "clients over-quota."
• Build vs. buy triage. The decision here is unusually cheap to make: MIT license, single-purpose, no vendor lock-in. The real question is not cost but framework fit and maintenance burden — see below.
• Material finding for the decision record: despite the brief describing this as a "Laravel/PHP package," this is a Symfony bundle (maba/gentle-force-bundle). Symfony bundles are not installable or usable in Laravel. Any plan that assumes drop-in Laravel adoption is invalid.

When to Consider This Package

Adopt-consideration is gated almost entirely on one criterion:

• Only if the target application is Symfony. This is the hard gate. For a Laravel codebase, stop here — Laravel ships RateLimiter and the throttle middleware, which cover brute-force and request limiting natively and are first-party maintained.
• Legacy Symfony 4/5 estates where the maba/* family is already in the dependency graph, making an incremental addition low-friction.
• You specifically need composite limiters — brute-force + error + request — expressed in one configuration surface with a consistent storage abstraction. That combination is not trivially reproduced, and it is the strongest argument in the package's favor.
• Internal or low-exposure services where a stale dependency is tolerable and you can pin it.

Look elsewhere when:

• The stack is Laravel. Non-negotiable. Use framework-native throttling.
• You require modern PHP / Symfony 6–7. Last release was 2021-08-26 — roughly four years stale. Verify compatibility before scoping; assume it will not support current Symfony without a fork.
• You need active security patch cadence. This is a security control. An unmaintained security dependency is a supply-chain liability, not a feature. With 50 stars and zero dependents, there is effectively no community to catch regressions or respond to CVEs.
• Distributed / Redis-backed limiting at scale, or audit evidence for SOC 2 / pen-test remediation, where you need a vendor or maintainer who will attest and patch.
• You need per-tenant or per-plan quota logic with product-facing reporting — this is infrastructure-level limiting, not a quota/billing system.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed, single-purpose library for three related controls: blocking repeated login failures, capping request volume, and capping error volume. The capability is real and maps to security posture and abuse-cost reduction. However, two facts dominate the recommendation: (1) it is a Symfony bundle and cannot be used in our Laravel services, and (2) its last release was 2021 with negligible adoption, which is a maintenance and supply-chain risk for a security-relevant component. Recommendation: do not adopt on Laravel; do not adopt on Symfony without budgeting a fork-and-own plan.

To engineering: The differentiating idea worth borrowing regardless of adoption is error-rate limiting alongside conventional brute-force and request limiting — it addresses enumeration and fuzzing that volume-based throttles miss. If we build in-house or use framework-native tooling, that behavior is the piece to replicate. On Laravel, RateLimiter + named limiters + throttle middleware already cover the brute-force and request cases; the gap is the error-based limiter. If we are on Symfony and want this specific bundle, treat it as a vendored fork: pin the version, verify PHP/Symfony compatibility, assign an owner, and add it to the dependency-review list.