Deploy and Host Node-RED on Railway

Node-RED is a low-code, browser-based editor for wiring together APIs, devices, and online services. Drag nodes onto a canvas, connect them into flows, and run event-driven automations and HTTP endpoints in minutes — no build step, no redeploy needed.

About Hosting Node-RED

Node-RED runs as a single lightweight Node.js container, so hosting it means one service and one persistent volume. This template deploys a thin wrapper over the official image pinned to 5.0.4, with a volume mounted at /data where your flows, encrypted credentials, settings, and any nodes installed through the Palette Manager live — everything survives restarts and redeploys. The app binds Railway's injected PORT automatically, and the flow editor is protected with a login the moment the URL goes live: a username and a random admin password are set for you, and the credential-encryption secret is fixed so your stored credentials keep decrypting across redeploys. Deploy, sign in, and start building flows.

Why This Template

A stock Node-RED container starts with no authentication — anyone who finds the URL can open the editor, rewrite your flows, and (because function nodes run JavaScript and the Palette Manager installs arbitrary npm packages) run code on the box. Most Node-RED listings on Railway expose exactly that, and several publish NODE_RED_USERNAME / NODE_RED_PASSWORD variables that the image never reads, so the deploy form looks secured while the instance is wide open.

This template closes it:

Admin login on by default. The wrapper injects an adminAuth block into settings.js at boot, hashing NODE_RED_PASSWORD with bcrypt. Anonymous GET /settings, POST /flows, and POST /nodes all return 401.
Refuses to boot without a password. An empty NODE_RED_PASSWORD or NODE_RED_CREDENTIAL_SECRET stops the container rather than silently starting open.
Password rotation by redeploy. settings.js lives outside the volume and re-hashes on every boot, so changing the variable and redeploying rotates the login.
Stored credentials survive redeploys. NODE_RED_CREDENTIAL_SECRET is set explicitly; without it Node-RED generates a new key each boot and every saved credential becomes undecryptable.

Common Use Cases

Glue APIs and SaaS tools together with visual flows instead of custom backend code
Build webhooks, schedulers, and HTTP endpoints for automations and integrations
IoT dashboards and device orchestration with MQTT and home-automation nodes

Dependencies for Node-RED Hosting

Persistent volume mounted at /data (flows, credentials, settings, installed palette nodes)
A Node-RED admin password (NODE_RED_PASSWORD) and credential secret (NODE_RED_CREDENTIAL_SECRET) — both generated for you by the template

Deployment Dependencies

Implementation Details

The wrapper image (ghcr.io/bon5co/node-red-railway:5.0.4) adds a boot-time settings.js that enables adminAuth, sets credentialSecret, and disables the projects feature. The volume is chowned to the node-red user before the server drops privileges with su-exec, so writes to the Railway-managed (uid 0) mount succeed. Extra nodes install at runtime from the Manage Palette menu and persist on the volume, no image rebuild needed.

Why Deploy Node-RED on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Node-RED on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.