FCaptcha
Self-hosted, invisible CAPTCHA that detects AI agents driving real browsers. GDPR, WCAG 2.2 AA, and EAA: no cookies, no third-party data sharing, and no visual or audio puzzle. With a false-positive budget enforced in CI. Proof of work, drop-in for Turnstile and reCAPTCHA.
FCaptcha: a self hosted CAPTCHA that detects AI agents
FCaptcha blocks bots and AI driven browsers with a single click or less, and it is built to drop in for Turnstile and reCAPTCHA.
What FCaptcha detects
FCaptcha is an open source CAPTCHA system designed to detect a wide range of unwanted automated traffic. The README says it is built to detect traditional bots, headless browsers, automation frameworks, CAPTCHA farms, and the newer generation of AI agents. The AI agent category is described in detail. The system targets vision models that take a screenshot and then click, computer use agents that drive a real browser over the Chrome DevTools Protocol, and synthetic input that reports itself as trusted. The README explains the detection uses input event forensics and the cadence of an LLM's thinking time, which are signals that distinguish a human from a scripted or model driven interaction. It also flags self declaring agents by name, listing ClaudeBot, GPTBot, ChatGPT-User, PerplexityBot, and Bytespider, and it mentions cryptographically verified declared agents as a further category. The framing is that classic CAPTCHAs fail against agents that can read puzzles, so FCaptcha shifts toward behavioral and declarative signals. The README's live demo link lets a reader try it, and the deploy buttons for Render and Railway show it is meant to be run as a service. The project's pitch is broad coverage from old school bots to current AI agents in one system.
Drop in compatibility and modes
A practical feature in the README is drop in compatibility with existing CAPTCHA providers. FCaptcha serves the same siteverify contract on the same paths as Turnstile, reCAPTCHA, and hCaptcha, so migrating an existing backend is described as a base URL change. Tokens carry a signed hostname and action that the application can check, which preserves the verification handshake those systems already use. The README also describes two interaction modes. Checkbox mode behaves like Turnstile or reCAPTCHA v2, presenting a box the user clicks. Invisible mode behaves like reCAPTCHA v3, running without a visible challenge for most users. The goal stated in the project title and intro is to block bots and agents with a single click or less, which aligns with the invisible mode for the common case. By reusing the siteverify contract and the two familiar modes, FCaptcha lowers the switching cost for sites that already depend on a CAPTCHA vendor. The README presents this compatibility as a core reason to adopt it, because a team does not have to rewrite its verification logic, only point the base URL at an FCaptcha deployment and keep checking the signed tokens it issues. The same paths and contract mean existing front end code keeps working while the verification backend changes underneath.
Privacy, compliance, and false positive budget
The README emphasizes privacy and compliance properties. It states FCaptcha is self hosted, invisible, and uses no cookies, no third party data sharing, and no visual or audio puzzle. Those claims map to regulatory needs: the description mentions GDPR, WCAG 2.2 AA, and the European Accessibility Act, which are the privacy and accessibility frameworks a public website must often satisfy. Skipping puzzles helps with accessibility because audio and visual challenges are a known barrier, and skipping third party data sharing helps with GDPR by keeping verification on the operator's own infrastructure. The README also says a false positive budget is enforced in CI, which means the project treats wrongly blocking a human as a measured, bounded risk rather than an afterthought. For an operator, self hosting means the verification service runs on their own domain and data, not a vendor's. The combination of no cookies, no puzzles, and a CI enforced false positive budget is presented as the responsible design stance for a modern CAPTCHA. The README ties these properties directly to the named standards, so a compliance minded team can see which requirements the tool is built to meet. No cookies and no third party sharing also reduce the compliance work a site owner must do to adopt the tool.
Runtime support and deployment
The README's badge row shows the runtimes and deployment options FCaptcha supports. It lists Go 1.21 or newer, Python 3.12 or newer, and Node 20 or newer, which tells a reader the project ships or is usable across those three ecosystems. A Docker image is published on ghcr.io, the GitHub container registry, so a team can run it as a container without building from source. The README also includes one click deploy buttons for Render and Railway, two hosted platforms, which makes a quick public deployment straightforward for those who do not want to manage their own server. The MIT license badge confirms the code is permissive to use and modify. The live demo link gives a place to see the system before installing. Taken together, the deployment story is flexible: pull a container, deploy to a PaaS with a button, or run one of the language runtimes directly. The README's emphasis on drop in replacement for Turnstile and reCAPTCHA, plus this range of runtimes and a container image, positions FCaptcha as a self hosted alternative a team can stand up quickly and point existing verification code at by changing only the base URL and keeping the siteverify checks. The ghcr.io image and the one click deploy buttons make a first self hosted instance quick to launch for evaluation.
Editorial conclusion
FCaptcha is published under the MIT license and supports Go, Python, and Node runtimes with a Docker image on ghcr.io. The README says it is a drop in replacement for Turnstile, reCAPTCHA, and hCaptcha using the same siteverify contract.
Community notes