How to Install Node-RED on Ubuntu 24.04 VPS — Visual Flow-Based Programming for IoT and Automation

Node-RED turns the messy plumbing of APIs, MQTT brokers, databases, and hardware sensors into a drag-and-drop canvas of nodes and wires. Instead of writing glue code, you wire together pre-built blocks — HTTP inputs, function transformers, database writes, MQTT publishes — and watch messages flow between them. This guide takes you from a blank Ubuntu 24.04 VPS to a hardened, HTTPS-enabled Node-RED server running as a systemd service, with your first end-to-end flow pushing data to an MQTT broker.

Prefer a turnkey deploy? Launch a CloudCore Starter VPS and follow this tutorial in under 25 minutes — the plan includes everything Node-RED needs for small and medium IoT workloads.

Table of Contents

What is Node-RED?

Node-RED is a flow-based programming environment built on Node.js. Originally developed by IBM Emerging Technology in 2013 and now stewarded by the OpenJS Foundation, it has become the de facto visual automation tool for IoT, home automation, and integration workloads. You edit flows in a browser-based editor, wire nodes together with your mouse, and click deploy — the runtime immediately executes your flows without a compile step.

Each node is a small JavaScript module that processes messages. Input nodes trigger on HTTP requests, MQTT topics, websockets, TCP streams, serial port data, schedules, or file watches. Processing nodes split, join, filter, delay, template, or transform messages via inline JavaScript in function nodes. Output nodes publish to MQTT, write to databases (InfluxDB, PostgreSQL, MongoDB), send emails, invoke webhooks, push to Slack, or drive GPIO pins on connected hardware. The official catalog at flows.nodered.org lists over 4,500 community nodes covering everything from Philips Hue lights to Modbus industrial protocols to Google Sheets.

Typical deployments range from hobbyist projects (turning on a light when a motion sensor fires) to production industrial gateways ingesting Modbus and OPC-UA telemetry, normalising it, and pushing to a time-series database. The node-red-dashboard palette turns flows into responsive web UIs without writing frontend code — gauges, charts, sliders, and buttons bound to live message streams. This makes Node-RED a compelling choice for quickly prototyping operational dashboards, device control panels, and small SCADA-style interfaces.

Why Self-Host Node-RED on Your VPS?

Running Node-RED on your own VPS — rather than on a Raspberry Pi in your closet or a managed cloud offering — gives you a durable, internet-reachable automation hub that survives home power cuts and ISP outages:

• Always-on reachability — A VPS has a static public IP, runs 24/7, and is accessible from anywhere. Perfect for webhook receivers, scheduled tasks, and MQTT bridges that must stay online.
• No hardware to maintain — SD cards in Raspberry Pis corrupt over time. A VPS runs on enterprise-grade NVMe storage with automatic hypervisor-level redundancy.
• Predictable performance — Your flows are not competing for CPU with a home NAS or Plex transcoder. Dedicated vCPU allocation means consistent response times for time-sensitive automations.
• Edge-to-cloud integration — Edge devices on your LAN publish to a VPS-hosted MQTT broker over TLS; your Node-RED instance subscribes, transforms, and forwards to cloud services. Classic hub-and-spoke architecture without exposing your home network.
• Data ownership — Unlike SaaS automation platforms, every message, credential, and transformation lives on infrastructure you control. No vendor can deprecate a connector or raise per-execution pricing.
• No per-execution billing — Commercial workflow platforms charge per task, per run, or per active user. Node-RED on a flat-rate VPS runs unlimited flows with zero marginal cost.
• Full runtime access — You can ssh in, install any npm package, write custom function nodes, hook into the filesystem, run cron jobs alongside Node-RED, and expose flows on any port.

Cost Comparison: Self-Hosted Node-RED vs. Hosted Automation

Prerequisites

Before you begin, confirm you have:

• A VPS running Ubuntu 24.04 LTS with root or sudo access
• SSH access to the server
• A domain name pointed at your VPS (optional, but required for HTTPS)
• At least 1 vCPU and 1 GB RAM (2 vCPU / 2 GB recommended for production)
• Inbound ports 22 (SSH), 80 (HTTP), and 443 (HTTPS) open in your firewall

