Building in the same directory the server reads from is a whole class of outage. This starter does not.
Why not build over the live directory?
Two failures made the case. An interrupted npm ci left node_modules empty; the site kept answering 200 from modules already resident in memory and only died at the next restart, four days later. Separately, an incremental build kept a reference to a Prisma client that had been regenerated under a new hash, so every database-backed page returned 500 while the static ones stayed green and the deploy reported success.
What does a release contain?
A standalone build carries its own minimal node_modules and a server.js. Because server.js bundles neither public/ nor .next/static, the deploy copies both into the release directory, then symlinks the shared .env so secrets survive releases and rollbacks.
How is a release verified before it goes live?
It is started on a staging port and polled until every smoke path answers 200. The set matters: one static route, one server-rendered route, and one list that reads the database. Checking only a static route is how a total database outage once passed as a healthy deploy.
What does a rollback actually restore?
Code, and only code. Migrations and content stay where they are. That is fine while migrations remain additive, and it is the reason a destructive migration turns an instant rollback into an incident.