What is the .next folder and what does it contain?

The .next folder is Next.js's build output and dev cache. It's created automatically when you run next dev or next build, and it should never be edited by hand or committed to git.

What's inside (after a production build):

• cache/ — incremental cache for the Next.js compiler. Lets next build reuse work between runs and powers HMR in dev. Also stores the Data Cache for ISR and fetch results.

• server/ — server-side bundles. Compiled Server Components, route handlers, page modules, middleware, and the manifest files Next uses to dispatch requests.

• static/ — client-side bundles, hashed for cache busting. Includes JavaScript chunks, CSS, and any imported static assets. Served at /_next/static/....

• standalone/ — only created when output: 'standalone' is set. A self-contained Node bundle with just the files needed to run the app, useful for Docker.

• BUILD_ID — a unique ID for this build, used in asset URLs and as part of cache keys.

• build-manifest.json, prerender-manifest.json, routes-manifest.json — metadata Next reads at runtime to map URLs to chunks, decide which routes are static vs dynamic, and identify ISR pages.

• trace — performance trace data from the build, useful for debugging slow builds with next build --profile.

Practical points:

• Always gitignore it — the default .gitignore from create-next-app already does. Generated artifacts shouldn't be in source control.

• Delete it to force a clean build — rm -rf .next when caching weirdness is making your life difficult. next build will rebuild from scratch.

• Don't ship it as your only artifact — for self-hosted deploys, you also need node_modules, public/, package.json, and next.config.js. Or use output: 'standalone' to get just what you need.

• Cache the right parts in CI — caching .next/cache between CI runs speeds up builds dramatically. Don't cache .next/static — it should always be regenerated to match the build.

• It can get big — for large apps, .next can be hundreds of megabytes. The standalone output strips this down to just the runtime essentials.

Treat it like a Webpack output directory — useful to inspect when debugging build issues, but otherwise an implementation detail you can ignore.