Where Does Gatsby Store Cache and Build Output?
Gatsby caches build data in .cache and writes the deployable site to public, both inside your project folder and both safe to wipe.
Last updated
Gatsby keeps two generated folders inside the project, and telling them apart saves debugging time. The .cache folder holds Redux state, downloaded remote files, and the GraphQL schema between builds. The public folder is the static site you deploy. Static query results and processed images accumulate in the cache between builds, which is why the folder can grow surprisingly large on image-heavy sites.
Both are disposable by design. gatsby clean wipes them together, which is the standard first step when a build breaks after dependency changes. Never hand-edit inside .cache; the next build overwrites it without asking.
Where Gatsby stores this, by platform
[SiteDir]\.cache
Build cache: page data, schema, downloaded assets. Wipe it with gatsby clean when builds act stale. Contents regenerate from gatsby-config and src.
[SiteDir]/.cache
Same in-folder layout on macOS. Deploy output goes to public beside it. Node modules stay in node_modules; Gatsby-specific state is only ever these two folders.
[SiteDir]/.cache
Same arrangement. CI runners benefit from caching .cache between runs for speed, but a poisoned cache is also the classic CI failure, so bust it when builds go weird.
Frequently asked questions
My Gatsby build fails after upgrading a plugin. What resets it?
Run gatsby clean (it deletes .cache and public) and rebuild. Stale GraphQL schema and plugin caches cause most mysterious build failures, and a clean rebuild resolves them.
Should .cache and public be committed?
Yes. Both regenerate from source on every build. Commit gatsby-config, gatsby-node, src, and static. The starter template's .gitignore already excludes the right folders.
Notice an outdated path? Let us know.