Pages on RenderCache.com

Contact

Mon, 01 Jan 0001 00:00:00 +0000

For questions, support and project enquiries, email info@rendercache.com.

You can also report reproducible bugs, request features or share deployment feedback through the RenderCache engine issue tracker. Include the RenderCache version, operating system, browser version and the response you expected. Remove tokens, cookies, authorization headers and private content before sharing logs or configuration.

Deployment choices

Mon, 01 Jan 0001 00:00:00 +0000

The alpha supports a full reverse-proxy setup and selective crawler routing behind an existing edge. In both cases, the renderer needs a fixed route to the original application. It must not render its own frontend. This project website is static Hugo output and does not host a render backend.

Standalone reverse proxy

Put TLS termination in front of RenderCache’s public listener, configure the original app and public site root, and let Go classify document requests. Matching crawler claims can use the saved copy; humans and private/API requests continue to the origin. This gives the delivery log visibility into crawler bypasses as well as snapshot responses. Keep the separate admin listener on a private interface or secure tunnel.

Download the alpha

Mon, 01 Jan 0001 00:00:00 +0000

RenderCache v0.1.0-alpha.1 is available for Linux amd64. It is an evaluation alpha. The standalone executable needs a separately installed, maintained Chrome or Chromium; the repository’s Dockerfile installs Chromium in its runtime image.

Linux amd64 archive SHA256SUMS

Release notes and matching source tag are on GitHub. The engine is licensed under Apache 2.0. Its binary archive includes dependency notices, a sample configuration, and deployment instructions.

Verify before extracting

Download the archive and checksum file into the same directory, then run:

How RenderCache works

Mon, 01 Jan 0001 00:00:00 +0000

RenderCache sits between crawler requests and a fixed origin. A normal visitor receives the original application. A matching crawler request can receive an eligible saved response from disk. User agents are configurable routing claims; they are not authenticated bot identities.

Start with the sitemap

The service discovers pages from your sitemap and schedules missing or expired snapshots through a bounded queue. Chrome loads each page on the configured origin, waits for a readiness selector or a settling delay, and captures the rendered document. The snapshot preserves structured data while removing executable scripts and inline event handlers. Chrome is an external process; the Go executable does not contain a browser.

Questions about RenderCache

Mon, 01 Jan 0001 00:00:00 +0000

Do all AI crawlers fail to run JavaScript?

Crawler capabilities differ and can change. RenderCache addresses requests that need useful HTML without executing your application. Its editable user-agent patterns are routing hints, not a universal claim about every crawler or a way to verify identity. Test the responses that matter for your own public pages.

Will this guarantee search ranking or AI citations?

No. It can make rendered content available in a response and record what the server wrote. A receipt does not prove a crawler read the body, indexed it or used it in an answer. Reachability, robots rules, canonical metadata, content quality and each service’s policies still matter.

Run RenderCache

Mon, 01 Jan 0001 00:00:00 +0000

Start on Linux amd64 with a maintained Chrome or Chromium installation. Download and verify the alpha, then run it as an unprivileged user with its own writable data directory. Use a public origin whose pages do not require a login. The Chrome sandbox is enabled by default.

Point it at the app

Replace the sample addresses, browser path, and readiness selector with values for your application. origin must reach the original app directly; pointing it back at the RenderCache frontend would create a loop. The selector should appear when the page’s useful content is actually ready.

Status and roadmap

Mon, 01 Jan 0001 00:00:00 +0000

RenderCache v0.1.0-alpha.1 is a working Linux amd64 evaluation release. It includes the Go reverse proxy, Chrome rendering, atomic disk snapshots, sitemap warming, stale-while-revalidate serving, private-response withdrawal, authenticated purge, shell diagnostics, rotating delivery receipts, and one protected status/comparison page. Storage quotas, explicit prune, directory locking and resource controls are included.

The release gates exercised real Chrome with race-enabled Go tests, a constrained non-root Chromium container, nginx routing, Cloudflare request logic, deterministic archives, checksum validation and the extracted executable. Sandbox operation on your host still needs verification. The browser-only website example is separate from the real admin comparison.

What the bot sees

Mon, 01 Jan 0001 00:00:00 +0000

The example below starts with the same JavaScript fixture used by the project: its original page has an empty app container, and JavaScript fetches the article text. The bundled before-and-after capture comes from RenderCache v0.1.0-alpha.1. Words absent from the extracted raw text are highlighted in the rendered text.

This is an interactive illustration. Cache-state controls and generated receipts run in your browser; they do not query a server, run Chrome, change a cache, or show visits by real crawlers. The site has no public arbitrary-URL rendering endpoint.