Filament Turnstile Laravel Package

Technical Evaluation

Architecture fit. This package is a thin UI adapter, not a standalone capability. It provides a single Filament form component (Coderflex\FilamentTurnstile\Forms\Components\Turnstile) that renders Cloudflare's client-side widget, and delegates all server-side verification to its upstream dependency coderflex/laravel-turnstile. For a TPM this is the key architectural fact: adopting this package means adopting a two-package chain plus a third-party SaaS (Cloudflare Turnstile). The surface area you actually own is small — one field type, a handful of fluent options (theme, language, size), and a reset-captcha browser event. That is low-risk to integrate and low-cost to remove, which is the main argument in its favor. It is not a general-purpose CAPTCHA abstraction; there is no driver system, so swapping to reCAPTCHA/hCaptcha later means replacing the field, not reconfiguring it. Treat it as a point solution for "add bot protection to Filament auth and form screens."

Integration feasibility. Straightforward and well-bounded. Installation is a single Composer require with version pinned to your Filament major (v1→Filament v2, v2→v3, v3→v4, v4→v5), two env vars (TURNSTILE_SITE_KEY, TURNSTILE_SECRET_KEY), and a form-schema entry. The README documents the highest-value use case end-to-end: subclassing Filament's Login page, adding the Turnstile component to the schema, and wiring login(Login::class) in the PanelProvider. It also correctly anticipates the two failure paths that make CAPTCHAs feel broken to users — stale tokens after a validation error (the reset-captcha event via onValidationError / throwFailureValidationException) and multiple instances on one page. Both were fixed as regressions in 2.4.x, which tells you they were real production issues and that someone is actually running this.

Technical risk. The dominant risk is supply chain and maintenance depth, not code quality. Signals: 33 stars, 0 dependents, a single primary author, and a release history where a large share of PRs are Dependabot bumps rather than feature work. Recent releases (v3.0.0, v4.0.0) are almost entirely framework-version compatibility work — which is good hygiene, but it also means the maintainer's recurring obligation is chasing Filament's breaking changes. Filament moves fast and has already broken this package twice at the major level (component API migration in v3, FilamentComponent→schema API). Each Filament upgrade therefore becomes a coordinated two-package upgrade for you. Secondary risk: version pinning is unforgiving — installing ^4.0 on Filament v4 will fail or, worse, resolve wrongly; the major-version-to-major-version mapping must be enforced in CI. Tertiary: token verification is a network call to Cloudflare's siteverify endpoint, adding an external dependency to your login path (see Operational Impact). Note also the README references Filament v4 docs while the package targets v5, and the changelog is largely auto-generated — documentation drift is likely.

Key questions.

• Is the upstream coderflex/laravel-turnstile maintained by the same author, and does it carry the same bus-factor? (It does, per the README — this is a single-maintainer chain.)
• What is our actual threat model — credential stuffing on Filament login, public form spam, or both? Turnstile only meaningfully covers the former if we also add rate limiting.
• Do we have a documented fallback if Cloudflare's siteverify is unreachable, or if the maintainer abandons the package before our next Filament upgrade?
• Are we willing to accept a hard dependency on Cloudflare as a vendor for an internal admin panel?
• Who owns the fork-and-patch contingency, and what's the trigger threshold (e.g., no compatible release within N weeks of a Filament major)?

Integration Approach

Stack fit. Requires Filament (v2–v5 depending on package major), Laravel 11/12/13 on the v4 line, PHP 8.3/8.4. Because it plugs into Filament's form schema, it composes with any Filament form — login, registration, password reset, contact, or a resource create page — with the same one-line declaration. If your admin surface is already Filament, the marginal integration cost is near zero. If you are on Filament but behind on majors, you must pick the matching package major; there is no forward-compatible build.

Migration path. There is nothing to migrate from if Turnstile is new — it is additive. If you are replacing an existing CAPTCHA (reCAPTCHA, hCaptcha, a honeypot), expect a field-level swap plus re-issuing keys in Cloudflare and a user-facing change in widget appearance and challenge behavior; plan a short comms note for admin users. If you are on an older package major, the upgrade is mechanical but must be sequenced with the Filament major upgrade itself — v2→v3 involved a component-API rewrite, so treat package bump and framework bump as one change, not two.

