RedBot: building chat bots for five platforms inside Node-RED

Chat platforms exposed as nodes in a flow editor

Node-RED is a tool for wiring together hardware devices, APIs and online services, and RedBot uses that idea literally. The package adds nodes for Telegram, Facebook Messenger, WhatsApp, Viber and Slack, and the promise in the description is a full featured chat bot with almost no coding skills required. What that means in practice is that the platform protocol work is done for you. A bot becomes a flow: a receiver node for the platform, one or more nodes that decide what to answer, and a sender node for the same platform. The chat platform problems that normally eat the time, verifying webhooks, decoding message payloads, handling the platform's own quirks, are handled inside the nodes. The audience is a person with a Node-RED instance and a need for a bot, rather than a developer writing a bot service. The package is published on npm as node-red-contrib-chatbot, the project site is red-bot.io, and the licence is MIT with the copyright held by Guidone.

From empty Node-RED to a bot in three commands

The requirements are Node.js 18 or newer and Node-RED 2.0 or newer, and the install is the standard Node-RED one followed by the package inside your user data directory:

sudo npm install -g node-red

cd ~/.node-red
npm install node-red-contrib-chatbot

Then start Node-RED:

node-red

That last step matters for how the package is found. Node-RED looks for contributed nodes in the user data directory, which is why the second command runs from ~/.node-red rather than from a project folder, and it is also why the Docker setup later mounts specific directories into the container at those exact paths. The install writes into the directory Node-RED is already reading, and restarting the editor is what makes the new nodes appear.

Telegram first, because polling avoids the certificate problem

The readme recommends starting with Telegram and explains why in one line: Telegram allows polling to receive messages, so it is not necessary to create an https certificate. That removes the single most common reason a first bot fails. The setup then is: create a chat bot with @BotFather, follow its instructions, and copy the access token. In the Node-RED editor, add a Telegram Receiver node, open its configuration panel, add a bot and paste the token. Next add a Message node and connect it to the receiver. Finally add a Telegram Sender node, and in its configuration panel select the same bot you configured in the receiver, which is the step people miss. With those three nodes in place the bot answers Hi there! to any message it receives. The two-node pairing is the pattern for every platform RedBot supports, with the platform specific details moving into the node configuration, so the flow you build once transfers to another platform with a different receiver and sender.

The Docker path and the assets sidecar

There is a container image as well as the npm route. The Dockerfile is short and starts from the official Node-RED image:

npm install node-red-contrib-chatbot@latest --unsafe-perm --no-update-notifier --no-fund --only=production --omit=dev

The compose file defines a redbot service from the guidone/redbot image, publishing port 1880 and passing a set of environment variables that turn on mission control, enable or disable Node-RED projects and tours, set the development mode and the environment name, and enable the one time password. It then bind mounts the working directories for nodes, lib, bin, migrations, database and src into the container at the paths under node_modules/node-red-contrib-chatbot, plus a data volume for the persistent state. A second service, redbot-assets, builds from Dockerfile-webpack and serves the front end assets on port 8080, which is what the webpack build produces. The build-docker script in the package file targets linux/amd64 and linux/arm64, so the same image runs on a Pi and on a server.

Where the state lives: a database, migrations and mission control

RedBot keeps more than the flow definition. The repository has a database directory, a migrations directory, and a mission-control.sqlite file, and the environment variable REDBOT_ENABLE_MISSION_CONTROL switches that feature on. A bot platform needs somewhere to record the conversation context, the identifiers of the chats it knows about, and the state of any flow that has to survive a restart, and the presence of a database and a migrations folder says plainly where that lives. The migrations folder is the part to look at before an upgrade, because a schema change without the matching migration is how an upgrade breaks an existing deployment, and the release notes in the changelog are where those changes are recorded. The plugins directory and the src directory sit next to the nodes and lib directories, and the plugins area is where the extension mechanism lives, since the package also supports building plugins from the webpack configuration.

The documentation is generated from Notion, which has a cost

The documentation is unusual in a way worth flagging. The main RedBot documentation, the examples, the advanced examples and the chat context pages are all hosted in Notion, and the repository contains a script that imports from it, with a build-docs entry in the package scripts and a version-old entry that runs the same import and commits the generated files. The front end itself is built with webpack, and the repository carries the webpack configuration, a redbot.config.html and redbot.config.js, and a docker-compose sidecar that serves the built assets. The upside is that the documentation is written and updated in a tool most people can edit, and the downside is that the authoritative text is not in the repository, so a reader browsing the source on GitHub sees a pointer rather than the content, and the repository's own docs directory carries mainly the nodes index. For a project maintained by one person, the Notion workflow is a reasonable trade, but it is a dependency you should know about before you depend on the documentation.

One maintainer, irregular releases and a test suite

The readme says maintaining RedBot is very time-consuming and asks for donations, and the copyright line reads Copyright (c) 2026 Guidone, so this is a single person project with a personal support burden rather than a team. That shows in the release pattern. The tagged releases are 2.0.1 on 2026-06-03, 2.0.3 on 2026-06-29 and 2.0.4 on 2026-06-30, while the version in the package file has already moved to 2.0.5, so the published package and the repository are not always in step, which is normal but means you should check what you actually get after npm install. The last push was on 2026-09-30, and the 2.0 release is the current line, with the changelog linked from the readme. There is a jest test suite, an eslint configuration and a lint script, so the project does have the tooling of a maintained codebase. The credits note that the work was inspired by node-red-contrib-telegram and builds on the Telegram Bot API for NodeJS, which is worth knowing if you are comparing approaches to the same problem.

Editorial conclusion

RedBot is a good fit if you already run Node-RED and want a bot for one of the five supported platforms without writing the platform protocol by hand, and the Telegram path in particular gets you a working bot in minutes. It is the wrong choice if you need a bot with a server side web endpoint and no polling, if you want more than one maintainer behind the project, or if you cannot accept that the documentation lives in a separate tool rather than in the repository. Before you build on it, read the chat context documentation for how conversation state is kept, check the migration files before upgrading an existing deployment, and pin the version you tested because releases are irregular.

Frequently asked questions

Official sources

1. guidone/node-red-contrib-chatbot on GitHub
2. License: MIT
3. Project website
4. README
5. Releases