Auth Captcha Laravel Package

Product Decisions This Supports

• Upgrade planning for Laravel 9 migration: 3.0.0 drops support for all pre-Laravel-9 versions. This is a forcing function that ties the package's lifecycle to your framework upgrade roadmap — treat it as a dependency in the same swimlane as the Laravel 8→9 migration, not as an independent upgrade.
• Abuse / traffic-control features: the new rate-limiting parameters open up product-level knobs (per-key, per-route, or per-tenant quotas) that previously required custom middleware. Supports decisions like "can we ship per-customer API quotas without building it?"
• Build vs. buy for throttling: if throttling is not a differentiating capability, adopting a maintained package beats owning bespoke middleware. This release is a signal the maintainer is still active and tracking current framework versions — a positive mark for buy.
• Support matrix / LTS commitments: the versioning policy (major bumps that drop old framework versions) lets you state, and commit to, a support window for your own product ("we support the two most recent Laravel majors").
• Not supported by this release: no new product surface area beyond throttling configuration. Do not scope roadmap items (billing metering, analytics on rate-limit hits) on the assumption that these parameters do the work for you.

When to Consider This Package

Adopt when:

• You are on Laravel 9 or newer already, or the upgrade is funded and scheduled. On Laravel 8 or below, 3.0.0 is simply not installable — you would be pinning to the 2.x line and inheriting an unmaintained branch.
• You need configurable request throttling (API rate limits, login/OTP attempt limits, per-tenant quotas) and want it declaratively configured rather than hand-rolled in middleware.
• You want the maintenance burden of throttling logic to sit outside your codebase, and the maintainer's release cadence (framework-current, semver-major on breaking changes) is acceptable.
• Your team can absorb a major-version upgrade path: config key renames, published-config republishing, and any signature changes implied by the new rate-limiting parameters.

Look elsewhere or defer when:

• You are locked to Laravel ≤8 with no upgrade window — evaluate alternatives or fork; do not adopt 3.0.0.
• Your rate limiting must integrate with an external store or control plane (Redis cluster policies, an API gateway, an edge/CDN layer). A framework-level package may duplicate or conflict with that layer.
• You need guarantees the package will not make further breaking drops. The 3.0.0 policy statement ("no longer supports lower versions") is explicit and will repeat at each major. If you need long support tails, budget for pinning and patching.
• Throttling is core differentiating IP (e.g. a metered billing engine). Then own it.

Action before committing: read the 3.0.0 upgrade guide for the renamed/removed config keys and the exact shape of the new rate-limiting parameters, and confirm the Laravel 9 minimum against your oldest supported deployment target.

How to Pitch It (Stakeholders)

For executives: This is a routine dependency upgrade to the newest major version of a library we use (or would use) for request throttling — the mechanism that stops abuse and protects uptime. The new version is current with the framework version we are moving to anyway, and it adds configurable rate-limit settings, so quota features can be configured rather than custom-built. The cost is a one-time upgrade task that must be sequenced with our Laravel 9 migration; the risk is low but the coupling is real — the package no longer runs on older framework versions, so the two upgrades land together.

For engineering: 3.0.0 adds Laravel 9 compatibility, removes support for all earlier Laravel versions, and introduces new rate-limiting parameters. Plan it as part of the Laravel 9 migration: republish and diff the config, migrate to the new throttling parameters, and add regression coverage on the endpoints that are currently throttled. Pin the major version and record an explicit support-window decision so the next framework-major drop is anticipated rather than discovered. If anyone is still on Laravel 8, they stay on the 2.x line — flag those services now.