Astro SSR Cache Growth During Dev: Is Cache Invalidation Handled?

Short answer

There is no Astro flag or API to "clear the SSR cache per request," because the growth you're seeing almost certainly isn't an Astro SSR cache at all. In astro dev, Astro renders each request fresh; the memory that accumulates lives in Vite's in-memory module graph, which HMR intentionally keeps alive. That is expected behavior, not a leak — though it can hide real leaks, so verification matters.

Likely explanation vs. confirmed facts

Confirmed: Astro's dev server runs on Vite. Vite maintains a module graph in memory so that when a file changes, only the affected modules are invalidated and re-transformed. Invalidated modules are dropped from the graph, but Vite does not purge the process heap — the old module closures, source maps, and transform results become garbage that Node's collector reclaims on its own schedule.

Likely, but verify: The steady heap climb across reloads is the module graph plus Vite's transform cache growing as you edit files, combined with Node 20's GC being less aggressive about returning memory to the OS. Large dynamic imports add to the baseline because Vite caches their transformed output. None of this implies component instances are pinned across requests — Astro's rendering pipeline is stateless per request outside the Vite layer.

Answers to your three questions

1. Per-request cache clearing: No such flag exists, and you don't need one. SSR output is not cached between dev requests. If you want to confirm this, edit a component and reload — the change appears immediately, which demonstrates the render path is re-executed.
2. Vite's file cache on delete/rename: Vite's watcher invalidates the module graph entry on change and unlink events. The on-disk pre-bundling cache in node_modules/.vite is a separate concern; it is content-hashed and safe to delete manually (rm -rf node_modules/.vite) if you suspect staleness. Whether every rename edge case fully invalidates in your specific Vite version is worth verifying against the Vite changelog — treat this as version-dependent.
3. Manually purging integration caches: Generally no. Only do this if heap profiling shows a specific integration retaining objects across HMR cycles — that would be a bug in that integration, not normal behavior.

How to verify it's cache, not a leak

Start the dev server with inspection enabled:

node --inspect ./node_modules/.bin/astro dev

In Chrome DevTools' Memory tab, take a heap snapshot, reload the page 20–30 times, force garbage collection, and take another. If retained size plateaus after GC, you're looking at normal cache behavior. If it climbs monotonically, compare dominators between snapshots to find the retainer. As a control, run a production build (astro build then node ./dist/server/entry.mjs) under the same load — production has no Vite module graph, so growth there indicates a genuine application-level leak.

One detail that would change this advice: does the heap keep growing if you reload without editing any files? If yes, profile before assuming it's Vite — that pattern points away from HMR invalidation and toward something in your own request path.