REFUSE TO GUESS.
If your team runs a self-hosted git forge, docs registry, or block explorer: bots and AI crawlers hit your commit, diff, and blame pages over and over, and your servers re-render every single one — CPU your team pays for and can't get back. renderwall sits in front of your forge, proves which of those pages can never change, and serves the proven ones from a cache instead of rendering them again. Your infrastructure does less work for the exact same traffic, and no one on your team has to guess which pages are safe to store.
Run the field test yourself
Shadow mode changes zero served bytes. It only classifies, counts, and prices what enforcement would absorb.
cargo build --release
cp examples/renderwall.toml /etc/renderwall.toml # edit upstream + visibility
./target/release/renderwall run -c /etc/renderwall.toml
curl -s 127.0.0.1:9090/stats | jq .absorbable_ratio02 Revision comparison
REV A — TODAY, NO RENDERWALL
- Every crawler hit re-renders the page from scratch, every time.
- Nobody knows how much CPU that costs until the forge falls over during a spike.
- The only lever most teams have is a proof-of-work gate — and 98% of what still gets through is a scraper, not a person.
REV B — WITH RENDERWALL
- Pages proven immutable serve from a cache instead of rendering again.
- Shadow mode measures the exact savings before anything changes.
- Your team decides with real numbers from your own traffic, not a guess.
03 What the problem costs, and what renderwall costs to run
The first two are the size of the scraper problem on a real forge. The third is renderwall's own overhead — neither kind is a guess, and they are not the same kind of number.
~20%
of total CPU, across five nodes
kernel.org's own accounting, via the Anubis project (Konstantin Ryabitsev), spent on scrapers with a proof-of-work gate already deployed. This measures the size of the problem on infrastructure not running renderwall, not a renderwall result.
98%
of successful traffic, still scrapers
Same source, same gate. A third of scrapers solve the challenge and get through, and nearly all of what gets through is still a crawler walking commit pages, not a person.
~280µs
mean hit-path latency: renderwall's own bench
Release build, in-process, fresh TCP connection per request, 2 KB
page. Worst observed: ~920µs. Reproduce it yourself:
cargo test --release -p renderwall-proxy -- --ignored bench_hit
04 Already covers the systems your team is probably running today
The identifier is a hash, a release, or a build number — the classifier does not care which. Each of the four below is scored against the same four-property test before it ships (combinatorial URL space, an identifier provable from the URL alone, an expensive render, no CDN escape), and all four are shipped today, not planned.
cgit · forgejo · gitlab full git oid
(40/64-hex)
docs.rs exact semver
release
blockscout — the strongest render cost in the set: a raw trace re-executes the transaction 0x +
64-hex
jenkins decimal
build number
05 What v0 refuses on purpose, and what it cannot yet do
A refusal cannot go stale. Every one of these is a counted passthrough today, not a silent gap, and the count is what decides whether it is worth fixing.
Ref-relative URLs pass through, never resolved. A branch name, HEAD, or latest refuses classification rather than being looked up: no repository access, no resolution races. This is ADR-0002, refusal over resolution.
Credentialed requests never touch the store, in either direction. No auth-scoped caching exists yet. This is ADR-0003, the anonymous-fill invariant: the store can only ever hold bytes a credential-free request could see.
One upstream, one forge, per process. Single-tenant in v0. HEAD, Range, and snapshot requests always pass through.
06 Keep whatever your team already runs
renderwall is not a replacement for a challenge gate like Anubis, a CDN, or a cache you already run — it handles the traffic that gets through anyway. A proof-of-work gate taxes the door; the expense is in the room. A CDN keyed on the URL buys nothing against a combinatorial space with near-zero repeat rate. renderwall does neither job; it turns the traffic surviving both of those into a file read. Gate in front, store behind.
07 What's coming — roadmap, not a price list
renderwall is free forever for OSS forges, full stop. The plan below is real (it lives in this repo), but it is a roadmap, not an announcement — there is no paid product, no tier, and no price yet, and this page will not invent one before there is a second customer to sanity-check it against.
find the buyer, ship the wedge design partners run
shadow mode, unpaid
a fleet view, still self-hosted multi-site stats,
offline entitlement
more of what already qualifies new domains scored
against the same test
The one thing that will not change: the data plane stays a self-hosted binary your traffic never leaves. Any control plane is optional and disconnectable, never a requirement to run renderwall itself.
08 Try it for a week without changing what your forge serves
Shadow mode opens no store and serves every request from upstream,
byte-for-byte. It only classifies, counts, and measures, including
per-class upstream render latency a counter-only tap cannot see. Price
the week with renderwall audit before anything is
promoted to serving traffic from the store.
$ cargo build --release # one static-ish binary
$ cp examples/renderwall.toml /etc/renderwall.toml # edit upstream + visibility
$ ./target/release/renderwall run -c /etc/renderwall.toml
$ curl -s 127.0.0.1:9090/stats | jq .absorbable_ratio
$ ./target/release/renderwall audit -c /etc/renderwall.toml # the same week, priced
# or price a dump someone mailed you, with no access to their network:
$ ./target/release/renderwall audit --from their-stats.json