The repository has 1 README and no example application
GitHub's tree contains 3 files: a README, an MIT license, and assets/peak-banner.png. The fourth tree entry is the assets directory itself. There is no HTML page, server file, package manifest, test, or deployment configuration. The name promises examples, but every example lives inside Markdown. You can read the page in a few minutes. You cannot clone it, supply keys, and watch a protected form work.
That distinction decides the review. A real security example should make the trust boundary visible: browser receives a sitekey, browser returns a token, server sends it to Siteverify, and the application accepts or rejects the original action. commit 77ec457 gives fragments of that path without an application joining them. The fragments can introduce the nouns. They do not prove that the flow works as presented.
The non-interactive markup uses an undocumented client option
Cloudflare documents 3 widget modes: Managed, Non-Interactive, and Invisible. The basic managed-widget snippet follows Cloudflare's implicit-rendering shape, where a cf-turnstile element carries a sitekey and Cloudflare's script scans the page. The README then says data-mode="non-interactive" changes that widget's mode. Cloudflare's current client configuration table does not list mode or data-mode. Widget mode is associated with the sitekey when the widget is created through the dashboard or API.
That makes the second HTML example a poor thing to copy. A developer may see a widget and assume the attribute selected the intended security mode. Client attributes control other details, including appearance and execution. Use a sitekey created for the intended mode, then apply documented attributes such as data-appearance when you need to control visibility.
What happened when we ran it
We did not run commit 77ec457. Our test method used an unprivileged sandbox with 3 CPUs and 8 GB RAM, but it found no supported ecosystem because the GitHub language field is null. The repository also has no Dockerfile. With no application files, dependency manifest, or command, there was no honest install, build, or test step to attempt.
A skipped run is the finding here. It does not mean a command failed or that Turnstile itself failed. It means this repository offers prose snippets rather than a testable example. The tree has 4 entries and its only large asset is a promotional banner image. Anyone adopting the code must create the surrounding client, server, environment handling, and failure path elsewhere.
Siteverify is shown, while the decision path is missing
Siteverify requires 2 fields in this flow: secret and response. The Node.js fragment sends both to Cloudflare's endpoint, then prints data.success. A protected handler must act on that value, reject an invalid submission, keep the secret on the server, and decide what to do on network errors. Cloudflare also recommends checking fields such as hostname and action when configured. None of that appears in an executable handler here.
Tokens last 300 seconds and can be redeemed once, according to Cloudflare's documentation. Replays return timeout-or-duplicate, and malformed or expired tokens have their own error codes. Those details change application behavior, especially around retries and double submissions. A short snippet can omit UI polish; omitting the reject branch from a security example leaves out the part that protects the form.
The browser snippet does not capture a completed token
The Puppeteer fragment waits up to 15,000 milliseconds for a Turnstile iframe. It then looks for the outer widget element and calls an _callback property with an empty string. The snippet never defines browser, never registers that callback, and never shows the hidden response field after successful completion. Read literally, it demonstrates neither a complete browser session nor a captured token.
For testing a site you control, Cloudflare publishes dedicated test sitekeys and secrets. That route gives predictable pass or fail responses without turning a production challenge into an automation target. The repository's next section instead posts a sitekey and page URL to Peak, a paid outside service, then injects the returned value. That may describe Peak's product, but it is not the setup path a site owner needs to verify their own protection.
Three same-day commits are the whole maintenance record
The history contains 3 commits, all uploaded on September 1, 2026. GitHub showed 92 stars and 0 open issues or pull requests, there is no tagged release, and the last push happened on that same date. The push is recent, so calling the project abandoned would be wrong. The activity record is simply too thin to show how corrections, dependency changes, or Cloudflare API changes will be handled.
The README's final section makes the commercial purpose explicit. It advertises Peak pricing, a trial-credit code, and links with campaign parameters. That context does not make every earlier snippet false. It does mean the document is better read as vendor content than as a neutral set of integration examples. The 439,824-byte banner is also the repository's only non-text asset.
Cloudflare's runnable demo is the safer starting point
cloudflare/turnstile-demo-workers contains an installable Worker and demonstrates both implicit and explicit rendering. Cloudflare's Pages plugin is the narrower choice for a Pages Functions site. React teams can use marsidev/react-turnstile for a typed component and client lifecycle helpers, while keeping Siteverify on their own server. Each option gives you files that can be inspected and executed.
Use this README to recognize the sitekey, response field, and Siteverify URL, then stop. Create the widget in Cloudflare with the desired mode, use official test keys during development, and make the backend reject every response that Siteverify does not accept. Those steps cover the exact gaps that commit 77ec457 leaves open.