Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.esperr.com/llms.txt

Use this file to discover all available pages before exploring further.

​
When to choose Anubis

  • You want a locally verified challenge path.
  • You prefer browser proof-of-work over a hosted CAPTCHA flow.
  • You want to reduce external challenge-provider dependency.
Best fitAnubis is a strong fit for environments where a short burst of client-side CPU work is acceptable and avoiding a hosted challenge vendor matters more than minimizing device effort.

​
What the customer configures

You configure Anubis at the mitigation layer:
  1. In the console, create or edit a mitigation with Mode = Challenge.
  2. Select Anubis as the challenge provider.
Esper’s runtime must also have Anubis enabled:
  • ESPER_ANUBIS_DIFFICULTY
The difficulty controls how much work the browser performs before Esper accepts the challenge solve.
Operational noteHigher difficulty increases resistance to commodity automation, but it also increases solve time and device battery usage for legitimate users.

​
How to verify the setup

Open Settings > Challenge and run Test challenge setup. Green means:
  • Anubis is enabled on the runtime
  • your enabled Challenge mitigations that use Anubis are valid
Red means one or more of the following:
  • Anubis is disabled in runtime config
  • a challenge mitigation is missing its provider selection
  • the tenant has no enabled challenge mitigations to validate

​
What users experience

When a policy resolves to a Challenge mitigation using Anubis:
  • Esper creates a challenge session
  • the browser loads an Esper-managed challenge page
  • the page solves a short proof-of-work locally
  • Esper verifies the proof and issues the challenge proof token
  • the user is redirected back to the original return URL
UX expectationAnubis can feel slower on older mobile devices than Turnstile. If your customer-facing flow is sensitive to client CPU spikes, compare both providers before standardizing on one.

​
Tradeoffs

  • Pros: no third-party challenge provider, local verification, simple runtime dependencies
  • Cons: higher client CPU cost, device variability, tuning difficulty is an operational decision