Compatibility. Three compatibility axes to hold in CI: Filament major ↔ package major; Laravel/PHP versions within the supported matrix; and the upstream laravel-turnstile major (v3.0.0 moved it to ^2.0, so it too breaks independently). Add a Composer constraint test or a smoke test that boots a Filament panel with the field registered, so a silent resolution failure surfaces in CI rather than at deploy. Note Cloudflare's documented dummy keys are explicitly supported for testing — use them in the test suite and in local/staging so you never depend on live keys outside production.

Sequencing. (1) Get Cloudflare keys and validate Turnstile against staging with dummy keys first. (2) Install upstream laravel-turnstile, confirm server-side verification works headlessly. (3) Install this package at the major matching your Filament version. (4) Pilot on the Filament login page only — highest value, well-documented, easiest to roll back. (5) Instrument verification failure rates for one to two weeks. (6) Roll out to public-facing forms (registration, password reset, contact) once login is stable. (7) Only then consider resource create/edit forms, where CAPTCHA usually adds friction without much benefit for authenticated admins.

Operational Impact

Maintenance. Low day-to-day, with periodic forced upgrades. Your team does not maintain the widget; Cloudflare does. Your recurring burden is (a) keeping the package major aligned with Filament, (b) keeping the upstream verification package aligned, and (c) rotating Turnstile keys if compromised. Budget an explicit task each time Filament ships a major — historically this package has lagged, and with a single author and 0 dependents there is no community pressure to make it fast. Practically, assume you may need to carry a fork patch for a few weeks around a Filament major release.

Support. Support surface is the author's GitHub issues and the README. There is no commercial support, no SLA, no security policy beyond a pointer to SECURITY.md. For an internal admin panel this is acceptable; for a customer-facing, revenue-adjacent flow it is thin. Escalation path in practice is: read the upstream laravel-turnstile README (explicitly the recommended route for detail), then read the source — the component is small enough to audit in an hour, which is a genuine mitigation.

Scaling. Negligible infrastructure impact. The client widget is a Cloudflare-served script; server-side verification is one HTTP call per submission, so volume is proportional to form submissions, not traffic — trivially small even at high admin usage. Cloudflare's free tier covers normal volumes; check current Turnstile quotas if you anticipate heavy public-form traffic. No database, no queue, no cache added.

Failure modes. Enumerate and plan for each:

• Cloudflare siteverify unreachable or slow — if verification is fail-closed, logins fail during a Cloudflare incident. Decide the policy explicitly (recommend fail-open with alerting on auth, fail-closed on public spam forms) and make it configurable, not hardcoded.
• Stale token after validation error — user solves CAPTCHA, submission fails validation, token is consumed and the form appears permanently blocked. This is the single most common "the CAPTCHA is broken" ticket; the reset-captcha event exists for exactly this and must be wired on every form that uses the field, not just login.
• Multiple widgets on one page — fixed in 2.4.1, but re-verify if you add more than one form per page, and pin ≥2.4.1 on the v2 line.
• Widget destroyed on visibility change (e.g., tabs, wizard steps, modals) — fixed in 2.4.0; relevant if you place the field in a multi-step Filament wizard.
• Key misconfiguration or missing env var — surfaces as silent, always-passing or always-failing verification depending on upstream defaults; validate keys at boot and fail loudly in non-production.
• Abandonment — if the package goes unmaintained across a Filament major, you fork. Small codebase makes this cheap; assign an owner now.
• Accessibility / regional availability — Turnstile is generally better than image CAPTCHAs here, but confirm behavior for your user geography and any strict CSP rules, since the widget loads a third-party script.

Ramp-up. Effectively zero for a Filament-fluent developer: one composer require, two env vars, one schema entry, and one event dispatch. The README's login example is copy-pasteable. Estimate under half a day to a working pilot on staging including key setup, plus one to two days of instrumentation and rollout to remaining forms. The real ramp-up cost is organizational, not technical: agreeing the fail-open/fail-closed policy and naming an owner for the upgrade-and-fork contingency.