Node-RED Hosting on Its Own VPS

Node-RED is a low-code tool for wiring together APIs, devices and online services: you drag nodes onto a canvas in the browser, connect them into flows and deploy. It is an open-source (Apache 2.0) project of the OpenJS Foundation. Choose it with a plan, pay, and we build the VPS (KVM, NVMe, Ubuntu 24.04 LTS) and install Node-RED, currently 5.0.9, in about three minutes after boot. You get:

• An HTTPS address like yourname-x7k2.devoster.app with a Let's Encrypt certificate.
• An editor that is never open without a login. Node-RED's editor has no login unless one is configured; ours is configured before Node-RED first starts. You sign in as admin with a generated password shown in the Devoster dashboard, where you can also reset it.
• Installs that stick. Nodes you add from the palette manager, and npm modules you use in Function nodes, live in Node-RED's data directory and survive restarts and updates. Flow credentials are encrypted with a key generated on your server.
• Dashboard controls to open the editor, restart, stop or start it, read its logs, run an update and connect your own domain.

The app is free; you pay only the VPS plan, with 10% off yearly. The server comes with full root, free nightly backups kept 3 days plus one snapshot, a dedicated IPv4, 1 Gbps with unlimited bandwidth and DDoS protection. See the other apps that install this way on the One-Click Apps page.

A Raspberry Pi at home is the classic place for Node-RED. A VPS is the better place when the flows need to be reachable from the internet and stay up when your home connection doesn't:

• Glue between online services: poll an API on a schedule, transform the data in a Function node and push it to a spreadsheet, a database or a chat channel.
• Webhooks and small APIs: HTTP In nodes turn a flow into an endpoint on your HTTPS address, ready for Stripe, GitHub or a form service to call.
• MQTT and IoT backends: devices and gateways publish to an MQTT broker, and Node-RED subscribes, stores and reacts. Node-RED is the client here; a broker is not included (see the FAQ).
• Dashboards: dashboard nodes from the palette give you simple web UIs for the data your flows collect.

One thing a cloud server can't do is reach into your home network by itself. Devices behind your router need to connect out, to a broker or to Node-RED's endpoints, or you can link the two networks with a VPN such as our one-click WireGuard server.

Node-RED reads its configuration from settings.js. On this install that file is managed and replaced on updates, so your own settings go in settings.user.js next to it, in Node-RED's data directory (/data inside the container, /opt/devoster/data/node-red on the server). It is a normal Node.js module, module.exports = { ... }, merged over our defaults when Node-RED starts. Two settings stay managed: the editor login (adminAuth) and the credential encryption key (credentialSecret), so the dashboard's password reset always works.

Three defaults worth knowing, all changeable there:

• Projects are off. Node-RED's Projects feature, which keeps flows in a Git repository, is disabled by default. Git is available in the image, so you can switch it on.
• Context is kept in memory. Flow and global context values are lost when Node-RED restarts or updates. Configure a file-based context store if you rely on them.
• There is one editor account. The managed login has a single user, admin, with full rights.

Restart Node-RED from the dashboard after you change settings.user.js. If the file has a syntax error, Node-RED ignores it and starts with the defaults rather than failing, and says so in its logs.

The editor login protects the editor and Node-RED's admin API. It does not protect the endpoints your flows create: an HTTP In node at /sensor answers anyone who calls https://your-address/sensor. That is by design, since webhooks have to be callable, but it means every endpoint is your responsibility:

• Set httpNodeAuth in settings.user.js to put a username and password on all HTTP In endpoints at once.
• Or check a secret token or a signature header at the start of each flow, which is how most webhook senders expect to be verified.
• Never expose a Function node that runs whatever it is sent.

Email: outbound mail ports are blocked by default on Devoster VPS plans, so SMTP email nodes won't connect. Use an external email provider (its SMTP submission port can be opened on request) or a node that sends through an HTTPS API. Node-RED core has no password-reset email anyway; reset the editor password from the Devoster dashboard. Telegram, Slack, Discord and HTTP request nodes are unaffected.

Very little to start. Node-RED idles at around 80 MB of RAM. What grows its footprint is the palette (every installed node package loads at startup), the size of the messages you pass around, and anything you keep in memory, such as context or large arrays in Function nodes.

If you add your own services, such as a Mosquitto broker, note that only SSH, HTTP and HTTPS are open in the server's firewall; with root, opening another port is up to you. You can upgrade to a larger plan from the panel later.

We test new Node-RED versions and apply them in a maintenance hour you choose, or when you press Update now. A snapshot of the VPS is taken first, and if Node-RED doesn't come back healthy the server is rolled back automatically. The nodes you installed from the palette are yours, though: community nodes are not part of what we test, so before a major Node-RED version, check that the ones you rely on support it, and switch auto-update off until they do.

The server is unmanaged. You have full root, and its security, your flows and the endpoints they expose are your responsibility. We don't provide help building flows; Node-RED's documentation and forum cover that. Our VPS hardening checklist is a good first hour for any server with root access.

Nightly backups (3 days) and your snapshot slot cover the whole VPS. Export important flows from the editor, or switch on Projects and push them to a Git remote, so a copy lives off the server.