Filament Captcha Field Laravel Package

Product Decisions This Supports

• Scoping abuse protection for public-facing Filament forms. This package only matters if we expose Filament Forms to unauthenticated users — public panel registration, guest submission forms, contact/support intake, lead capture. It is not relevant to internal admin CRUD, which already sits behind auth and is a poor fit for CAPTCHA UX.
• A build-vs-buy call on a very thin capability. The underlying feature is a provider JS widget plus a validation rule rendered as a Filament field. That is roughly 1–2 engineering days to build in-house (a Placeholder/custom field with a Blade view and a custom rule, or a small Livewire component). This package saves hours, not weeks — so the decision is dominated by maintenance risk, not by development cost.
• Provider selection as a product/privacy decision. reCAPTCHA sends user signals to Google and carries consent/compliance overhead in the EU; Cloudflare Turnstile and hCaptcha are common substitutes. Deciding which provider is a product/compliance call that precedes picking any wrapper package.
• Where enforcement lives. Whether abuse mitigation is handled at the edge (Cloudflare/WAF, rate limits) or in-app (form-level CAPTCHA) changes the roadmap item entirely. Form-level CAPTCHA is the last mile, not the strategy.
• Dependency governance. Adopting a package for a security control sets a precedent: we then own patching it. v0.1.1 shows the maintainer is not gone — but one framework-compatibility bump in ~2 years is the floor for "alive," not a reason to trust it in a security path. This assessment should feed a standing rule about acceptable maintenance status for security-adjacent dependencies.
• Fork-or-wrap decision. If we adopt, we should wrap it behind our own field/interface so a provider or package swap is a one-file change — cheap insurance given the maturity signals here.

When to Consider This Package

What v0.1.1 changes: the release note is a single line — "Allows using Laravel 10." That loosens the framework constraint on the illuminate/support side and updates the freshness signal (the package is no longer frozen at Feb 2023). It says nothing about Filament compatibility, which was and remains the dominant risk. It also lands us on Laravel 10, which is already in security-only maintenance — so the bar it clears is a low one, and it tells us nothing about readiness for L11/L12 or Filament v3/v4. Net: the package moved from "looks abandoned" to "minimally maintained, still behind."

Consider it when:

• We are on the Filament version this package actually supports — still unverified. The Laravel bump does not confirm Filament v3/v4 support; inspect composer.json and the field implementation against our pinned major before anything else.
• We are pinned to Laravel 10 specifically (this release is the only thing that makes that combination installable).
• The target is a low-stakes, internal or prototype form where a broken widget is an inconvenience rather than an outage.
• We need reCAPTCHA specifically, today, and have no appetite to write a custom field.
• We are willing to pin the version, review the source (it is small and MIT), and accept ownership of future patches.

Look elsewhere when:

• We are on Filament v3/v4 or plan to upgrade — still the dominant cost, and v0.1.1 does not address it. 0 dependents / ~18 stars means no community pressure to keep it current.
• We are on Laravel 11/12 or expect to be; a Laravel 10 bump signals lag, not momentum.
• CAPTCHA is a real security or compliance control on a production, public surface. Unmaintained security-adjacent dependencies are a liability, and there is no evident response path for vulnerabilities.
• Privacy constraints point to Turnstile or hCaptcha rather than reCAPTCHA.
• We need it in exactly one or two places — build the custom field and keep control.
• We want a maintained, broader Laravel CAPTCHA package for validation/rendering and only need Filament glue.

Bottom line: unchanged. v0.1.1 is a compatibility patch, not a revival — one Laravel 10 line, no Filament work, no dependency adoption, no version beyond 0.1.x. It marginally improves the freshness picture and matters only if we are stuck on Laravel 10. Treat the repo as a reference implementation to copy ideas from, not a dependency to standardize on.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source add-on that puts a CAPTCHA field into our admin/form framework. It would save us a day or two of work, but it is a security component — meaning we would inherit the job of keeping it patched. A new release landed (v0.1.1), but it only adds support for Laravel 10, a framework version already in security-only maintenance, and does nothing about the framework-version risk that actually blocks us. Recommendation stands: do not adopt as a dependency. Fund a short in-house implementation (1–2 days) on a modern, privacy-friendlier provider, paired with rate limiting and edge protection. Same outcome, no orphaned dependency in a security path.

To engineering: It is a thin Filament field wrapping a CAPTCHA widget and a validation rule. v0.1.1 loosens the illuminate constraint to allow Laravel 10 — nothing else. Filament major compatibility is still unverified and likely broken given the original release date; zero dependent packages, and a single commit-style release is the only maintainer signal in ~2 years. Propose we build a small custom field behind our own interface — provider-agnostic, testable, swappable — and handle the bulk of abuse prevention with rate limiting and edge rules rather than form-level CAPTCHA. If we still want the shortcut for a prototype, pin it, vendor-review the source, confirm the Filament constraint before install, and do not let it reach production.