Node-RED is a low-code development platform for building automations, integrations, and event-driven applications through visual flows. Instead of implementing every connection in a traditional backend, users combine reusable nodes that receive data, transform messages, call APIs, interact with databases, and deliver results to other services.
The platform runs on Node.js and is widely used for integrating cloud applications, IoT devices, messaging systems, web services, databases, and internal business tools.
Node-RED can run on a local computer, inside a container, on a single-board device, or on a virtual private server. A VPS is a practical choice for workflows that must operate continuously because the automation remains available even when the administrator’s computer is turned off.
This guide explains how to deploy Node-RED through the Serverspace control panel, access the new VPS, open the visual editor, create a first flow, build an HTTP endpoint, configure authentication, connect a domain, enable HTTPS, protect credentials, back up the environment, and troubleshoot common problems.
What Is Node-RED?
Node-RED uses a flow-based programming model in which an application is assembled from individual functional blocks called nodes.
Each node performs a specific operation, for example:
- receive an HTTP request;
- send data to an external API;
- subscribe to an MQTT topic;
- parse or generate JSON;
- run custom JavaScript;
- write information to a database;
- send a notification to a messaging service;
- start an operation on a schedule;
- read or write a file;
- display data in the debug sidebar.
Nodes are placed in the visual editor and connected with wires. The resulting automation is called a flow.
After changing the flow, the user clicks Deploy. Node-RED then applies the configuration and starts running the updated logic.
Common Node-RED Use Cases
Node-RED is useful when several systems need to exchange data or react to events without requiring a complete custom application.
Typical use cases include:
- connecting several REST APIs;
- processing incoming webhooks;
- building Telegram bot workflows;
- collecting data from IoT devices;
- publishing and receiving MQTT messages;
- creating internal monitoring dashboards;
- sending alerts when a condition is met;
- synchronizing CRM platforms, spreadsheets, and databases;
- running periodic maintenance tasks;
- converting JSON, XML, CSV, or text data;
- prototyping integrations before developing a dedicated backend;
- controlling sensors, controllers, and smart devices.
The visual editor makes Node-RED especially convenient for rapid prototyping. A developer can verify an integration idea before investing time in a larger production application.
Node-RED vs Traditional Application Development
In a conventional backend project, a developer usually needs to:
- create the application structure;
- install libraries;
- define routes;
- process events;
- implement retries and error handling;
- organize logging;
- connect external services;
- prepare deployment scripts.
Node-RED represents many of these operations as configurable nodes.
For example, a small HTTP service can be assembled from three components:
A flow that receives an MQTT event and sends a notification might look like this:
The visual approach does not eliminate programming completely. The Function node allows developers to write JavaScript when the built-in nodes are not sufficient.
Core Node-RED Concepts
The editor uses several important concepts:
- Node — an individual processing or integration component.
- Flow — a group of connected nodes.
- Message — the object passed between nodes.
- Palette — the list of available nodes.
- Workspace — the central area where flows are designed.
- Deploy — the operation that applies changes.
- Context — storage available to nodes and flows.
- Subflow — a reusable group of nodes.
- Configuration node — a shared connection configuration, such as an MQTT broker.
Most nodes receive a JavaScript object named msg, modify it, and pass it to the next node.
The main data is commonly stored in:
A message can also contain other properties:
msg.headers
msg.statusCode
msg.filename
Why Run Node-RED on a VPS?
A local installation is suitable for learning and development, but production automations require an environment that remains online.
A VPS provides:
- continuous operation of deployed flows;
- a stable public IP address;
- the ability to receive webhooks from external services;
- remote access to the editor;
- centralized storage of configuration and credentials;
- administration through SSH;
- an isolated environment for integrations;
- scalable CPU, RAM, storage, and bandwidth;
- a more predictable backup strategy.
Running Node-RED on a separate server also prevents automation workloads from interfering with the administrator’s personal computer.
Recommended Server Resources
Node-RED itself is relatively lightweight. Actual requirements depend on the number of flows, message frequency, payload size, installed modules, and external services.
A small test environment can start with:
- 1 vCPU;
- 1–2 GB of RAM;
- 10–20 GB of SSD or NVMe storage;
- Ubuntu Server;
- a public IPv4 address.
For several persistent integrations, consider:
- 2 vCPUs;
- 2–4 GB of RAM;
- 20–40 GB of SSD or NVMe storage;
- network bandwidth suitable for the expected traffic.
Additional resources may be required when:
- flows process a high number of messages;
- large JSON documents are passed between nodes;
- Function nodes perform CPU-intensive operations;
- a database runs on the same VPS;
- many third-party modules are installed;
- the server processes files, images, or media;
- dashboards serve many concurrent users.
Network Ports
A basic Node-RED deployment may use the following ports:
| Port | Purpose | Recommendation |
|---|---|---|
| 22/TCP | SSH administration | Use SSH keys and restrict access where possible |
| 1880/TCP | Node-RED editor and HTTP endpoints | Do not expose publicly without authentication |
| 80/TCP | HTTP | Used by a reverse proxy and certificate validation |
| 443/TCP | HTTPS | Recommended for remote browser access |
| 1883/TCP | MQTT without TLS | Required only when a local MQTT broker is used |
| 8883/TCP | MQTT over TLS | Preferred for public MQTT connections |
Do not open all ports automatically. The required firewall rules depend on the integrations enabled in the environment.
Deploying Node-RED Through the Serverspace Control Panel
Node-RED is available in the Serverspace application catalog.
Using a prepared application removes the need to manually install Node.js, npm, Node-RED, and the initial dependencies. Serverspace creates the virtual machine and prepares the service for the first connection.
Step 1. Start Creating a Server
Sign in to the Serverspace control panel, open the vStack cloud section, and click Create server.
The server creation wizard will open.
Step 2. Select Node-RED
Open the Applications or 1-Click Apps tab.
Find Node-RED in the catalog and select it.
The prepared image reduces the number of installation steps and allows you to start creating flows sooner.
Step 3. Choose the Data Center
Select the region in which the virtual machine will be deployed.
Consider:
- the location of users;
- latency to external APIs;
- the location of MQTT brokers;
- data residency requirements;
- the region of databases and other project components.
When Node-RED frequently communicates with another server, placing both systems close to each other can reduce network latency.
Step 4. Configure the VPS
Select:
- the number of vCPUs;
- the amount of RAM;
- the disk size;
- network bandwidth;
- the virtual machine name.
For several lightweight automations, you can start with:
- 1–2 vCPUs;
- 2 GB of RAM;
- 20 GB of NVMe storage.
Example server names:
or:
Step 5. Configure SSH Access
Choose an authentication method:
- a root password;
- an SSH public key.
SSH key authentication is recommended for a production server.
Never:
- commit the private key to Git;
- store it in the Node-RED directory;
- send it through an unprotected chat;
- place it inside a flow;
- publish it in documentation.
Step 6. Deploy the Server
Review the selected parameters and start the deployment.
Serverspace will automatically:
- allocate the selected resources;
- create the virtual disk;
- assign a public IP address;
- install the operating system;
- deploy Node-RED;
- prepare the VPS for access.
Wait until the instance status changes to Active.
Why Deploy Node-RED in Serverspace?
This deployment model separates infrastructure management from automation design.
Serverspace is used to manage:
- virtual CPUs;
- RAM;
- disk capacity;
- the public IP address;
- network settings;
- the virtual machine lifecycle.
Node-RED is used to manage:
- flows;
- nodes;
- API integrations;
- MQTT connections;
- environment variables;
- credentials;
- message transformation;
- error handling.
The administrator can change VPS resources without rebuilding the flows.
Isolate Automation Workloads
A separate VPS is recommended when Node-RED connects to important services.
Isolation helps:
- limit access to unrelated application files;
- configure separate firewall policies;
- monitor resource usage independently;
- update Node-RED without affecting other systems;
- reduce the impact of a faulty flow;
- simplify backups and recovery.
Separate Production and Testing
Production and experimental flows can run on different servers:
| Server | Purpose | Example Resources |
|---|---|---|
| node-red-production | Production integrations | 2 vCPUs, 4 GB RAM |
| node-red-staging | Testing changes and new nodes | 1–2 vCPUs, 2 GB RAM |
| node-red-iot | IoT and MQTT workloads | 2 vCPUs, 2–4 GB RAM |
Do not install an untested node directly on the production server.
Connecting to the VPS via SSH
Copy the public IP address from the Serverspace control panel.
Connect to the server:
Replace YOUR_SERVER_IP with the actual public address.
During the first connection, SSH will display the host fingerprint. Review it and confirm:
Enter the root password or use the private key associated with the selected public key.
Checking the Node-RED Installation
Display the Node.js version:
Check npm:
Check Node-RED:
List running processes:
Confirm that port 1880 is listening:
Opening the Node-RED Editor
Open the following address in a browser:
Replace YOUR_SERVER_IP with the public IP of the VPS.
The Node-RED editor should appear.
The main interface areas are:
- Palette on the left — available nodes;
- Workspace in the center — the flow diagram;
- Sidebar on the right — help, node information, and debug output;
- Deploy at the top — applies changes.
The editor may initially be accessible without a login. Do not leave port 1880 publicly exposed after completing the initial test.
Creating the First Flow
Create a simple flow that sends a message to the debug sidebar.
Step 1. Add an Inject Node
Drag the Inject node from the palette to the workspace.
The node can trigger the flow manually when its button is pressed.
Step 2. Add a Function Node
Drag a Function node to the workspace and connect it to Inject.
Open the Function node and add:
return msg;
Save the node.
Step 3. Add a Debug Node
Drag a Debug node into the workspace and connect it to Function.
The complete flow should look like this:
Step 4. Deploy the Flow
Click Deploy.
Press the button on the left side of the Inject node.
The debug sidebar should display:
Creating a Simple HTTP Endpoint
Node-RED can expose lightweight HTTP APIs.
Add the following nodes:
- HTTP In;
- Function;
- HTTP Response.
Connect them:
Configure HTTP In:
- Method: GET
- URL: /api/status
Add the following code to Function:
status: "ok",
service: "node-red"
};
msg.headers = {
"Content-Type": "application/json"
};
return msg;
Click Deploy.
Test the endpoint:
Expected response:
How the msg Object Works
Nodes exchange a JavaScript object named msg.
Example:
"payload": "temperature",
"topic": "sensor/room1",
"value": 24.5
}
A Function node can update its properties:
msg.unit = "F";
return msg;
If the Function node does not return a message, the flow will not continue.
To stop processing deliberately, use:
Installing Additional Nodes
Extra integrations can be installed directly from the editor.
Open:
- the main menu;
- Manage palette;
- the Install tab;
- search for the required package;
- review its details and install it.
Third-party packages can add support for:
- Telegram;
- PostgreSQL;
- MySQL;
- Redis;
- Home Assistant;
- Prometheus;
- cloud services;
- dashboard components.
Before installing a package, review:
- the latest release date;
- download statistics;
- the source repository;
- dependencies;
- reported issues;
- compatibility with the installed Node-RED version.
Where Node-RED Stores Its Data
In a standard user installation, Node-RED data is commonly stored in:
The directory may contain:
- flow definitions;
- encrypted credentials;
- settings.js;
- installed modules;
- package.json;
- context data;
- project files.
The exact location depends on the system user, installation method, and configured userDir.
The active user directory is normally displayed in the Node-RED startup log.
Configuring settings.js
The main runtime configuration is stored in:
Create a backup before editing:
The file can be used to configure:
- the listening port;
- the network interface;
- the editor path;
- authentication;
- HTTPS;
- context storage;
- Function node settings;
- logging;
- the credentials encryption secret.
Restart Node-RED after changing the file.
Why the Editor Must Be Protected
The Node-RED editor allows users to:
- view existing flows;
- modify automation logic;
- install nodes;
- send requests to external APIs;
- create Function nodes;
- use configured integrations;
- deploy modified flows.
An unauthorized user who reaches the editor may be able to change production automation or abuse stored service connections.
Public access without authentication should only be considered inside a trusted isolated network.
Generating a Password Hash
Node-RED editor authentication uses a password hash.
Install the administration CLI if it is not already available:
Generate the hash:
Enter the desired password.
The tool will return a string similar to:
Copy the hash for the adminAuth configuration.
Enabling Editor Authentication
Open settings.js:
Find or add:
type: "credentials",
users: [{
username: "admin",
password: "$2b$08$EXAMPLE_HASH",
permissions: "*"
}]
},
Replace the example hash with the generated value.
Save the file and restart Node-RED.
The editor will now require a username and password.
Protecting HTTP Endpoints
Editor authentication and HTTP In routes are configured separately.
Basic authentication for HTTP endpoints can be enabled with httpNodeAuth:
user: "apiuser",
pass: "$2b$08$EXAMPLE_HASH"
},
After restarting Node-RED, send authenticated requests:
For public APIs, a token-based mechanism, reverse proxy, or dedicated API gateway may be more appropriate.
Configuring credentialSecret
Node-RED stores node credentials in an encrypted file.
To use a persistent encryption key, add the following setting:
Use a long random value.
The secret must be included in the backup strategy. If the credentials file is restored without the correct key, Node-RED cannot decrypt stored passwords and tokens.
Secure Access Through an SSH Tunnel
If only administrators require the editor, port 1880 does not need to be exposed publicly.
Create an SSH tunnel:
Then open locally:
(http://127.0.0.1:1880[/code)]
Advantages:
- port 1880 remains hidden from the Internet;
- traffic is encrypted by SSH;
- existing SSH authentication is reused;
- no domain is required;
- no certificate is needed for temporary administrative access.
Connecting a Domain
For regular browser access, create a dedicated subdomain:
Add an A record:
| Type | Name | Value |
|---|---|---|
| A | node-red | YOUR_SERVER_IP |
Verify DNS resolution:
The command should return the VPS public IP address.
Configuring Nginx as a Reverse Proxy
Install Nginx:
sudo apt install nginx -y
Create a new virtual host:
Add:
listen 80;
server_name node-red.example.com;
```
location / {
proxy_pass http://127.0.0.1:1880;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
```
}
Enable the configuration:
Test Nginx:
Reload the service:
Obtaining an SSL Certificate
Install Certbot:
Request a certificate:
After the certificate is installed, open:
(https://node-red.example.com[/code)]
HTTPS encrypts the connection but does not replace editor authentication. Keep adminAuth enabled.
Configuring the Firewall
Allow SSH:
For a reverse proxy, allow HTTP and HTTPS:
sudo ufw allow 443/tcp
Enable UFW:
Review the rules:
Once Nginx is configured, port 1880 does not need to be publicly accessible.
Before enabling the firewall, open a second SSH session and verify that the server remains reachable.
Running Node-RED as a System Service
Node-RED should start automatically after a VPS reboot.
Search for the installed service:
Check the status:
or:
Restart the service:
Enable automatic startup:
The exact service name depends on how the prepared application was built.
Viewing Node-RED Logs
For a systemd service, use:
Follow new entries:
Display the last 100 records:
Replace nodered if the service uses another name.
The startup logs can reveal:
- runtime errors;
- the active settings.js path;
- the userDir location;
- module loading problems;
- port conflicts;
- flow errors;
- failed external connections.
Using Environment Variables
Avoid storing tokens and passwords directly in Function nodes.
Define a variable such as:
Read it in a Function node:
msg.headers = {
Authorization: "Bearer " + token
};
return msg;
Environment variables simplify:
- migration between environments;
- secret rotation;
- separation of production and staging;
- safe sharing of exported flows.
Node-RED Context Storage
Node-RED supports three context scopes:
- node — available only to the current node;
- flow — shared by nodes in the current flow;
- global — available to all flows.
Store a value:
Read it:
By default, context may be stored in memory and lost after a restart.
For persistent values, configure filesystem-based context storage.
Enabling Persistent Context
Add the following to settings.js:
default: {
module: "localfilesystem"
}
},
After restarting Node-RED, context values will be periodically written to disk.
Filesystem context is appropriate for small state values but should not replace a database for large datasets or transactional information.
Handling Errors in Flows
Node-RED includes several nodes for operational visibility:
- Catch — receives errors from other nodes;
- Status — tracks node status changes;
- Complete — triggers when a node finishes processing;
- Debug — displays messages in the editor;
- Log — writes operational events.
An error notification flow might look like this:
Production automations should handle:
- unavailable APIs;
- request timeouts;
- authentication failures;
- unexpected payload formats;
- duplicate event delivery;
- database outages;
- rate-limit responses.
Preventing Infinite Loops
Incorrectly connected nodes can create a loop that continuously generates messages.
Possible consequences:
- high CPU usage;
- increased memory consumption;
- large numbers of API requests;
- rapid log growth;
- temporary blocking by external services.
For repeating operations, use:
- Delay nodes;
- rate limits;
- retry counters;
- stop conditions;
- timeouts;
- maximum retry limits.
Backing Up Node-RED
A backup should include:
- flows;
- credentials;
- settings.js;
- package.json;
- package-lock.json;
- custom nodes;
- projects;
- credentialSecret;
- environment variable documentation or a secure secret export.
Create an archive of the user directory:
Do not keep the only copy on the same VPS.
The archive may contain sensitive information. Therefore:
- restrict file permissions;
- encrypt the backup;
- avoid public storage;
- do not send it through unsecured channels.
Exporting and Importing Flows
To export a flow:
- select the required nodes;
- open the main menu;
- choose Export;
- copy the generated JSON.
To import:
- open the menu;
- choose Import;
- paste the JSON;
- place the nodes in the workspace;
- review the configuration;
- click Deploy.
Exported JSON may reveal the structure of integrations. Review it before sharing publicly.
Node-RED Security Checklist
- Do not leave the editor without authentication.
- Do not expose port 1880 directly to the Internet.
- Use an SSH tunnel or reverse proxy.
- Enable HTTPS.
- Configure adminAuth.
- Protect HTTP endpoints separately.
- Set a persistent credentialSecret.
- Do not place tokens directly in Function nodes.
- Review third-party packages.
- Separate production and testing environments.
- Restrict the system user’s permissions.
- Update the operating system and Node-RED regularly.
- Keep external backups.
- Monitor logs and resource usage.
- Configure request rate limits where required.
Useful Commands
| Action | Command |
|---|---|
| Check Node.js | node --version |
| Check npm | npm --version |
| Check Node-RED | node-red --version |
| Check port 1880 | sudo ss -lntp | grep 1880 |
| Check the service | sudo systemctl status nodered |
| Restart the service | sudo systemctl restart nodered |
| Follow the logs | sudo journalctl -u nodered -f |
| Check memory | free -h |
| Check disk usage | df -h |
Common Node-RED Problems
The Editor Does Not Open
Check the listening port:
Check the process:
Review the firewall:
Test locally:
(http://127.0.0.1:1880[/code)]
If the local request succeeds, investigate the firewall, reverse proxy, or cloud networking rules.
Port 1880 Is Already in Use
Find the process:
or:
Stop the conflicting service or change the Node-RED port in settings.js.
Node-RED Does Not Start After Editing settings.js
A syntax error is a common cause.
Check the journal:
Restore the backup:
Restart the service.
Some Nodes Appear as Unknown
The imported flow depends on a package that is not installed.
Check:
- the missing node type;
- package.json;
- Manage palette;
- package compatibility;
- npm installation errors.
Install the required module and restart Node-RED.
Stored Credentials Cannot Be Decrypted
The environment may be using the wrong credentialSecret.
Verify that:
- the original secret is configured;
- settings.js was restored correctly;
- the credentials file matches the flow file;
- a new random secret was not generated during migration.
Without the correct secret, passwords and tokens must be entered again.
A Flow Does Not Run After Deployment
Check:
- the Debug sidebar;
- node status messages;
- wires between nodes;
- whether Function returns msg;
- whether a node is disabled;
- availability of external services.
Add Debug nodes after important stages to locate where processing stops.
Node-RED Uses Too Much CPU
Possible causes:
- an infinite loop;
- an Inject node running too frequently;
- a large stream of messages;
- a faulty third-party node;
- CPU-intensive JavaScript;
- retries without a delay.
Check system load:
Disable suspicious flows temporarily and add rate limiting.
The VPS Runs Out of Memory
Check memory:
List the largest processes:
If memory pressure is persistent:
- increase the VPS RAM;
- reduce message sizes;
- store less context in memory;
- remove unnecessary modules;
- move resource-intensive tasks to a separate service.
When Node-RED Is a Good Choice
| Requirement | Is Node-RED Suitable? |
|---|---|
| Connect several APIs | Yes |
| Process MQTT and IoT events | Yes |
| Create a webhook handler | Yes |
| Build an automation prototype quickly | Yes |
| Build a high-load application with complex business logic | A dedicated backend may be more appropriate |
| Publish the editor without authentication | No |
Frequently Asked Questions
What is Node-RED?
Node-RED is a Node.js-based low-code platform for building automations and integrations from visually connected nodes.
Can I deploy Node-RED through the Serverspace control panel?
Yes. Select Node-RED from the 1-Click Apps catalog while creating a cloud server. Serverspace will prepare the virtual machine and application automatically.
How many resources does Node-RED require?
A small test project can run with 1 vCPU, 1–2 GB of RAM, and 10–20 GB of storage. Several persistent flows may require at least 2 GB of RAM.
Which port does Node-RED use?
The editor and HTTP endpoints use TCP port 1880 by default.
Is it safe to expose port 1880 to the Internet?
Not without authentication. Use an SSH tunnel or a reverse proxy with HTTPS, and enable adminAuth for the editor.
Can Node-RED be used to create an API?
Yes. HTTP In, Function, and HTTP Response nodes can be used to create custom routes that return JSON or other content.
Where are Node-RED flows stored?
In a standard installation, user data is often stored in ~/.node-red. The exact location depends on the userDir setting and installation method.
Can Node-RED connect to MQTT?
Yes. Built-in MQTT nodes can subscribe to topics and publish messages through an MQTT broker.
How should passwords be stored in flows?
Use node credentials, a persistent credentialSecret, and environment variables. Do not place API tokens directly in Function nodes.
Can I install additional Node-RED nodes?
Yes. Packages can be installed through Manage palette or npm. Review the source, maintenance status, and compatibility before installing third-party modules.
Does Node-RED need backups?
Yes. Back up flows, credentials, settings.js, package files, custom nodes, and credentialSecret. Keep at least one copy outside the VPS.
Can Node-RED be used in production?
Yes, provided that authentication, HTTPS, backups, monitoring, error handling, and restricted editor access are configured.
Deploy Node-RED with Serverspace
The Node-RED application in Serverspace allows you to create an automation server without manually installing Node.js, npm, and the platform.
After deployment, you receive:
- a dedicated virtual machine;
- a public IP address;
- an installed Node-RED environment;
- configurable computing resources;
- SSH access to the server;
- the ability to receive webhook requests;
- support for API, MQTT, and third-party integrations;
- full control over flows and runtime configuration.
This environment is suitable for:
- cloud service integrations;
- IoT projects;
- notification automation;
- internal tools;
- webhook processing;
- rapid prototyping.
The administrator retains control over firewall rules, updates, logs, domains, certificates, and backups.
Conclusion
Node-RED simplifies automation development by providing visual flows and reusable nodes for APIs, MQTT, databases, files, messaging platforms, and other services.
The platform is useful for developers, system administrators, IoT engineers, and organizations that need to connect different applications quickly.
Deploying Node-RED through Serverspace reduces the amount of initial server preparation. Select Node-RED from the application catalog, configure the VPS resources, and deploy the virtual machine.
After the first login, protect the editor, configure HTTPS or an SSH tunnel, restrict network access, preserve credentialSecret, and organize external backups.