8 released 30 May 2017, latest 8.17.0.
Node.js 8 reached end of life on 31 December 2019.
What changed
Compared with Node.js 6, Node.js 8 moved to the V8 5.8 engine and made async/await available without a runtime flag, enabling native promise-based asynchronous code. The cycle introduced npm 5 and package-lock.json, which made dependency-tree locking a standard workflow. It also added APIs such as util.promisify for adapting callback-based functions and async_hooks for observing asynchronous execution. HTTP/2 support was added during the cycle, initially as an experimental capability. These changes modernized application development, but Node.js 8 remains tied to an old JavaScript engine, npm generation, OpenSSL stack, and native-module ABI.
What staying costs
Node.js 8 has reached end of life, so it no longer receives vendor security fixes, bug fixes, or compatibility updates. Remaining on it leaves the runtime and its bundled cryptographic components exposed to known and newly discovered issues without an upstream remediation path. Dependency maintainers, build tools, test frameworks, and hosting platforms commonly stop testing old Node.js lines, so routine package updates can become difficult or force teams to retain vulnerable transitive dependencies. Native add-ons compiled for Node.js 8 may also become harder to build on current developer machines and CI environments. The longer the application remains on this line, the more its dependency lockfile, tooling, and deployment environment diverge from supported Node.js releases, increasing the size and risk of the eventual upgrade.
What to do
Plan a migration to a currently supported Node.js LTS line rather than treating Node.js 8 as a platform that can be hardened indefinitely. First, inventory applications, services, CI jobs, container images, and native dependencies that declare or assume Node.js 8. Update the application test suite before changing the runtime, then run it on the target Node.js version and address runtime, dependency, and build failures. Review uses of deprecated Node.js APIs, legacy Buffer construction, callback and promise error handling, TLS settings, and any assumptions about npm behavior. Rebuild and retest native add-ons for the target Node.js ABI. Upgrade the package manager deliberately, preserve reproducible dependency installation during the transition, and regenerate lockfiles only after validating the resulting dependency tree. Test production-like startup, outbound TLS connections, scheduled jobs, and observability integrations before deployment, then remove Node.js 8 from CI images, developer setup instructions, and runtime deployment configurations.
We can tell you what moving off Node.js 8 involves.
What it takes to move off Node.js 8 depends on what you built on it — the version you are on, how much depends on it, and how much of the work is mechanical. Leave your email with this version and we can tell you what that looks like for you.
Not sure yet? Get my plan
