GataBot-MD: a self-hosted WhatsApp bot built on Baileys

A WhatsApp bot held as a session, not a personal account

GataBot-MD is a WhatsApp bot written in JavaScript for Node, and the mechanism that puts it in the message stream is worth understanding first. The dependency list names @whiskeysockets/baileys, pulled from a GitHub fork rather than the registry, and the setup documentation offers two ways to link a number. One is a QR code, exposed as the qr script in the package metadata, and the other is a pairing code that arrives as eight digits, configured in config.js and described in the README as linking the number directly to receive the code. Both are session mechanisms rather than a normal account login, which is the usual pattern for bots on WhatsApp. The consequence for an operator is that this is a service you host, on a machine that stays online, and the number it uses becomes a bot identity rather than a personal account.

Owners, user levels and a config file that runs the whole bot

The README organises the project around a single configuration file, config.js, and the table of settings points at specific line numbers in it, which is a sign that this file is the control surface of the project. The first entry is Owners, defined as who will have total control over the bot, then the ability to change the bot's name, the optional pairing-code connection, and the user level setting that adjusts difficulty so that users level up inside the bot. A fork button is offered so you can create your own version from this one, and a policy document, a contributors list and a set of issue templates for bugs, help requests and suggestions sit alongside. The fact that owners are configured in one place and levels are enforced by the bot is a design choice with consequences: adding an owner grants that number full control, so the file is a security boundary, not just a settings file.

Installing on Termux, with a scripted path and a manual path

The primary install path documented in the README is Termux on Android, and there are two routes. The manual one is a sequence of ordinary steps. You grant storage access, install the toolchain with apt and pkg, clone the repository, and then install the packages:

apt update && apt upgrade && pkg install -y git nodejs ffmpeg imagemagick yarn

git clone https://github.com/GataNina-Li/GataBot-MD && cd GataBot-MD

The automatic route pipes a shell script straight into bash:

apt update -y && yes | apt upgrade && pkg install -y bash wget mpv && wget -O - https://raw.githubusercontent.com/GataNina-Li/GataBot-MD/master/gata.sh | bash

Note the difference in style. The automatic path fetches a script over the network and executes it with root privileges on a phone, and it installs bash, wget and mpv along the way. If you fork the project, the README documents exactly which lines of gata.sh to edit so the install pulls your own fork, and gives the two line numbers, 205 and 209, that hold the git clone and the cd into the repository. The project also states it does not guarantee perfect behaviour in Termux, and asks for reports with evidence if you hit slowness or errors.

A plugin directory and a dependency list that shows the feature set

The functionality lives in the plugins directory, and the dependencies in the package metadata give a fair picture of what the bot actually does. There is a scraper package, a lyrics finder, music track data, a translate API client, acrcloud for music recognition, a phone number library in two flavours, an apt toide scraper, a file type detector, fluent-ffmpeg, cheerio and jsdom for web parsing, axios, p-queue for job ordering, lowdb and nedb for local storage, and moment-timezone with a countries and timezones table. Several dependencies are pointed at forks rather than the registry, including baileys and a module named module-gatadios, which is worth knowing when you audit the tree. The media directories in the repository, audio and media, pair with the ffmpeg and ImageMagick packages the install steps pull in, and the Dockerfile installs the same set of system libraries, so the media pipeline is a first-class part of the bot rather than an add-on.

Deployment beyond the phone: Docker, Render, Koyeb and Replit

The repository carries configuration for several hosting platforms, which tells you the project expects to run on a server as often as on a phone. The Dockerfile is minimal and worth reading as a specification of the runtime. It starts from node:lts-buster, installs ffmpeg, imagemagick and webp with apt, copies package.json, runs npm install along with an extra install of qrcode-terminal, copies the rest of the tree, exposes port 5000 and starts node index.js. The presence of a Procfile, a render.yaml, a koyeb.js, an app.json and a replit.nix means each of those platforms gets a configuration file, and the scripts server.sh, start.sh, shell.sh, update.sh and install2.sh show the range of environments the maintainer supports, from a server to a hosted container to a phone shell. The scripts section of the package metadata is small: start runs node index.js, qr runs node index.js qr for the QR login, code runs node index.js code for the pairing code, and test runs node test.js.

Licensing, versions and the gap between the tag and the tree

The licence situation needs reading twice. The repository metadata reports a custom licence that GitHub cannot classify, and the README points to the LICENSE file, while the package metadata states GPL-3.0-or-later in its license field. That discrepancy is the kind of thing that has to be settled before the code is used commercially or redistributed, and the LICENSE file is the document that governs. On versions, the single tagged release is v1.7.0, published on 2023-11-05, and the package metadata version matches at 1.7.0, while the last push to the repository was on 2026-05-04. So the tree is being worked on, but the published version lags by years. The README opens with a note saying the project is in constant evolution and invites users to install and follow the announcements channel for news. Read together, the picture is a fast-moving personal project with an infrequent release tag, which is fine for a hobby deployment and uncomfortable for anything that needs a stable base to pin.

What it is not, and where a different tool fits better

Two things are worth saying plainly. First, this is a self-hosted bot on infrastructure you control, and the README routes people toward sponsored bot hosting services when Termux proves troublesome, which is an admission that running it reliably is work rather than a product. Second, the category has a boundary. A bot session like this is not the same as an official WhatsApp Business API integration: there is no SLA, no review process and no guaranteed delivery, and the numbers of the maintainer and the contributors are the people you can contact when it breaks, as the README shows with a Telegram support channel, a Gmail address and a PayPal link. If the requirement is a supported business messaging channel with predictable behaviour, an official integration or a hosted platform is the honest alternative, and the difference in approach is the difference between running a session on your own hardware and using a documented, metered API. For a personal or group automation tool, the bot fills a gap the official path does not.

Editorial conclusion

GataBot-MD fits an individual or small group who wants a WhatsApp bot on infrastructure they control, with a plugin system and a config file where owners and levels are defined in one place. It does not fit a business that needs a supported, audited service, and the licensing question has to be settled before any commercial use. Before deploying it, read the LICENSE file, because the package metadata claims GPL-3.0-or-later while the repository reports a custom licence, and note that the newest tagged release is v1.7.0 from 2023 while the last push was on 2026-05-04, so the gap between the tag and the working tree is where the real behaviour lives.

Frequently asked questions

Official sources

1. GataNina-Li/GataBot-MD on GitHub
2. Issues
3. Project website
4. README
5. Releases