Your data is not cached
What it never stores and the zero-logging commitment are the wider version of this. What is cached is derived and cheap to rebuild — unlike resolving an entitlement, which is deliberately never cached, or a live leaderboard rank, which is deliberately never cached by us.
Your users, purchases, audit events, support mail and entitlements are fetched live, rendered, and discarded.
Never log or cache a proxied response body is a coding rule here, not a policy in a document.
What is cached
The manifest, briefly — what your Worker composes and where. It changes on a deploy, not on a request.
Static assets. The screen itself.
Nothing about your customers.
What you might expect to be cached and is not
An entitlement.
The kit resolves one with a single indexed lookup per gated request, with no cache anywhere — bought for exactly one property: a revocation is immediate.
An entitlement cached anywhere is an entitlement that outlives its revocation by however long the cache lives — and your refund took effect in five minutes is a sentence no support team should have to say.
What that costs
A page load reaches your Worker. So the dashboard is as fast as your Worker is, and as available.
And an unreachable Worker is reported as unreachable rather than served from a stale copy that looks fine.
Where caching does belong
In your own Worker, on your own terms, where you can decide what is safe to hold and for how long.
The kit’s own answer, where it has one, is to store rather than cache — a materialized leaderboard rank refreshed on a cron is not a cache, it is a stored column with a stated staleness, and your own rank stays live either way.
Refreshing
Reload. There is no invalidation to trigger, because there is almost nothing to invalidate.