Recommended Plan: CloudCore Starter

The CloudCore Starter plan is the ideal entry point for Node-RED:

- 2 vCPU cores

- 2 GB RAM

- 40 GB NVMe SSD

- 32 TB traffic included

- EUR 7.99/month

This is more than enough for typical IoT flows, webhook receivers, dashboard UIs, and MQTT bridges.

Connect to your server:

ssh root@your-server-ip

We will create a dedicated non-root user for Node-RED later in Step 5.

Step 1: Update System Packages

Refresh the package index and apply pending upgrades before installing new software:

sudo apt update && sudo apt upgrade -y

Install a few utilities you will need later:

sudo apt install -y curl git build-essential ufw

If a new kernel was installed, reboot:

sudo reboot

Reconnect via SSH after a minute.

Step 2: Install Node.js 20 LTS

Node-RED requires Node.js. The official Node-RED documentation recommends the current LTS — at the time of writing that is Node.js 20 LTS. The version shipped in Ubuntu 24.04's default repositories is older than Node-RED's minimum requirement, so add NodeSource's official repository:

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

Verify both Node.js and npm are installed:

node --version
npm --version

Expected output:

v20.18.0
10.8.2

If node --version reports 20.x or higher and npm --version reports 10.x or higher, you are ready to install Node-RED.

Step 3: Install Node-RED Globally

Install Node-RED from npm with the --unsafe-perm flag, which is required because some native dependencies (serialport, bcrypt) compile during install and need root-level access to write to /usr/lib/node_modules:

sudo npm install -g --unsafe-perm node-red

Expected output (abbreviated):

added 332 packages in 1m
npm notice
npm notice New major version of npm available! 10.8.2 -> 11.0.0
npm notice

Verify the installation:

node-red --version

Expected output:

Node-RED v4.0.5
Node.js  v20.18.0
Linux    6.8.0-45-generic x64 LE

Step 4: First Launch and Directory Layout

Do a one-off manual launch to generate the default ~/.node-red directory and settings file:

node-red

Expected output (abbreviated):

Welcome to Node-RED
===================
16 Apr 10:00:00 - [info] Node-RED version: v4.0.5
16 Apr 10:00:00 - [info] Node.js  version: v20.18.0
16 Apr 10:00:00 - [info] Linux 6.8.0-45-generic x64 LE
16 Apr 10:00:00 - [info] Loading palette nodes
16 Apr 10:00:01 - [info] Settings file  : /root/.node-red/settings.js
16 Apr 10:00:01 - [info] HTTP Static    : /root/.node-red/public
16 Apr 10:00:01 - [info] Context store  : 'default' [module=memory]
16 Apr 10:00:01 - [info] User directory : /root/.node-red
16 Apr 10:00:01 - [info] Projects directory: /root/.node-red/projects
16 Apr 10:00:01 - [info] Server now running at http://127.0.0.1:1880/
16 Apr 10:00:01 - [warn] Encrypted credentials not found
16 Apr 10:00:01 - [info] Starting flows
16 Apr 10:00:01 - [info] Started flows

Node-RED is now listening on port 1880. Stop it with Ctrl+C — we will set it up properly as a service next.

The user directory (~/.node-red) contains:

• settings.js — the main configuration file
• flows.json — your deployed flows (created on first deploy)
• flows_cred.json — encrypted credentials (created on first deploy)
• package.json — installed palette nodes
• node_modules/ — palette node dependencies
• projects/ — optional Git-backed project directories

Step 5: Run Node-RED as a systemd Service

Running Node-RED as root is never appropriate for production. Create a dedicated system user and wire up a proper systemd unit so the service survives reboots.

Create a nodered user with a home directory:

sudo useradd --system --create-home --shell /bin/bash nodered

Copy the existing user directory if you generated one under root, or let the service initialise a fresh one:

sudo mkdir -p /home/nodered/.node-red
sudo chown -R nodered:nodered /home/nodered

Create the systemd unit file:

