Buildpack detection failure during Node.js runtime version mismatch

Answer

Buildpack detection on Scalingo is based on the presence of package.json. Runtime selection is separate and follows a deterministic priority: an explicit pin wins over engines.node, and a version outside the platform matrix causes a build rejection.

Conflict between engines.node and a pinned runtime

Confirmed fact: When a Node version is resolved from the app configuration, the buildpack provisions that version and the build proceeds. Rejection occurs only when the resolved version is absent from the currently supported matrix. Detection itself does not fail because of an engines mismatch.

Likely explanation: The buildpack resolves Node in Heroku-style order: NODE_VERSION environment variable or .nvmrc at repo root first, then engines.node in package.json, then platform default. If a pinned runtime is set, the buildpack installs the pinned version even if engines.node declares a different range. npm or yarn may emit an engines warning because the installed Node does not satisfy the declared range, but the build is not re-routed to the engines range. Non-deterministic fallback is observed when no explicit pin exists and engines.node specifies a range that matches multiple supported versions.

Deprecated but still listed version

Confirmed fact: A version that is outside the supported matrix is rejected after detection with an unsupported version error.

Likely explanation: If a Node version is deprecated by the platform but has not been removed from the supported matrix, the buildpack will still provision it deterministically when requested explicitly. The expected outcome is a successful build with a deprecation notice in the build log, not a rejection. Rejection requires removal from the matrix.

Steps needed for this case

1. Check the build log for the detected Node version line to see which source was used.
2. Verify the active pin sources in the app:

• Environment variable: scalingo env --app <app> | grep NODE_VERSION
• Repo file: cat .nvmrc if present
• Package manifest: grep -A2 '"engines"' package.json

1. Make the sources consistent. Remove or align the conflicting pin so the resolved version is inside the supported matrix.
2. Re-deploy and confirm the log reports the intended version without an unsupported version error.

One missing diagnostic detail that changes the recommendation: which pin source is currently active for your app, NODE_VERSION env var, .nvmrc, or neither? The resolution order and the fix depend on that.

Note: Behavior is version-sensitive and platform-specific. Scalingo can change its supported matrix and buildpack logic without notice. Deprecation warnings and fallback ordering may differ between buildpack releases and between Node, Yarn and pnpm variants.