Compilar en el mismo directorio del que lee el servidor es toda una familia de incidentes. Este starter no lo hace.
¿Por qué no compilar sobre el directorio en vivo?
Lo demostraron dos fallos. Un npm ci interrumpido dejó node_modules vacío; el sitio siguió respondiendo 200 con los módulos ya cargados en memoria y solo murió en el siguiente reinicio, cuatro días después. Aparte, una compilación incremental mantuvo la referencia a un cliente de Prisma regenerado con otro hash, así que todas las páginas con base de datos devolvían 500 mientras las estáticas seguían en verde y el despliegue informaba de éxito.
¿Qué contiene una release?
Una compilación standalone lleva su propio node_modules mínimo y un server.js. Como server.js no incluye ni public/ ni .next/static, el despliegue copia ambos en el directorio de la release y enlaza el .env compartido para que los secretos sobrevivan a releases y reversiones.
¿Cómo se verifica una release antes de publicarla?
Se arranca en un puerto de staging y se consulta hasta que todas las rutas de humo respondan 200. El conjunto importa: una ruta estática, una renderizada en servidor y una lista que lee la base de datos. Comprobar solo una ruta estática es como una caída total de la base de datos pasó por un despliegue sano.
¿Qué restaura realmente una reversión?
El código, y solo el código. Las migraciones y el contenido se quedan donde están. Es aceptable mientras las migraciones sean aditivas, y es la razón por la que una migración destructiva convierte una reversión instantánea en un incidente.