sudo tee /etc/systemd/system/nodered.service > /dev/null <<'EOF'
[Unit]
Description=Node-RED
After=network.target
[Service]
Type=simple
User=nodered
Group=nodered
WorkingDirectory=/home/nodered
Environment="NODE_OPTIONS=--max-old-space-size=512"
Environment="NODE_RED_OPTIONS=-v"
ExecStart=/usr/bin/node-red --userDir /home/nodered/.node-red $NODE_RED_OPTIONS
Restart=on-failure
KillSignal=SIGINT
SyslogIdentifier=Node-RED
StandardOutput=journal
StandardError=journal
[Install]
WantedBy=multi-user.target
EOF

Explanation of key options:

• User=nodered — runs Node-RED as a non-privileged user, not root.
• NODE_OPTIONS=--max-old-space-size=512 — caps Node.js heap at 512 MB, preventing runaway flows from consuming all system RAM on a 1 GB plan. Bump to 1024 or 2048 on larger VPS plans.
• --userDir /home/nodered/.node-red — explicitly points Node-RED at its config directory.
• Restart=on-failure — systemd restarts Node-RED if it crashes (but not if you manually stop it).
• KillSignal=SIGINT — Node-RED handles SIGINT cleanly, flushing flows before exit.

sudo systemctl daemon-reload
sudo systemctl enable nodered
sudo systemctl start nodered

Check the status:

sudo systemctl status nodered

Expected output:

