Redeploy a Node.js application

3 min read07 November 2026

Redeploying is not just replacing files: it means installing dependencies, restarting the process and confirming the app still answers. On app hosting the operation happens from the panel, with no root and no built-in pipeline. A short, repeatable procedure avoids mixed states where old files sit next to new dependencies.

Before changing anything

  1. Back up: project archive, database export if it holds data, and any backup included in the plan.
  2. Note the current version: commit, release number or date.
  3. Read the changes: new required variable, database migration, required Node version.
  4. Prepare rollback: the previous archive must be downloadable and tested.

Do not make direct panel edits your only working copy. A file edited by hand and then overwritten by a deploy is a silent loss.

Replace the files

Depending on your panel, use the file manager, an archive import, Git or SFTP. The service root usually contains the project and node_modules. Two methods:

  • Stopped: stop the service, replace files, install, restart. Simple, with no mixed state.
  • Side by side: prepare a new copy, switch a link or folder, restart. Faster, but requires discipline with paths.

Remove obsolete files: an old module deleted from the code but still present can be loaded by mistake. Never copy node_modules from your machine, especially when native modules are involved.

Reinstall dependencies

With matching package.json and lockfile, npm ci installs exactly the locked versions and starts from a clean folder. Otherwise npm install updates the lockfile and may introduce versions you never tested.

Bash
npm ci
npm run build

If the build is not needed at runtime, install production only:

Bash
npm ci --omit=dev

A TypeScript app often needs dev dependencies to compile, then only production ones to run. Build before pruning, or install everything, compile, then remove.

Restart and check

Restart from the panel and read the log up to the listening line. Then test:

  • the health route, if any, for a 200;
  • a database read and write;
  • a page or route using static files;
  • the deployed version, if the app exposes it.

Watch memory and CPU for a few minutes: an incompatible native dependency usually shows up on the first call, not at startup.

Rollback

If the check fails, restore the previous archive, run npm ci, restart. Do not hot-fix a broken deploy before returning to a known state. Keep one note per deploy: date, version, commands run, result.

Advertisement

Was this article helpful?

Read next