You know the one. You're trying to subscribe to a newsletter, and Google asks you to identify all the bicycles. You squint at the photo. You miss one pixel. You get a new grid, this time with motorcycles, and you start wondering if you're the bot.

That's reCAPTCHA. It works, kind of. It also loads a JavaScript bundle from google.com on every page it appears on, ships your browsing behavior to Google's risk-scoring API, and gets flagged in nearly every cookie-compliance audit we've seen.

The captcha on orkestr is Altcha. Self-hosted, no third-party JS, no Google, no behavioral tracking. Users don't see a puzzle. There's a single checkbox and a quiet "verifying..." while the browser does some math. About a second, total.

This post is why we picked it over the better-known options. If you're looking for a Google reCAPTCHA alternative and you care about GDPR, this is the path we'd recommend.

The honest verdict, up front

For low-to-moderate traffic forms (signup, contact, comments, login) where you're not under sustained ML-driven attack: self-hosted Altcha is the right pick. No third-party calls, no GDPR paperwork, no user-hostile puzzles, a small widget loaded from your own origin.

For very high-traffic public surfaces under active attack by sophisticated operators (e-commerce checkouts, ticket drops, large social platforms) you probably still want a managed service with behavioral ML. Altcha's proof-of-work raises the per-request cost; at internet scale, a real bot farm absorbs it.

"Low-to-moderate traffic forms" is most of the internet. Altcha wins for most people.

How they compare

The "data leaves your origin" row is the whole point. Every other column flows from it.

What reCAPTCHA actually does

reCAPTCHA v3 (the "invisible" one) is not really a captcha. It's a behavioral fingerprinting library that returns a score between 0 (likely bot) and 1 (likely human). The score comes from Google looking at your browser, your IP, your mouse movement, your cookies, and crucially, your entire Google account state if you happen to be logged in.

That's a feature for fraud detection at scale. It's a legal and reputational risk for an EU business, because every form on your site becomes a Google data-collection endpoint. Schrems II turned every cross-border transfer to a US ad-tech company into a per-tool compliance question. reCAPTCHA is exactly that tool.

The compliance picture got materially worse on April 2, 2026. Google reclassified reCAPTCHA from data controller to data processor, which sounds like an internal Google detail but isn't. EU operators are now fully on the hook for GDPR compliance on every reCAPTCHA hit: a signed DPA with Google, an explicit legal basis documented in your privacy policy, and your team handling any data subject requests. Data still goes to US servers. The compliance burden didn't shrink, it moved to your desk.

EU DPOs ask the same question in different words: if you don't control the JavaScript on your login page, who does? It's worth sitting with.

Cloudflare Turnstile is better, but it's still Cloudflare

Turnstile is the industry response to reCAPTCHA-fatigue. It's free, the UX is good (most users see a checkbox, not a puzzle), and Cloudflare is more transparent about what it collects than Google has ever been. If you're not in the EU and you don't care about CLOUD Act exposure, Turnstile is a fine pick. It's the second-best option here.

For an EU-native deploy platform, though, every US sub-processor is a row on a DPA that EU buyers read line by line. We wanted captcha to be a thing on our origin, not a thing on someone else's. Turnstile doesn't get you there.

What Altcha does instead

Altcha replaces the "score-the-user" model with a "make-the-bot-pay" model. Proof of work.

The server generates a random salt, a nonce, and a target prefix, signs the whole envelope with an HMAC key only the server knows, and hands it to the browser. A Web Worker iterates a counter, combining it with the nonce and running PBKDF2-SHA256 each step, until the derived key starts with the target prefix. When it finds a matching counter, the server gets the challenge plus the solution back, verifies the HMAC, verifies the prefix match, and accepts the form.

The whole thing takes about a second on a modern laptop. A human doesn't notice. A bot farm trying to submit ten thousand forms per second per IP suddenly has to spin up real CPU per submission.

There's no third party. The challenge endpoint sits on your domain. The widget JavaScript serves from your origin. The HMAC key never leaves your server. There's nothing to add to a sub-processor list, because there's no sub-processor.

Two gotchas if you self-host Altcha

The integration is small. One new endpoint, one HMAC environment variable (openssl rand -hex 32), one React component for the widget. Two things are easy to miss, both worth flagging.

Don't let a CDN cache the challenge

