A deploy for one of my services started failing unexpectedly today because its Node.js major version was suddenly upgraded from v16 to v17 tonight, and the OpenSSL v3 transition is likely a breaking change for many applications.
I understand that the first Node.js v17 stable release was cut in the past day.
I was able to resolve the issue just fine by for now by reverting to v16 with an explicit env-var declaration of NODE_VERSION for this service, which Render did honor as expected.
Just wanted to report this in case it took other folks by surprise, and suggest maybe revising the docs here:
The docs currently state that Render defaults to the latest LTS version of Node.
Last I checked, Node v17 is not an LTS release.
FWIW, this was an Elixir service. Maybe this issue is pervasive, or maybe it is specific to the default elixir service configuration.
Hi @ethan, thanks for reporting this! We’re looking into this on our end. In the meantime, like you mentioned, you can pin the version of Node via the methods in that doc.
Hi @ethan, after looking into this further, it does look like the default version we pull is 14.7.0, that is if a node version is not specified via any of the methods in the doc you linked (which it will weigh in order of precedence): Specifying a Node Version | Render. So, for example, if there were a package.json detected in your repo specifying a different node version, that could be a reason why we would pull a more recent version of node.
Hey Jade, I can assure you that prior to adding the env var to remediate this issue, none of the 4 listed config paths for specifying the Node version were applied to the service in question.
This is what got me wondering if maybe this is an issue specific to the default Elixir service configuration setup on render.
One last thought I had was maybe the presence of “engines” declaration in package-lock.json for a dependency was essentially setting the engine config even though I never explicitly declared in package.json. But from perusing my package-lock file could not find a dep that would have caused this.
Are there any other default node version altering config bits besides the 4 things listed in that support article?