RenderCache on SoftDevStudio.com

RenderCache Adds macOS and Windows

Sun, 18 Oct 2026 00:00:00 +0000

RenderCache’s two alphas ran on Linux only. Version 0.2.0 adds macOS on Apple silicon and Windows on x86-64, with the same rules for the data directory on all three: no links followed, one process per directory, and a snapshot replaced only by a complete copy.

The review before the release found a gap that had been there since the first alpha. Links pointing out of the data directory were refused, but links that stayed inside it were followed. Now every link is refused. It also put a limit on pages crawlers ask for outside the sitemap: a page has to go an hour without a request before a new URL can take its slot, and its snapshot is deleted when that happens, so made-up URLs can’t keep Chrome busy or fill the disk.

RenderCache Second Alpha Fixes a Crawler Redirect Loop Behind HTTPS Edges

Sun, 18 Oct 2026 00:00:00 +0000

RenderCache’s first alpha had a bug that only shows up in a real deployment. RenderCache sits behind nginx or a Cloudflare Worker that handles TLS. On a cold page it passes the crawler’s request on to the app, and in alpha 1 it rebuilt the forwarding headers from its own plain-HTTP connection on the way. So the app was told the crawler came in over HTTP. Apps that force HTTPS redirected it, the crawler came back the same way, and went round again, on exactly the pages not cached yet.

RenderCache Ships Its First Alpha, a Self-Hosted Cache That Serves Crawlers Rendered Pages

Fri, 16 Oct 2026 00:00:00 +0000

RenderCache, the studio’s tenth project, is a pre-render cache for public JavaScript sites that runs on your own server. It renders public pages in Chrome, keeps the finished HTML and hands that copy to crawlers, while visitors get the normal app. The first alpha, 0.1.0-alpha.1, came out on 16 October for Linux on x86-64: one Go executable, with Chrome running beside it. The code is on GitHub under Apache 2.0.

The hard request is the first one, for a page with no saved copy yet. RenderCache doesn’t keep a crawler waiting on Chrome: a cold page comes from the origin, maybe still an empty shell, and renders in the background. So it warms pages from the sitemap ahead of time, refreshes them in the background and keeps the older copy if the origin fails for a moment. For each request from a recognized crawler it also writes a receipt with the status, the cache outcome and the bytes written. It’s a record of what left the server. What the crawler did with the page, it can’t say.