Node.js 26 enters LTS: how to upgrade a website or CRM
On October 28, 2026, the Node.js 26 branch moved into long-term support - LTS. The first release with this status was Node.js 26.13.0 Lithium. For teams that support a website, personal account, CRM or integration service on Node.js, a new version of the working platform has appeared with support planned until the end of April 2029.
The transition requires checking the application: dependencies, build, launch method and exchange with external systems. A running project on a supported branch 22 or 24 can first receive the latest fixes for its branch, and change the main version in a separate release. For Node.js 18 and 20, you need to plan to migrate from a platform that has already completed regular support.
Below is the procedure for selecting a version, preparing a test environment, and accepting the update. It is designed for developers, administrators and technical customers. Release details verified October 30, 2026; further patch versions and dependency requirements should be checked before your release.
What does Node.js 26 going to LTS mean?
B official announcement stated: version 26.13.0 changes the LTS status metadata and does not contain additional changes relative to 26.12.1. Therefore, this particular release should not be presented as a new set of features or a promise to speed up the site.
For a project, the practical change is the maintenance horizon of the selected branch. The team can plan updates, library support, and the next transition based on the published calendar. The LTS status itself does not confirm the compatibility of your ORM, framework, database driver or custom code.
Node.js Project Recommends use Active LTS or Maintenance LTS branches in production. Both statuses are suitable for production; the choice on a specific branch also depends on the application requirements and maintenance plan.
Which version to choose for October 30, 2026
The table shows the dates of normal support for the Node.js project by official schedule. This is a lifecycle calendar and not a guarantee of availability for a specific application.
| Branch | Status at the time of review | End of support | Team action |
|---|---|---|---|
| Node.js 18 | EOL, support ended | April 30, 2025 | Prepare a transition to a supported branch |
| Node.js 20 | EOL, support ended | April 30, 2026 | Check dependency constraints and plan migration |
| Node.js 22 | Maintenance LTS | April 30, 2027 | Install the latest fixes; determine the date of the next transition |
| Node.js 24 | Maintenance LTS from October 20, 2026 | April 30, 2028 | Maintain the current branch or prepare a proven transition to 26 |
| Node.js 26 | Active LTS from October 28, 2026 | April 30, 2029 | Consider for new project and migration after checking compatibility |
For an existing CRM, start choosing with its limitations. If a critical driver or library officially supports 24, but compatibility with 26 has not yet been confirmed, moving to 24 may be a reasonable interim step. Record the reason and date of the next inspection so that the temporary solution is not left without the owner.
Security updates and major version changes have different scopes. For example, October 21, 2026 fixes have been released for branches 22, 24 and 26. Receiving current fixes in a supported branch does not require automatically migrating the application to another major. But such a patch release also needs to be checked before production.
The general choice of language, base and architecture is discussed in material about the design of a custom CRM. The challenge here is to safely change the runtime environment of an existing JavaScript application.
First find all processes using Node.js
A website, an API, a queue handler, a bot, and scheduled tasks can run on one server. They may differ in Node.js version, application directory, and launch user. Updating the binary in one SSH session does not show what each service continues to run under.
Create a short inventory:
| Component | What to record | Why is this necessary? |
|---|---|---|
| Website or API | Node.js version, executable path, release directory, and startup command | Reproduce the current working configuration |
| Background handlers | Queues, schedule, task completion method | Don't lose your work and don't run it in parallel twice |
| Build and CI | Node.js and package manager versions, and the lockfile | Compare builds under identical conditions |
| Container | Base image and built image ID | Prepare repeatable deployment and rollback |
| Process Manager | User, interpreter, working directory and startup | Check startup after update and reboot |
In the selected environment, you can get information about the running Node.js command:
node -p 'JSON.stringify({node:process.version,execPath:process.execPath,platform:process.platform,arch:process.arch,modules:process.versions.modules,napi:process.versions.napi})'
npm --version
npm pkg get enginesThe first output is related to this call node, and not to all server processes. engines describes the stated limitations of the package; the absence of a field does not prove support for any version. Also check the actual running service and its configuration. There is no need to transfer environment secrets to the general report.
Check Linux dependencies and environment
Collect a list of components without which the main scenario cannot be executed: web framework, ORM, database drivers, PDF generation, image processing, cryptography, queues and integration SDKs. For each, you need the version, declared support for Node.js, and the result of testing in the target environment.
Native extensions require special attention. In Node.js documentation It is noted that changes to V8 may require adaptation and rebuilding of modules that use its API. This doesn't mean that any extension will necessarily break: the way it is implemented, including the use of Node-API, matters. Check the specific package.
The practical procedure is to re-install the dependencies in a separate build directory under the target Node.js and OS. Old node_modules, copied from another environment, can hide the problem until the first call to a rarely used function. The very fact of starting the server does not check this function.
There is a separate detail for official Linux binaries: the announcement of 26.13.0 reminds of the dependence on libatomic, introduced starting with Node.js 25. On some distributions, it needs to be installed separately. Check the requirements of the selected binary or image on a test machine; The installation command depends on the OS.
In the compatibility list, include working HTTPS connections, certificates, and proxies. Verify them with the same security requirements: disabling certificate verification for a successful request will hide the configuration problem.
Build a separate release with the saved lockfile
Before experimenting, save your current working release, launch configuration, and its Node.js details. Prepare backup copies of data according to project rules and check who will perform restoration if necessary. Then create a separate directory or test image for the candidate.
For an npm project with package-lock.json and customized script build a basic check looks like this:
# Run only in a separate candidate directory, never in the live release
node --version
npm --version
npm ci
npm run buildBy npm documentation, npm ci uses lockfile, fails if it doesn't match package.json and deletes the existing one node_modules before installation. Therefore, running this command in the directory of a live service is risky. Save the package manager settings with which the lockfile was created.
If the project uses Yarn or pnpm, use the lockfile installation it provides and the committed version of the manager. Do not change the runtime, the package manager and the entire set of dependencies at the same time unless necessary: if it fails, it will be more difficult to find the cause.
After installation, run existing tests and production build. The exact name of the test command depends on the project. Run the candidate on a separate local port or in a test environment, with data enabled and real mailings, payments and other external activities disabled.
For a server-rendered application, build and run the candidate under a consistent version of Node.js. Generating new files on top of the directory that serves the running process may mix the old configuration in memory with the new build result. A separate release makes it easier to verify code, file, and process compliance.
What to check in Docker and PM2
Docker: image composition and build tool
In the release card, save the exact base image and the ID of the resulting application image. The update must be reproducible: the team must understand which set of components has passed acceptance and which image is returned when rolled back.
B recommendations of official Node.js images It is noted that starting from Node.js 26 Yarn is absent from them. If the build relies on an already installed yarn, determine in advance how the project obtains the required version of the package manager. Check your image specifically: a custom Dockerfile can add its own tools.
As you transition, keep the boundaries of the experiment clear. If Node.js, the Linux image family, and the way native libraries are installed change at the same time, list each change and review it separately. The candidate must be tested on startup, shutdown, data access, and required network connections.
PM2: executable and startup
For PM2, check the application by its name and configuration file: fields cwd, script and interpreter. In interpreter You can specify an absolute path. This allows you to explicitly set which Node.js runs a particular service.
Separately check autostart after reboot. PM2 Documentation requires updating the startup configuration after updating the local version of Node.js. Otherwise, the verified manual startup and the next system startup may use different paths.
Make changes according to the plan of the desired application, preserving the previous configuration for rollback. A general restart of all processes is not an acceptance test for a single service being updated.
How to accept a website or CRM update
Successful HTTP response from the main page - the start of the test. After changing runtime, the actions for which the business uses the application are important. For each, prepare inputs, expected results, and confirmation of completion.
| Scenario | What to check | Evidence |
|---|---|---|
| Public pages | Home page, services, cases, required language versions | Correct HTTP codes, headers, canonical and content |
| Interface files | Scripts, styles, images and dynamic component loading | No loading errors or mixing of release files |
| Login and permissions | Regular user and restricted role | Your data is available, other people's records are closed |
| Application form | Reception, storage and subsequent delivery | Associated ticket and result identifier in CRM |
| Exchange and queues | One routine operation, temporary failure and repeat | The result is found; repetition does not create an extra action |
| Documents and files | Upload, download and generation, if provided | The file opens, rights are respected |
| Long-term connections | WebSocket or other connection used | The event comes, connection restoration works |
| Load | Comparable operations in old and new environments | Response time, errors, CPU, memory and queue status |
For forms, use the detailed scripts from articles about website integration with CRM. A message in the browser and a letter to the developer do not replace checking the full path of the request.
Do not assign a universal acceptable latency growth or observation time. Agree on boundaries before release based on current metrics and business scenario. If a background task is running at night, checking for a few minutes during the day does not confirm that it is working.
Prepare switchover and rollback
Before deployment, write down the conditions for stopping the release. For example: login fails, delivery of requests is disrupted, the number of errors in the agreed API is increasing, or the queue is stuck. For each condition, assign an observation and a decision maker.
The switchover plan should include:
- IDs of previous and new releases, Node.js version and dependencies.
- Confirmed candidate acceptance results.
- The order in which current queries and background operations are completed.
- Switching the desired application and checking again via a public address.
- Reverting the previous release along with its runtime and configuration.
- Checking records and tasks that appeared during the new version.
Rolling back the code does not cancel a payment that has already been made, a message sent, or a data change that has already been made. If the release includes changes to the database schema, check in advance the compatibility of the old application with the new schema. For runtime changes, it is useful to limit the scope of the release so that the return does not depend on multiple unrelated data transformations.
Check readiness for rollback on the test environment before production. A saved archive without launch instructions and a clear version of Node.js does not yet confirm that the previous service can be restored at the right time. Transferring an entire site with a change in location has a broader scope; there is a separate one for it corporate website migration checklist.
What to convey to the contractor for evaluation of work
Collect Node.js versions and dependencies, repository or composition of available sources, deployment method, list of processes, critical scenarios and maintenance window restrictions. Pass secrets separately through an agreed channel. Indicate what has already been verified and what remains unknown.
Ask to separate inspection, dependency adaptation, testing, release preparation, and post-switch maintenance. If package compatibility is not established, this uncertainty should be visible in the evaluation. There is no single cost for “updating Node.js” without such a survey.
Compatibility of the server part and integrations can be discussed within backend development. For an ongoing project, please agree separately support and SLA conditions: what metrics are monitored, who makes the decision to rollback, and how the team deals with the bug after release.
FAQ
Do you urgently need to transfer a properly working project from Node.js 24 to 26?
Moving 26 to LTS does not in itself end support for 24. Keep your supported branch current with patches and make a migration plan based on libraries and maintenance period. The urgency of a particular security update is determined by the security advisory and the usage of the affected features.
Is it possible to update only Node.js on the server, leaving the old dependencies?
This option needs to be checked as a separate candidate. Native extensions and other dependencies may have limitations. A clean install from a lockfile and tests in the target environment provide more information than migrating the old one node_modules and checking one screen.
Can upgrades be guaranteed without downtime?
This depends on the architecture, number of instances, session storage, background tasks, and switching method. The requirement for continuous operation is included in the project in advance and verified in a test deployment. No such guarantee can be given for one version of Node.js.
Do I need to update Node.js if my site consists of static files?
Check where it is used. Node.js can only participate in the build; then update and check the build environment. If there is an SSR, API, form processor, or standalone bot, their runtime requires self-validation.
Sources
- Node.js 26.13.0 Lithium: transition to LTS on October 28, 2026.
- Node.js branch support schedule.
- Node.js: release statuses and recommendations for production.
- Node.js Security Updates October 21, 2026.
- npm CLI v11: npm ci operating conditions.
- Node.js: native extension compatibility.
- PM2: Application Configuration Options.
- PM2: autostart after Node.js update.
- Official Docker images of Node.js: build recommendations.
The material was prepared according to documentation verified on October 30, 2026. Acceptance matrix and release order - engineering recommendations. They do not describe the completed NBM-IT migration and require adaptation to the specific application.