Package a Next.js app for self-hosted deployment without guessing at a Dockerfile

You are packaging a Next.js app for self-hosted deployment in a container, using output: 'standalone' in next.config so the resulting image ships only what the app actually traces as needed at runtime, rather than the entire node_modules tree or a Dockerfile improvised from a generic Node.js template.

APP DETAILS
A Next.js 16 App Router app using the pnpm package manager, with a mix of static and ISR-revalidated pages

DEPENDENCIES WITH NATIVE OR BUILD-STEP REQUIREMENTS
sharp for image processing, which needs its native binary matched to the container's target platform architecture

CACHING NEEDS
Will run as 2-3 horizontally scaled replicas behind a load balancer, so per-replica ISR cache regeneration is a real concern, not a hypothetical

CONTAINER PLATFORM
A self-managed Kubernetes cluster

BUILD RULES
Set output: 'standalone' in next.config so the build produces a minimal, traced .next/standalone directory containing only the files and dependencies the app actually needs at runtime, then structure the Dockerfile as a genuine multi-stage build: one stage installs dependencies and runs the build, a second, much smaller final stage copies only .next/standalone, .next/static, and the public directory into a lean base image, rather than copying the entire repository including devDependencies and source files that have no runtime purpose into the final image. Run the container as a non-root user in the final stage, and explicitly copy in and use whatever Node.js version matches what the app was built and tested against, rather than floating on whatever "latest" tag a base image happens to resolve to at build time, since an unpinned base image can silently change the app's runtime environment between builds with no code change at all. Address the ISR cache-persistence question directly rather than leaving it implicit: a standalone container's filesystem cache for revalidated pages lives inside that specific container instance, so a fresh container — from a restart, a redeploy, or a horizontally scaled second instance — starts with an empty cache and has to regenerate every ISR page from scratch on its next request, which is a real, working behavior but a different one than a long-running single server would have, and if this container needs to run as multiple replicas, either accept that each replica regenerates its own cache independently, or configure a custom cache handler backed by a shared store such as Redis so all replicas share one cache instead of each maintaining its own. Confirm which environment variables the app needs at build time versus runtime, since a value baked into the standalone build during the image build stage cannot be changed later just by setting a different environment variable when the container starts — if a variable genuinely needs to differ per deployment without rebuilding the image, it has to be read at runtime inside the app, not consumed only during the build.

OUTPUT FORMAT
The complete multi-stage Dockerfile, the exact next.config.ts change, and one paragraph specifically addressing what happens to ISR-cached pages across a container restart or a horizontally scaled second replica, given the caching needs stated above.