abanoubnassem/filament-grecaptcha-field
Integrate Google reCAPTCHA into Filament forms with a simple, reusable custom field. Add spam protection to any Laravel admin panel form, configure your keys, and validate submissions through Filament’s native form workflow with minimal setup.
filament-grecaptcha-field is a narrow, single-purpose Filament form component that wraps Google reCAPTCHA (v2/v3) as a Filament field. It is not infrastructure — it is a UI-level integration shim between Filament's form builder and Google's client/server verification endpoints.
Architecture fit. The package sits entirely inside the presentation layer of a Filament panel. It adds a field type plus the associated validation rule and view. That is a shallow integration surface: it does not touch the domain model, persistence, queues, or auth pipeline. For a TPM this is attractive — adoption is reversible, and blast radius on failure is limited to individual forms where the field is used.
Integration feasibility. Low effort. Composer install, publish config/assets, add the field to a form schema, supply site/secret keys via environment. No database migrations, no service provider bootstrapping that alters application behaviour beyond view/asset registration. The main prerequisite is that the host application already runs Filament — this package is meaningless outside that context.
Technical risk. The material risks are not architectural, they are lifecycle and third-party risks:
^0.0 constraint is effectively a floating pin.Key questions. Which Filament major are we on, and is that combination explicitly covered by the package's test matrix? Is Filament 5.0 GA at our adoption time, or are we tracking a pre-release? Do we have a reCAPTCHA Enterprise requirement that this community wrapper does not satisfy? What is our policy on pre-1.0 dependencies in production panels? Who owns the Google Cloud project and key rotation? Is a maintained alternative (official Filament plugin, or a thin in-house field) a better bet given the bus factor?
Stack fit. The package is only viable in a Laravel + Filament stack. It is not usable from plain Blade, Livewire outside Filament, or non-Laravel PHP. If our admin surface is Filament, fit is direct; if it is Nova, Backpack, or bespoke Livewire, this package is out of scope and we should evaluate the raw reCAPTCHA SDK instead.
Migration path. Greenfield adoption is trivial — add the field to one form, behind a feature flag, and observe. Brownfield adoption is equally low-friction because there is no schema or data migration; the only migration concern is if we are replacing a hand-rolled reCAPTCHA implementation, in which case we should run both in parallel on a single low-traffic form before removing the bespoke code. Because the package is pre-1.0, plan for re-adoption work at each minor bump rather than assuming drop-in upgrades: treat composer constraint updates as change requests, not maintenance.
Compatibility. This release specifically adds Laravel 13 and PHP 8.4, and adjusts composer.json for Filament 5.0. Practically, that means: if we are on Laravel 11/12 with Filament 3 or 4, this release is a no-op for us and carries no benefit — do not upgrade reflexively. If we are planning a Laravel 13 or Filament 5 upgrade, this release removes a blocker. The critical check is that the package's widened constraint is actually tested; a composer.json edit is not evidence of runtime verification. Verify by running our own form tests against the target matrix, not by reading the changelog.
Sequencing. Adopt in this order: (1) confirm Filament major and Laravel/PHP targets; (2) pin an exact version rather than a range, given pre-1.0; (3) pilot on one internal, low-risk form; (4) instrument verification failures and latency; (5) only then roll to customer-facing forms where bot protection actually matters; (6) add a renewal checkpoint at the next Laravel or Filament major to re-evaluate whether the package still tracks upstream.
Maintenance. Low absolute effort, but non-zero and lumpy. Expect a small burst of work at each Laravel/Filament/PHP major release — this changelog is exactly that pattern. Budget roughly one dependency-review cycle per framework major, plus ad-hoc work if the maintainer goes quiet. Because the package is pre-1.0, pin versions and treat every bump as a reviewable change with a changelog read and a smoke test.
Support. Community-only. No vendor SLA, no commercial backing, no security disclosure process documented in the release notes. Escalation path for a bug is a GitHub issue against a single-maintainer repo. Mitigation: keep the integration thin enough that we can vendor the field class into our own codebase in an afternoon if upstream stalls. That fallback is genuinely cheap here given the shallow surface area, and it should be the documented exit strategy.
Scaling. Effectively irrelevant to application scale — the field is per-form-render, not per-request throughput. The scaling consideration is external: reCAPTCHA verification is a synchronous outbound HTTP call on form submission. At high submission volume that adds a network round-trip to the critical path and subjects our form latency to Google's availability. Verify timeouts and failure-mode configuration (fail-open vs fail-closed) explicitly; the sensible default for admin panels is fail-open with alerting, and fail-closed only where abuse is a demonstrated problem.
Failure modes. Ranked by likelihood and severity: (a) silent breakage on framework upgrade — widened composer constraints pass install but the field's Blade view breaks under a new Filament version; caught only by rendering the form in a test. (b) credential misconfiguration — wrong site/secret key or key-pair mismatch between environments, producing forms that either block all users or validate nothing. (c) third-party outage or quota exhaustion — Google unreachable or quota hit, blocking submissions depending on fail-mode. (d) compliance drift — reCAPTCHA script loaded without consent where regulation requires it. (e) maintainer abandonment — no security patch path; mitigated by the vendoring fallback.
Ramp-up. Under a day for a developer already fluent in Filament. The package itself is small; the learning cost is in Filament's form-schema conventions and in reCAPTCHA's own semantics (v2 checkbox vs v3 score thresholds, invisible vs visible, server-side score actions). Document the key provisioning and rotation procedure, the chosen score threshold if v3, and the fail-mode decision — those are the three things that will otherwise be re-litigated by whoever touches the form next.
How can I help you explore Laravel packages today?