How to deploy Node-RED application on a new machine

Hi,
I would like to deploy the Node-RED application on another computer that has the same Node-RED and Node.js versions installed.

I have copied folder "node_modules" and 2 files ".config.json", "package.json" at path "C:\Users\Admin\.node-red" to the respective location on the computer I want to deploy, but when starting the Node-RED application, the execution does not seem correct.

Please tell me the method of deploying Node-RED application on another computer without manually reinstalling the entire node from Palette.

Thanks!
Kiyo

You don't need node_modules. Copy the rest of the .node_red folder and then go into the folder in the command line and run
npm install

Also what do you mean by "does not seem to be correct"?

1 Like

Thank you for your support!
On the development machine I install many nodes to debug and test, the completed project does not have to use all the installed nodes, so I only want to deploy a part of the necessary node installed on the new machine, so how should I do it?
Delete unnecessary nodes in 2 files " .config.json ", " package.json ", then do as you instructed, right?

Also what do you mean by "does not seem to be correct"?
=> Because my operation was mistaken, I have solved it.

The ~/.node-red/package.json file will list everything you have installed on your development machine.

If you don't need all of those nodes on the new machine then edit the file and remove the unneeded nodes from the dependencies section.

You do not need to edit .config.json at all - although if you are using Node-RED 1.2.x, then .config.json is no longer used. You'll want to copy over .config.*.json - there will be four files that match that.

You don't need to delete them from .config.json, that will be handled automatically when node-red starts. If you want to guarantee that the deployed system has exactly the same versions of all nodes installed then you need to copy package-lock.json too, but then you would have to remove the unneeded nodes from that file, but that is not practical as the format is complex. If you are happy for the deployed system to use the latest valid versions of nodes (which may be later than on your development system) then don't include the lock file.
If you want to ensure exactly the same versions of nodes (which is the only way of guaranteeing the same behaviour) then you have no option as far as I can see other than installing all the nodes then removing the ones you don't need, or removing them on the development machine before you copy from it.

To be honest, I think you're overstating the risk here.

If you want the same versions of the nodes, you can edit the package.json file and remove the ~ from the version strings. You'll then get the same versions of the nodes. Yes, some underlying dependency version may change, but it would be frankly incredible if that broke anything (in my experience).

I don't think that is correct. The actual version installed in the development system may be later than the ~version, so removing the ~ would give the production system an earlier version than the development system.
I didn't say there is a big risk, but if you have a staging site you are testing on, and then want to put it into production, it ideally should use exactly the same versions. If not bothered about the exact versions then don't bother including the lock file. Then the production system may be later than the development, but one assumes this is less of a risk than having an earlier version.