Statamic Captcha Laravel Package

Technical Evaluation

Architecture fit. aryehraber/statamic-captcha is a Statamic addon built on Laravel, so it fits a Laravel/Statamic stack natively: Composer-installed, auto-discovered service provider, published config, and a tag/validation-rule surface used directly in form templates. The relevant architectural signal in v1.18.0 is that adding a provider required only a new provider implementation plus registration — the package exposes a clean provider abstraction rather than hard-coding a single vendor. That is the right seam, and it means vendor choice is a configuration decision rather than an integration project.

Integration feasibility. Low effort. Typical path is composer require, publish config, set credentials in .env, select the provider, add the tag to the relevant form, and rely on the package for server-side verification. For an engineer already familiar with Statamic forms this is measured in hours, not days. Nothing in this release changes routes, middleware, or the config schema.

Technical risk. This release is additive and non-breaking: one new provider (FCaptcha) and one new contributor. There are no deprecations, no removals, and no security fix — so there is no urgency to upgrade, and no reason to block on it either.

Residual risks worth tracking:

• Vendor risk, not package risk. Every provider is a third-party service sitting in a submission-critical path. FCaptcha is materially less established than reCAPTCHA/hCaptcha/Turnstile; adopting it imports that vendor's availability, pricing, data-residency, and privacy posture into our forms.
• Verification coverage. Confirm the new provider's server-side verification path is actually exercised by tests; a provider that renders a widget but verifies weakly is worse than no CAPTCHA.
• Bus factor. Single-maintainer addon with an ecosystem-typical support model (GitHub issues, no SLA). Acceptable, but should be a conscious acceptance rather than an accident.

Key questions.

1. Which Statamic and Laravel version ranges does 1.18.0 declare, and do our apps fall inside them?
2. Is FCaptcha self-serve or contract-based, and what does it cost at our submission volume?
3. Is there a concrete driver to adopt FCaptcha (regional availability, cost, compliance), or is it simply newly available?
4. Does FCaptcha support server-side verification with a documented API, and is that path tested in the package?
5. What is our fail-open vs. fail-closed policy when a CAPTCHA provider is unreachable?

Integration Approach

Stack fit. Native. The package targets Statamic's form pipeline and Laravel's validation layer, so there is no adapter, shim, or bespoke glue to maintain. Credentials live in environment config, consistent with how we handle other third-party secrets.

Migration path. None required. Existing provider configuration continues to work unchanged; the only new surface is an additional selectable provider. The upgrade is a version bump on a branch, verified against the forms that already use CAPTCHA. Choosing FCaptcha is opt-in per environment and per form.

Compatibility. Pin the exact version, run the existing form submission tests, and confirm the current provider still renders and verifies after the bump. Treat FCaptcha adoption as a separate change from the version upgrade so that a regression can be attributed unambiguously.

Sequencing.

1. Upgrade to 1.18.0 with no provider change; verify no regression on existing forms. This is the low-risk, independently valuable step.
2. If FCaptcha has a real driver, procure credentials and validate in staging against a single low-traffic form.
3. Canary in production on one form; compare submission success rate and abandonment against baseline.
4. Decide whether to standardize on one provider or run per-region/per-form providers — and document that decision, because multiple providers multiplies the operational surface.

Do not bundle this upgrade with unrelated form or template changes.

Operational Impact

Maintenance. Low. Composer-managed, semver-minor, no config migration, no data migration. The ongoing cost is release tracking — and specifically watching for major-version bumps that coincide with Statamic major upgrades, which is where this class of addon typically breaks.

Support. Open source, single maintainer, no commercial SLA. Mitigations: pin the version, keep the ability to vendor-patch or fork, and retain a documented fallback (Laravel's native validation rules or a direct provider SDK) if the package stalls. A one-provider integration is easy to replace; a sprawl of four providers is not.

Scaling. Each submission triggers an outbound verification call, adding roughly 100–300 ms of latency and coupling form throughput to the provider's rate limits and availability. Confirm limits against peak form volume (campaign launches, event registration spikes) before committing to any provider, and check whether the package caches or batches anything.

Failure modes.

• Provider outage → submissions blocked or silently rejected. Define fail-open vs. fail-closed explicitly, implement it, and test it. This is the single most important operational decision here.
• Missing or rotated keys → hard failures in production after an environment change. Add key presence to deployment checks.
• Client-side blocking → privacy tooling and adblockers suppress the widget script, producing false negatives and lost submissions. Monitor abandonment rate, not just error rate.
• Provider proliferation → each additional vendor adds a dashboard, key rotation procedure, and incident runbook.

Ramp-up. Low for engineers already working in Statamic. Adopting FCaptcha adds a modest increment: new dashboard, credential handling, and on-call familiarity with a second vendor's failure signature.

Recommendation. Upgrade to 1.18.0 as a routine, non-urgent maintenance step — it is additive and low risk. Do not enable FCaptcha absent a specific driver; if a driver exists, gate adoption behind a defined fail-mode policy and a single-form canary before any broader rollout.