● nodered.service - Node-RED
     Loaded: loaded (/etc/systemd/system/nodered.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-04-16 10:05:00 UTC; 5s ago
   Main PID: 2345 (node-red)
      Tasks: 11 (limit: 2256)
     Memory: 94.2M
        CPU: 2.133s
     CGroup: /system.slice/nodered.service
             └─2345 node-red --userDir /home/nodered/.node-red -v

Tail the logs to confirm it is running:

sudo journalctl -u nodered -f

Press Ctrl+C to stop tailing.

Step 6: Secure settings.js with adminAuth and credentialSecret

By default, Node-RED is wide open on port 1880 with no authentication. Anyone who can reach the server can edit flows, read credentials, and execute arbitrary code. Before exposing it to the internet, configure authentication.

First, generate a bcrypt hash of the admin password you want to use. The node-red admin hash-pw command prompts for a password and prints the hash:

sudo -u nodered node-red admin hash-pw

You will see:

Password:

Type your chosen password and press Enter. The output is a bcrypt hash like:

$2b$08$abcdefghijklmnopqrstuv.wxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234

Copy this hash — you will paste it into settings.js. Now open the settings file:

sudo -u nodered nano /home/nodered/.node-red/settings.js

Find the commented-out adminAuth section and replace it with:

adminAuth: {
    type: "credentials",
    users: [
        {
            username: "admin",
            password: "$2b$08$abcdefghijklmnopqrstuv.wxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234",
            permissions: "*"
        }
    ]
},

Paste your actual hash in the password field. The permissions: "*" grants full access; you can create read-only users later with permissions: "read".

Next, find (or add) the credentialSecret key. This is a fixed string Node-RED uses to encrypt the flows_cred.json file. If you leave it auto-generated, a new random key is created every time the file is deleted, which breaks credential recovery across backups:

credentialSecret: "replace-this-with-a-long-random-string-64-chars-or-more",

Generate a strong random secret:

openssl rand -hex 32

Paste the result into credentialSecret. Treat this value the same way you treat a database password — anyone with it can decrypt every credential stored in your flows.

While you are in settings.js, move the editor to a non-default path with httpAdminRoot. This reduces noise from bots scanning for /red and /admin:

httpAdminRoot: "/flow-editor",
httpNodeRoot: "/api",

The editor is now at http://your-server:1880/flow-editor and flow-deployed HTTP endpoints live under /api/*.

You can also require HTTPS at the Node-RED layer itself (instead of or in addition to Nginx) by setting requireHttps: true and pointing https at certificate files. We use Nginx for TLS in the next step, so leave that commented out.

Save the file (Ctrl+O, Enter, Ctrl+X) and restart Node-RED:

sudo systemctl restart nodered

Open your browser to http://your-server-ip:1880/flow-editor — you should now see a login screen. Sign in with admin and the password you hashed.

Step 7: Enable HTTPS with an Nginx Reverse Proxy

Exposing plaintext HTTP over the internet is unacceptable for any service that handles credentials. Put Node-RED behind Nginx with a Let's Encrypt certificate.

Install Nginx and Certbot:

sudo apt install -y nginx certbot python3-certbot-nginx

Create the Nginx site configuration:

sudo tee /etc/nginx/sites-available/nodered > /dev/null <<'EOF'
server {
    listen 80;
    server_name nodered.yourdomain.com;
    return 301 https://$host$request_uri;
}
server {
    listen 443 ssl http2;
    server_name nodered.yourdomain.com;
    ssl_certificate     /etc/letsencrypt/live/nodered.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/nodered.yourdomain.com/privkey.pem;
    # Security headers
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "no-referrer-when-downgrade" always;
    client_max_body_size 50m;
    location / {
        proxy_pass http://127.0.0.1:1880;
        proxy_http_version 1.1;
        # WebSocket support (required by Node-RED editor)
        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;
        proxy_read_timeout 86400;
        proxy_send_timeout 86400;
    }
}
EOF

Replace nodered.yourdomain.com with your actual hostname, then enable the site:

sudo ln -s /etc/nginx/sites-available/nodered /etc/nginx/sites-enabled/
sudo rm -f /etc/nginx/sites-enabled/default

Before running Certbot, comment out the SSL-specific lines (Certbot will uncomment them after issuing the certificate). Alternatively, use Certbot's automatic Nginx plugin:

sudo certbot --nginx -d nodered.yourdomain.com

Certbot will request the certificate, edit the config file to point at the new certificate files, and reload Nginx. When it completes, test and reload:

sudo nginx -t && sudo systemctl reload nginx

Certbot auto-renewal runs via a built-in systemd timer — no additional cron configuration is needed. Verify it:

sudo systemctl list-timers | grep certbot

Lock down the firewall so Node-RED is only reachable via Nginx:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

Crucially, do not open port 1880 to the public. Node-RED listens on 127.0.0.1:1880 (by default), and only Nginx (same host) reaches it. If you previously set uiHost in settings.js, leave it as "127.0.0.1".

Open https://nodered.yourdomain.com/flow-editor — you now have an authenticated, TLS-encrypted Node-RED editor.

Step 8: Install Palette Nodes (Dashboard and MQTT)

The core Node-RED install ships with a minimal set of nodes: HTTP, function, inject, debug, file I/O, and a few core utilities. Install useful community palettes for IoT and UI work.

Install via the Palette Manager (GUI)

Install via npm (CLI)

The CLI method is faster when you know which packages you want and is scriptable for reproducible deploys. Install palette nodes as the nodered user from the user directory:

sudo -u nodered bash -c 'cd /home/nodered/.node-red && npm install node-red-dashboard'

The official MQTT nodes (mqtt in, mqtt out) are built into Node-RED core, so no install is required — but many users also add the advanced broker helpers:

sudo -u nodered bash -c 'cd /home/nodered/.node-red && npm install node-red-contrib-aedes'

node-red-contrib-aedes embeds a lightweight MQTT broker inside Node-RED, which is handy for development and small deployments where you do not want to run a separate Mosquitto instance. For production, run a dedicated broker — see our Mosquitto install guide.

Other palettes worth installing for typical automation workloads:

• node-red-contrib-influxdb — write time-series data to InfluxDB
• node-red-contrib-home-assistant-websocket — bidirectional Home Assistant integration
• node-red-node-email — send and receive email via SMTP/IMAP
• node-red-contrib-telegrambot — send messages via Telegram
• node-red-contrib-cron-plus — advanced cron scheduling with per-node timezones

sudo systemctl restart nodered

Step 9: Build Your First Flow (HTTP in -> Function -> MQTT out)

Let's verify everything works end to end with a classic IoT-flavored flow: accept an HTTP POST, transform the payload in JavaScript, then publish to MQTT.

Prerequisites

You need an MQTT broker to publish to. The fastest option for this walkthrough is the public test.mosquitto.org broker. For production, set up your own — see How to Install Mosquitto MQTT on Ubuntu.

Build the flow

const body = msg.payload || {};
   msg.payload = {
       deviceId: body.deviceId || "unknown",
       temperature: Number(body.temperature) || 0,
       humidity: Number(body.humidity) || 0,
       ts: Date.now()
   };
   msg.topic = sensors/${msg.payload.deviceId}/readings;
   return msg;

Click Done.

Test the flow

From any terminal on the public internet:

curl -X POST https://nodered.yourdomain.com/api/sensor \
  -H "Content-Type: application/json" \
  -d '{"deviceId":"kitchen-01","temperature":22.5,"humidity":48}'

You should see OK returned. In the Node-RED debug sidebar (right panel), a message appears showing the transformed payload. The message is simultaneously published to sensors/kitchen-01/readings on test.mosquitto.org.

Subscribe from another terminal to confirm:

sudo apt install -y mosquitto-clients
mosquitto_sub -h test.mosquitto.org -t 'sensors/#' -v

Every POST to /api/sensor now fires a matching MQTT publish. You have just built a production-shaped IoT ingest pipeline in about two minutes of clicking.

Step 10: Enable Projects for Git-Backed Version Control

Node-RED's Projects feature stores flows as structured files inside a Git repository, giving you diffs, branching, merges, and remote push/pull — instead of one monolithic flows.json.

Open settings.js:

sudo -u nodered nano /home/nodered/.node-red/settings.js

Find the editorTheme.projects section and set enabled: true:

editorTheme: {
    projects: {
        enabled: true,
        workflow: {
            mode: "manual"
        }
    }
},

Restart Node-RED:

sudo systemctl restart nodered

Reload the editor. You will be prompted to create your first project. Provide a name, Git identity (email, name), and optionally add a remote ([email protected]:yourorg/nodered-flows.git). After setup, the editor shows a sidebar with Git history, uncommitted changes, and branches. Every deploy is a commit — or stage changes and commit in batches for coherent history.

With Projects enabled, the user directory now contains a projects/<name>/ subdirectory with flows.json, package.json, and Git metadata. You can cd into it and use standard Git commands directly.

Step 11: Back Up ~/.node-red

Your Node-RED instance is portable. The entire state — flows, credentials, palette nodes, settings, projects — lives in ~/.node-red. Backing up this directory is all you need for disaster recovery.

Manual backup

Create a tarball of the user directory:

sudo tar -czf /root/nodered-backup-$(date +%F).tar.gz \
  -C /home/nodered .node-red

Copy it off-server:

scp /root/nodered-backup-$(date +%F).tar.gz backup-host:/backups/

Automated daily backup with cron

Create a backup script:

sudo tee /usr/local/bin/backup-nodered.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
BACKUP_DIR="/var/backups/nodered"
TIMESTAMP=$(date +%F-%H%M)
DEST="${BACKUP_DIR}/nodered-${TIMESTAMP}.tar.gz"
mkdir -p "$BACKUP_DIR"
tar -czf "$DEST" -C /home/nodered .node-red
Keep only the last 14 backups
ls -1t "$BACKUP_DIR"/nodered-*.tar.gz | tail -n +15 | xargs -r rm -f
echo "Backup complete: $DEST"
EOF
sudo chmod +x /usr/local/bin/backup-nodered.sh

Schedule a daily 2 AM run via cron:

echo "0 2   * root /usr/local/bin/backup-nodered.sh >> /var/log/nodered-backup.log 2>&1" | sudo tee /etc/cron.d/nodered-backup

For off-site backups, combine with Restic or Rclone to push snapshots to S3-compatible object storage.

Critical: back up credentialSecret separately

The flows_cred.json file is encrypted with the credentialSecret in settings.js. If you restore flows_cred.json without also restoring the matching credentialSecret, every credential (MQTT passwords, API keys, OAuth tokens) becomes unreadable. Our backup script above captures the whole .node-red directory including settings.js, so this is handled — just make sure that is preserved.

Troubleshooting

Viewing logs

Live-tail Node-RED logs:

sudo journalctl -u nodered -f

Last 100 lines:

sudo journalctl -u nodered -n 100 --no-pager

Increase verbosity by editing the systemd unit: change NODE_RED_OPTIONS=-v to NODE_RED_OPTIONS="-v --trace-warnings" for detailed diagnostics during development.

FAQ

What are the minimum VPS specs to run Node-RED?

Node-RED runs comfortably on 1 vCPU and 1 GB of RAM for small to medium flows (dozens of nodes, hundreds of messages per minute). For production IoT gateways with hundreds of messages per second, several palettes loaded, and a dashboard UI, 2 vCPU and 4 GB RAM is a safer baseline. Heavy flows with embedded databases or image processing benefit from 4 GB+. The CloudCore Starter plan at 2 vCPU / 2 GB is the ideal entry point for most users.

Is Node-RED free and open source?

Yes. Node-RED is released under the Apache 2.0 license. It was originally developed inside IBM Emerging Technology by Nick O'Leary and Dave Conway-Jones in 2013, open-sourced in 2016, and moved under the OpenJS Foundation in 2019. The core runtime, editor, and official palette nodes are all open source. A vibrant ecosystem of 4,500+ community nodes extends it further.

How do I secure the Node-RED editor?

Four layers, all covered above:

For higher-security environments, add per-user accounts with granular permissions, integrate with OAuth or LDAP via community strategies, and run the editor behind a VPN like WireGuard or Tailscale so it is unreachable from the public internet at all.

Can Node-RED replace n8n or Home Assistant?

They overlap but serve different centers of gravity.

n8n is closer to a Zapier/Make competitor — workflow automation for SaaS integrations with a strong library of API connectors and a richer enterprise feature set (SSO, audit logs, RBAC). Node-RED's strengths are low-latency IoT, MQTT, hardware I/O, and building dashboard UIs. If your workload is mostly SaaS-to-SaaS, n8n is often easier; if it is device-to-cloud or involves MQTT, Node-RED is the stronger tool. Many teams run both.

Home Assistant is a dedicated smart-home platform with device discovery, a polished mobile app, and hundreds of vendor integrations. Node-RED is more general-purpose. A common pattern is running Home Assistant as the device integration layer and Node-RED as the automation engine that subscribes to HA's MQTT bus and implements complex multi-step automations that exceed HA's native YAML automation capabilities.

How do I back up Node-RED flows?

Back up the entire ~/.node-red directory — it contains flows.json, flows_cred.json, settings.js, package.json, and all palette node dependencies. Our Step 11 script does this on a daily schedule with 14-day retention. Critically, the credentialSecret in settings.js must be preserved alongside flows_cred.json for credentials to decrypt on restore.

For even stronger versioning, enable Projects (Step 10) — every deploy becomes a Git commit, giving you atomic, diff-able, revertible flow history. Push to a private GitHub/Gitea repository for off-site redundancy.

Next Steps

Now that Node-RED is running on a hardened VPS, here are natural follow-ups to extend your stack:

• Install Mosquitto MQTT — run your own dedicated MQTT broker alongside Node-RED instead of relying on public brokers. Essential for production IoT.

• Install Home Assistant — pair Node-RED with Home Assistant to orchestrate smart-home devices. Use HA for device integration and Node-RED for complex automations.

• Install n8n — add n8n to your stack for SaaS-oriented workflow automation. The two tools complement each other: n8n for SaaS-to-SaaS, Node-RED for IoT and hardware.

• Install InfluxDB and Grafana — persist sensor time-series data to InfluxDB via Node-RED's InfluxDB nodes, then visualize trends in Grafana dashboards.

• Install Uptime Kuma — monitor the Node-RED service itself. Alert on HTTP failures, high latency, or service restarts.

• Explore the official documentation — the Node-RED docs cover advanced topics like custom node development, context stores with Redis, multi-user editor sessions, and runtime API endpoints.

• Browse the community catalog — the flows library has over 4,500 reusable subflows and nodes. Search for your device, protocol, or SaaS tool before writing anything from scratch.

Launch a Production-Ready VPS in 60 Seconds

Our CloudCore plans give you everything Node-RED needs — fast NVMe storage, KVM virtualization, full root access, and 32 TB of traffic — on Ubuntu 24.04 LTS with one-click deploy.

- 2 vCPU, 2 GB RAM, 40 GB NVMe SSD

- Root access and 24/7 infrastructure monitoring

- Daily automated snapshots available

- EUR 7.99/month on the CloudCore Starter plan

Deploy Your Node-RED VPS Now — unlimited flows, unlimited executions, one flat monthly price.