Installing Node.js v14 on End-of-Life Ubuntu 16.10

Last updated: October 15, 2026

Ubuntu 16.10 is an interim release that has been past end of life for years. If 2016 is "your year" and upgrading the OS is not an option, Node.js v14 can still run on it through Node Version Manager. No compiling from source, no chasing external repositories—just a few commands and your legacy box gets a modern runtime.

What happened

• Ubuntu 16.10 is an end-of-life interim release, but nvm installs cleanly on it.
• The installer pulls the tool from the official nvm-sh GitHub repository.
• A few lines must be added to the shell profile so nvm persists in new sessions.
• Node.js v14.x is installed by default; specify the full version string to pin a specific build.
• An explicit alias step switches the default runtime when an older Node is already present.

Why bother with an EOL box

Only when the upgrade is impossible. A legacy CI runner, a kiosk device, or a long-frozen container are the usual suspects. Anywhere else, move off 16.10 first—you stop getting security patches the moment a release hits end of life.

For those who must stay, nvm is the lesser evil. It avoids touching apt entirely, so the package manager does not have to know about a newer Node. That isolation is exactly what you want on a system whose repositories are frozen in time.

Step-by-step install

Start by ensuring curl is present. Inside a Docker container, run an update first or apt will fail to find the package. Then elevate privileges and grab curl.

Download the nvm installation script from the project's repository and execute it in one pipeline. The script outputs environment setup that must be wired into your shell configuration.

These lines must persist in your shell profile—`.bashrc`, `.zshrc`, or equivalent. Without them, nvm only exists in the current session. Paste them in, open a fresh terminal, and run a quick check to confirm the command is recognized.

The environment configuration should point to a local directory where nvm stores its data, load the main nvm script, and optionally load bash completion support. Without these three pieces in place, the tool will not initialize properly across sessions.

Pulling down Node.js v14.x

With nvm loaded, trigger the installation for the v14 branch. Leaving the minor version unspecified fetches the newest patch release in that line. To lock to a precise build, pass the complete version number instead.

Verify the installation by querying the installed version. If another Node runtime was already set as default, use the alias command to make v14 the primary for all new shell sessions.

Our analysis

The win here is staying out of apt entirely. Mixing Node.js from the system package manager and from nvm is how teams lose entire afternoons to path confusion. Pick one method and stay consistent.

The risk is equally clear. Running any workload on an unsupported Ubuntu means unpatched kernel and library bugs. Anything reachable from the network needs hardening separately because the OS itself will not alert you to new CVEs.

Node.js v14 receives upstream updates, but Ubuntu 16.10 does not. Nvm buys you a modern runtime on an aging OS—it does not fix the underlying system. If the workload touches the open internet, treat the EOL box as temporary and set a hard deadline for the Ubuntu upgrade.

Who should care

What to watch next

• Confirm nvm is loaded in every shell profile a developer uses, not just the default one.
• Pin a specific Node.js v14.x version in production scripts to avoid surprise upgrades.
• Schedule the real Ubuntu upgrade before the next LTS release makes the gap obvious.

Key takeaways

• Use nvm, not apt, to keep Node and the OS package manager separate.
• Persist the nvm environment lines in the shell profile or the install is effectively lost.
• Treat EOL Ubuntu as a stopgap, not a destination, for any internet-facing workload.