Filament Turnstile Laravel Package

Product Decisions This Supports

• Shipping public-facing Filament forms safely. Bot mitigation for login, registration, password reset, contact, lead capture, support intake, and any Livewire/Filament form exposed to the open internet — without building and maintaining a CAPTCHA integration in-house.
• Build vs. buy, resolved cheaply. The buy side is a single small Composer dependency with a config-driven Blade component. That collapses a recurring "how do we stop spam signups?" debate into a one-sprint decision rather than a bespoke implementation with its own ownership cost.
• Vendor choice: Cloudflare Turnstile over Google reCAPTCHA. Supports a privacy/legal posture (fewer third-party trackers, no Google dependency in the consent story) and typically lowers user friction. Relevant if your DPO/legal review has flagged reCAPTCHA, or if Cloudflare is already in the infrastructure footprint.
• Multi-tenant and white-label roadmap. The TurnstileKeyResolverContract is the extension point for per-tenant/per-brand site keys — the pattern you need for a marketplace, agency, or white-label deployment. Note the v1.1 caveat: the Blade component reads keys from config, so a custom resolver means you own key injection yourself.
• Not blocking platform upgrades. v1.1 widens the PHP constraint from >=8.2 to >=8.2,<8.6, so PHP 8.5 is supported and the package won't pin your runtime upgrade roadmap. The explicit upper bound is a deliberate support policy, not an oversight — plan a dependency review before PHP 8.6.
• Low-risk incremental adoption. v1.1 carries no breaking changes and no behavioural code changes. If a decision was deferred pending "is this maintained?", this release is a modest positive signal but not a decisive one.

When to Consider This Package

Consider it when:

• You are on Filament and need CAPTCHA/bot protection on forms; the integration surface is a Blade component plus config, which is the minimum viable footprint.
• You are on PHP 8.2–8.5 and want a dependency that will not conflict with the rest of your constraint set.
• You prefer Turnstile over reCAPTCHA/hCaptcha for privacy, latency, or vendor-consolidation reasons.
• You need per-tenant keys and are prepared to implement a TurnstileKeyResolverContract and handle key injection yourself — the package gives you the seam, not the finished multi-tenant behaviour.

Look elsewhere — or budget extra work — when:

• You need turnkey multi-tenant key handling. v1.1 explicitly documents that custom resolvers must inject keys themselves; that is integration work you should scope, not assume.
• You are not on Filament/Livewire. The Blade component may be reusable, but the value proposition is the Filament fit; a plain-Laravel project should evaluate a lighter, more general Turnstile package.
• You need score-based risk tiers (reCAPTCHA v3-style) or challenge orchestration beyond a pass/fail token — Turnstile's model is different and this package does not abstract over it.
• You require a commercial SLA, security review artefacts, or vendor support. This is a single-maintainer OSS package at v1.1; treat maintenance continuity as a tracked risk.
• You are on PHP < 8.2, or you need a package that will move to PHP 8.6+ on your timeline rather than the maintainer's.

How to Pitch It (Stakeholders)

For executives: A small, low-cost dependency that puts bot protection on our public forms using Cloudflare Turnstile — a service likely already adjacent to our infrastructure. It removes an in-house build, avoids adding Google reCAPTCHA to our privacy surface, and carries no new contract or procurement cycle. The latest release is maintenance only: broader PHP version support, no breaking changes, no migration work. Principal risk is that it is a young, single-maintainer open-source package; that risk is bounded because the configuration is standard Turnstile and the widget can be replaced with contained effort.

For engineering: One Composer dependency, config-driven site/secret keys, a Blade component for Filament forms, and TurnstileKeyResolverContract as the extension seam for tenant-specific keys. v1.1 relaxes the PHP constraint to >=8.2,<8.6 — no code changes, no breaking changes, safe to adopt alongside a PHP 8.5 upgrade. Two things to note in the implementation: the component reads keys from config, so any custom resolver must also handle key injection; and the upper bound on PHP means we should schedule a dependency check before moving to 8.6. Recommended posture: adopt, pin the minor version, and keep a short exit note describing the swap path to an alternative Turnstile integration.