We sit behind Bunny CDN for SSL and edge caching. Our first wiring of Altcha had a weird failure mode: legitimate users were intermittently getting "captcha already used" errors on first submit.

The cause was the obvious one in hindsight. The CDN was caching responses from GET /api/altcha/challenge. Two different users were getting the same signed challenge, the first submission consumed it via replay protection, the second user hit a 400.

The fix is one header:

@router.get("/altcha/challenge")
async def get_challenge():
    challenge = mint_challenge(hmac_key, cost=5000)
    return Response(
        content=challenge.json(),
        media_type="application/json",
        headers={"Cache-Control": "no-store"},
    )

If you're behind any CDN, set this or you'll spend an afternoon wondering why your captcha is mass-failing in production but works locally.

Replay protection needs a real store

The replay attack on a captcha is obvious: capture a valid submission, replay it many times. Most official Altcha libraries (Django, .NET, and others) ship with a replay store built in, so check yours before reinventing it. We rolled our own integration against FastAPI, which meant we added one ourselves. Redis SETNX keyed on the verified solution hash:

# Returns True if key was set (first use), False if it already existed (replay)
is_first_use = await redis.set(
    f"altcha:used:{solution_hash}",
    "1",  
    nx=True,
    ex=600,  # 10 minutes, safely longer than the challenge TTL
)
if not is_first_use:
    raise HTTPException(400, "captcha already used")

An in-memory dict won't survive a deploy or scale across worker processes. Redis works. Postgres works. Pick something durable, pick a TTL longer than your challenge expiry, and you're done.

We use a separate HMAC key per environment, so a leak in dev can't be used to forge prod challenges. Same reasoning as keeping your test Stripe keys separate from your live keys.

When Altcha is the wrong call

We want to be honest about the limits, because they're real.

You're being actively attacked by a sophisticated bot operator. A real bot farm with cloud capacity can absorb proof-of-work costs at the bot's marginal cost of CPU. PoW raises the floor; it doesn't put a ceiling on a determined attacker. If you've ever had to pull pricing data off your site after a competitor scrape, you want behavioral ML, not a math puzzle. Altcha also supports Argon2id and Scrypt as memory-hard alternatives to PBKDF2, which resist GPU and ASIC acceleration and narrow the gap between consumer devices and bot farms; not a silver bullet, but worth knowing.

Your users are on very low-end devices. A one-second solve on a modern laptop can become a four-second solve on a five-year-old budget phone. If your audience is consumer mobile in developing markets, benchmark before shipping.

You can't run a Redis (or equivalent) for replay protection. A captcha without single-use enforcement is theater. If your hosting tier doesn't let you add a key-value store, fix that first, then come back.

For everything else (the long tail of SaaS signup forms, internal admin tools, contact forms, comment sections, account recovery flows), Altcha is the better default than reCAPTCHA in 2026.

FAQ

Is Altcha actually free?
Yes. It's MIT-licensed open source. The library is at github.com/altcha-org/altcha. The cost is the CPU spent on the verifying server (negligible) and the client-side compute (about a second of one core, once per submission).

Do I need to run a separate Altcha server?
No. Altcha is a protocol plus a small client library. You add two endpoints to your existing backend: one to mint challenges, one to verify them. There's no Altcha-the-service unless you opt into their managed offering.

Does Altcha work without JavaScript?
The default flow needs JavaScript (the Web Worker is where the proof-of-work runs). Altcha also supports a server-side mode where a pre-computed challenge can be verified at form-submit time, useful for accessibility tooling. Most setups won't need it.

Will switching from reCAPTCHA to Altcha break my form analytics?
Only if you were using reCAPTCHA's "human score" as a continuous signal in your analytics. If it was a binary pass/fail gating form submission, the switch is transparent.

Can I use Altcha on a static site?
You need somewhere to mint and verify challenges. A serverless function counts. A small serverless function handles this in about 30 lines of Python.

Closing

Captcha is one of those problems that looks solved until you read the privacy policy. Most teams pick reCAPTCHA because it's the default, not because they evaluated it. If you're an EU business, you almost certainly didn't evaluate it. Your DPO will, eventually, and the conversation is going to be uncomfortable.

We chose Altcha because it was the only option that kept the entire flow on our origin. You can run the same thing on whatever backend you already have. It's a couple of hundred lines of code and one Redis key prefix.

If you also care about which other US services your stack quietly depends on, the Vercel April 2026 breach checklist is a useful companion read.