v1.33.0
Completes the Redis work 1.32.0 started. All three servers can now run multiple replicas. Nothing changes for single-instance deployments.
Added
Node and Python get Redis-backed shared state.
1.32.0 shipped this for the Go server only, and said so — Node and Python had to stay single-instance. REDIS_URL now does the same job in all three.
Shared across replicas:
- proof-of-work challenges
- token replay protection
- Siteverify idempotency
- rate limits
- suspicion history
- fingerprint cardinality
- site-key rotation guards
Challenge and token consumption are atomic, so "single-use" means single-use across the whole deployment rather than per process.
Both failure modes stay closed, in every implementation: a server refuses to start if configured Redis is unreachable, and fails closed if it drops out while running rather than reverting to process-local state.
A multi-replica conformance suite.
Single instance was never the hard case. CI now starts two containers of each server against one Redis and proves the properties that only exist across replicas:
- a challenge issued by one replica verifies on the other
- token replay is rejected across replicas, not just within one
- a Siteverify idempotency response created on one replica is returned by the other
The same test file runs unchanged against Go, Node and Python. A single-process test cannot observe any of this, which is precisely why the guarantees were worth pinning.
Changed
- The deployment documentation no longer describes distributed state as Go-only, or tells you Node and Python must stay single-instance. The README's Redis paragraph had also contradicted its own environment table two lines further down.
Upgrading
No Redis: nothing to do — unset REDIS_URL keeps process-local behaviour.
Already running multiple Node or Python instances: you have been running with per-process challenge and replay tables, which means single-use was only ever enforced per process. Set REDIS_URL.