Waseem Anjum

Agreed, and the argument point is the one I'd underline: everything you pass in becomes part of the key, so passing a whole user or session object instead of just the id you need fragments the cache fast. On stampedes, cacheLife already behaves that way inside its window: after the revalidate time the old entry keeps being served while it refreshes in the background, and only once it's past expire does a request wait for fresh data. revalidateTag with the 'max' profile gives you the same stale-while-revalidate behavior on a tag purge. And yes on multiple instances: the default handler is an in-memory LRU per process, so without a shared cacheHandlers entry like Redis each replica refreshes on its own schedule.

Thanks, Adam. Both came before the skill existed. I hit them while writing my Next.js security update guide, and the skill just packages what I learned there. npm audit didn't flag the October advisories for me, which is why the skill compares installed versions against the advisory table instead of trusting it. The sharp one showed up when I patched a 15.x app to 15.5.28: the lockfile kept sharp on 0.34.x, so the image optimizer was still exposed until I ran npm update sharp. That's the whole case for a Gotchas section. If the agent can't guess it and you only learn it by getting it wrong, it belongs in the skill.

Exactly. In my test the app files inside the standalone runner came to 59 MB, so most of the 287 MB is the Node base image itself. And non-root is only a couple of lines once the node user owns .next, so there's little reason to skip it.

Good call on keeping it a liveness check. The /api/health route in the post only returns a status and the process uptime, with no database call, and that's on purpose: if a DB blip fails the probe, Docker marks the container unhealthy and Coolify or Swarm can pull containers that are actually fine. If you want DB status, put it on a separate endpoint that your monitoring watches. On base images, I measured slim and Alpine in the same test: 287 MB on node:24-slim vs 229 MB on node:24-alpine. I didn't build a distroless variant or run a CVE scan, so I don't have numbers there. Sharp ships prebuilt musl binaries, so Alpine works for it, but I keep slim as the default because glibc is the safer bet for other native modules. A distroless runner with a Trivy or Docker Scout comparison would make a good follow-up.

Good point, thanks. In my test the page made one getSession() call and the proxy made another, so cache() wouldn't have changed the 4, but it matters as soon as a layout and a page (or a few server components) each check the session in the same render, since each call would otherwise cost 2 queries on Prisma 7. And yes, the proxy can't share that cache, which is one more reason to keep it as an optimistic redirect and do the real check in the page.