If you've ever wanted to trigger something the moment another thing happens — turn on a light when a sensor trips, post to a webhook when a file lands in a folder, poll an API every five minutes and email yourself the results — you've basically described Node-RED. It's one of those tools that homelab folks discover once and then can't stop reaching for.
This guide walks you through installing Node-RED in its own LXC container on Proxmox VE, using the community-maintained helper script that most of the homelab world already relies on. You'll end up with a working Node-RED editor open in your browser inside about ten minutes, running in a container light enough that you'll barely notice it's there.
What You Will Learn
- What Node-RED actually is and what problems it solves
- Why running it in its own LXC container makes sense on Proxmox VE
- How to install it using the community-scripts helper script
- How to open the editor, set a login password, and add extra nodes
- How to manage the service, update the app, and fix the errors people actually run into
What Is This Feature?
Node-RED is a browser-based tool for wiring together small pieces of logic without writing a full application. You drag blocks called nodes onto a canvas, connect them with lines called wires, and each node does one small job: read a value, wait for a timer, call an API, send an email, publish an MQTT message. String enough of them together and you have a working automation, called a flow. It started as an IBM research project back in 2013 and is now maintained under the OpenJS Foundation. It runs on Node.js, and the whole thing is just a web app — you access it through a browser, and it keeps running on the server whether or not anyone's looking at it.
An LXC container, if you haven't used one before, is a lightweight form of virtualization that shares the host's Linux kernel instead of running its own. That makes it start in about two seconds and use a fraction of the RAM a full VM would need for the same job. Since Node-RED is just a Node.js process with no real hardware requirements, an LXC container is the natural fit — you don't need to hand it a virtual CPU, virtual BIOS, and a full guest OS just to run one npm package.
Why Would You Use It?
The honest answer is: because writing a full Python or Node.js script for every small automation gets old fast. Node-RED gives you a visual layer over the same building blocks — HTTP requests, timers, conditionals, MQTT — so you can see the logic instead of reading it line by line. That matters more than it sounds like when you're debugging a flow at midnight and just need to see where the data stopped flowing. It's also genuinely good glue software. A lot of homelab tools speak MQTT, webhooks, or REST, and Node-RED can sit in the middle translating between things that were never designed to talk to each other.
People commonly use it for:
- Home automation logic, often paired with Home Assistant
- Reacting to MQTT messages from sensors, smart plugs, or Zigbee/Z-Wave hubs
- Polling APIs on a schedule and forwarding the results somewhere else
- Building small internal dashboards without a front-end framework
- Prototyping integrations before committing to "real" code
Should you run it in a dedicated LXC container instead of just installing it directly on your desktop? If you want it running around the clock, yes. Nobody wants their porch light automation to stop working because they closed their laptop.
Prerequisites
Before you start, make sure you have:
- A Proxmox VE host on version 8.x or 9.x, with at least one storage location that can hold container templates and disks
- Root (or sufficient) access to the Proxmox VE shell — either directly on the console or over SSH
- An internet connection on the Proxmox host, since the install script downloads a container template and packages from the internet
- About 4 GB of free storage and 1 GB of free RAM to spare for the new container
- Basic comfort typing commands into a terminal — you won't need to write any code
You don't need Docker for this. The script installs Node-RED directly with npm and runs it as a systemd service, so there's one less layer to think about.
Step-by-Step Tutorial
Step 1: Open the Proxmox VE shell
Log in to the Proxmox VE web interface, click your node's name in the left-hand tree, and open >_ Shell from the top-right toolbar. This gives you a root terminal on the host itself — not inside any VM or container. You could also SSH in directly if you'd rather use your own terminal.
Step 2: Run the Node-RED install script
Paste this command into the shell and press Enter:
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/node-red.sh)"This pulls a script maintained by the community-scripts project (the spiritual successor to tteck's original Proxmox helper scripts) and runs it. It builds a fresh LXC container and installs Node-RED inside it, hands-off.
Step 3: Choose Default or Advanced settings
The script asks whether you want Default Settings or Advanced Settings. For a first install, Default is fine. It creates an unprivileged Debian 13 container with 1 CPU core, 1024 MB of RAM, and a 4 GB disk, on the DHCP-assigned network you already have configured on your Proxmox bridge. If you go Advanced instead, you can set your own container ID, hostname, static IP, and resource allocation up front. Neither path is wrong — Advanced just saves you from editing the container's settings afterward.
Step 4: Wait for the build to finish
The script downloads the Debian 13 template if you don't already have it cached, creates the container, installs Node.js 22, then installs Node-RED globally with npm. On a decent connection this takes somewhere between three and six minutes. You'll see a series of green "installed" checkmarks scroll by — that's normal, not an error log.
When it's done, it prints a summary block with the container's IP address. Write that down, or just glance at it in the Proxmox web UI under the new container's Summary tab afterward.
Step 5: Open the Node-RED editor
In your browser, go to:
http://<container-ip>:1880You should land straight in the Node-RED flow editor — a blank canvas with a palette of nodes down the left side. There's no login prompt yet, which brings up the next step.
Step 6: Set a login password
Right out of the box, anyone who can reach that IP and port can open your editor and see (and change) every flow you build, including any credentials stored in them. That's fine on an isolated home network you trust, but you should still lock it down before you build anything sensitive. Inside the container's shell (use pct enter <CTID> from the Proxmox host, or SSH into the container directly), generate a password hash:
node-red admin hash-pwType your chosen password when prompted. It prints a bcrypt hash starting with $2b$ or $2a$ — copy the whole thing. Then edit the settings file:
nano /root/.node-red/settings.jsFind the commented-out adminAuth block, uncomment it, and fill in a username and the hash you just generated:
adminAuth: {
type: "credentials",
users: [{
username: "admin",
password: "$2b$08$yourhashhere",
permissions: "*"
}]
},Save the file, then restart the service so the change takes effect:
node-red-restartReload the page in your browser and you should get a login screen this time.
Step 7: Install a few extra nodes
The default palette covers HTTP, MQTT, timers, and basic logic, but most people end up adding a couple of extras. From the top-right hamburger menu, choose Manage palette, click the Install tab, and search for a package by name — for example, node-red-contrib-home-assistant-websocket if you're planning to talk to Home Assistant. Click Install next to the one you want, and it appears in your node palette within a few seconds, no restart required.
I'd resist the urge to install a dozen node packages on day one, though. It's easy to end up with a cluttered palette full of things you tried once and forgot about.
Commands Explained
| Command | What it does |
|---|---|
bash -c "$(curl -fsSL .../ct/node-red.sh)" | Downloads and runs the community-scripts installer, which builds the LXC container and installs Node-RED inside it |
pct enter <CTID> | Opens a root shell inside the container, run from the Proxmox host — no SSH needed |
node-red admin hash-pw | Prompts for a password and prints a bcrypt hash you can paste into settings.js |
node-red-start / node-red-stop / node-red-restart | Convenience wrappers the install script creates around systemctl, so you don't have to remember the service name |
node-red-log | Tails the last 100 lines of the Node-RED service log and follows new output — shorthand for journalctl -f -n 100 -u nodered -o cat |
systemctl status nodered | Shows whether the Node-RED systemd service is running and its recent log lines |
Common Errors
Browser can't reach the editor at all. Nine times out of ten this is a firewall or a typo in the IP, not Node-RED itself. Confirm the container is running from the Proxmox web UI, double-check the IP under its Summary tab, and make sure nothing on your network is blocking port 1880.
"This site can't be reached" right after the install finishes. Give it another 20–30 seconds. The script enables the systemd service at the very end of the install, and on a busy host it can take a moment for Node-RED to finish its first boot and start listening.
Flows disappear or reset after a restart. This almost always means someone edited /root/.node-red/settings.js and introduced a syntax error, so Node-RED silently fell back to defaults on the next start. Check node-red-log for a JavaScript parse error near the top of the output.
"Unauthorized" after adding adminAuth. Usually the hash got truncated when it was copied into settings.js — bcrypt hashes are long, and it's easy to miss the trailing characters. Regenerate it with node-red admin hash-pw and paste carefully, ideally without going through a text editor with auto-formatting turned on.
Troubleshooting
If the editor loads but a flow won't deploy, click the debug tab (the bug icon on the right sidebar) before doing anything else — it usually tells you exactly which node threw the error. Most deploy failures trace back to a missing node type, which happens when you import a flow that uses a palette package you haven't installed yet.
For anything deeper, node-red-log is your first stop. It streams the same output you'd see running Node-RED manually in a terminal, including stack traces from crashed nodes.
If the whole service won't start, run systemctl status nodered and look at the last few lines. A common cause on low-memory containers is Node-RED hitting the --max-old-space-size=128 limit set in the systemd unit file — if you're running memory-heavy flows, bump your container's RAM allocation in the Proxmox UI first before touching that flag.
Best Practices
- Set adminAuth before you build anything with real credentials in it — API keys and tokens sit in your flow JSON in plain text otherwise.
- Export your flows regularly (hamburger menu → Export → all flows to clipboard or file) and keep a copy outside the container. A snapshot of the whole LXC container works too, but a flow export is faster to restore from if you only broke one thing.
- Give the container a static IP through Proxmox or a DHCP reservation on your router. Editor bookmarks and any other service calling into Node-RED will break if the IP drifts.
- Don't expose port 1880 directly to the internet. If you need remote access, put it behind a reverse proxy with its own authentication, or reach it over a VPN.
- Re-run the install script whenever you want to update — it detects the existing container and offers an update path instead of building a second one.
Frequently Asked Questions
Do I need Docker to run Node-RED on Proxmox?
No. The community-scripts installer runs Node-RED directly on Debian with npm and manages it as a systemd service. Docker is a separate, equally valid route if you already run a Docker host, but it's not required here.
How much RAM does Node-RED actually need?
The default 1024 MB is enough for a modest set of flows. If you're processing large payloads, running dozens of flows, or working with image or video data, bump it to 2 GB in the container's Hardware settings.
Can I run Node-RED and Home Assistant in the same container?
Technically yes, but I wouldn't. Keeping them in separate LXC containers means you can update, restart, or reinstall one without touching the other, and a crash in one doesn't take the other down with it.
Will updating Node-RED break my existing flows?
Rarely, and mostly with major version jumps. Export your flows before a big update anyway — it takes ten seconds and saves you from the one time it does matter.
Is Node-RED only for home automation?
No, that's just its most visible use case. It's a general-purpose flow tool — plenty of people run it purely for API integrations, scheduled jobs, or internal dashboards with no smart home devices involved at all.
Conclusion
You now have a working Node-RED instance, sitting in its own lightweight container, doing nothing until you tell it to. That's exactly where you want to be — the fun part is building your first real flow next: a timer that hits an API, a webhook that logs to a file, an MQTT message that flips something in your house. Start small, watch the debug panel while you build, and you'll have a feel for it within an afternoon.