Node runtime pinning boundary when base image updates

Railway's Node.js runtime selection operates through the NODE_VERSION environment variable or the engines field in package.json, with a compatibility boundary where a requested major version absent from the current build image set causes the deployment to fail.

When platform updates replace base images or adjust Nixpacks defaults, the same application code may resolve to a different runtime without code changes, creating an implicit version shift. This behavior affects projects that rely on specific Node features or LTS timelines without explicit version pinning.

The precise goal is to determine whether Railway enforces an explicit pin requirement to guarantee consistent runtime selection across platform updates, or if implicit fallback mechanisms exist that may silently redirect builds to a different major version.

Is a NODE_VERSION pin required to prevent automatic runtime downgrade or rejection when the requested major is removed from the build image set? Does the presence of a package.json engines field take precedence over an unset NODE_VERSION env variable during buildpack resolution? How can operators observe which runtime version was actually selected for a deployment without modifying code?