whatsapp-bot is a TypeScript bot runtime built on Baileys multi-device

The connection layer is Baileys, not a platform API

This is a WhatsApp bot written in Node and TypeScript, and the README makes its foundation explicit: the project now uses Baileys Multi-Device, the `adiwajshing/Baileys` library. The stack badges add Prisma for the data layer, MongoDB for storage, and the repository description calls it a multi-device bot with internationalization.

What that means for an adopter is worth saying plainly. The bot does not talk to a hosted platform API that you register an account with. It opens a session from your own machine, and the README says that after running it you need to scan the QR code, which is how a phone or a session pairs with a WhatsApp account. Baileys is an unofficial client library, and the project says so by the fact that it points at the library's repository.

That choice buys a lot. Multi-device support means the session is not a single long-lived connection, the bot can be hosted on a small server or even a phone, and the surrounding stack is ordinary Node. The cost is that the connection is maintained by a community library rather than by a vendor, and the README's own licence note says the project had to move to GPL-3.0 because Baileys is available under that licence.

Cloning and installing take two commands

The README lists the requirements first, and there are only two. Node.js v16 or greater, and FFMPEG. The second requirement is easy to overlook and it exists for a reason: a bot that produces stickers and media needs to process media files, and FFMPEG is what does that.

The install sequence is the familiar one:

git clone https://github.com/ArugaZ/whatsapp-bot.git
cd whatsapp-bot

npm install

The dependency list in package.json shows what that pulls in, and it is a curated set rather than a generic framework. There is `baileys` itself, pointed at a GitHub source rather than a registry version, and a group of packages from the same author: `@arugaz/ai2d`, `@arugaz/collection`, `@arugaz/eventemitter`, `@arugaz/formatter`, `@arugaz/queue` and `@arugaz/translator`. Around them sit the pieces a WhatsApp bot actually needs, `axios` and `cheerio` for fetching, `link-preview-js` for link previews, `jimp` and `node-webpmux` for image and webp work, `qrcode` for pairing, `awesome-phonenumber` for phone number handling, `croner` for scheduled jobs, and `fastify` as the HTTP layer.

The `engines` field requires Node 16.0.0 or newer, and the package is marked private, so it is a base project to clone and adapt rather than something to install from npm.

Mongo, Prisma and a small environment file

Data is stored in MongoDB and accessed through Prisma, and the setup is two steps. First you create an `.env` file based on `.env.example` and copy the Mongo database URL into it, then you push the schema to the database:

npx prisma db push

The example environment file is short, and it shows the whole configuration surface:

# Mongo database for store primary data
# example url: mongodb://[username:password@]host1[:port1][,...hostN[:portN]][/[defaultauthdb][?options]]
# you can also use the atlas version
MONGODB_URL=your mongodb url

# SERVER PORT
PORT=3000

# SECRET API
SECRET_API=keepitsecret

Three settings, and the third is the one to think about. `SECRET_API` is the shared secret that the HTTP endpoints of the bot are guarded with, and the example value in the file is a placeholder that says so. `PORT` sets where the Fastify server listens, and `MONGODB_URL` points at the store for the primary data. The comment mentions both a plain MongoDB URL and the atlas version, so a hosted database is a supported path.

The repository keeps the schema in a `prisma/` directory and the rest of the source in `src/`, with `bin/` holding the language generator scripts and `database/` holding the language list.

A build step, and the reason it exists

The project is compiled before it runs, and the README links its reason to a page about transpilers in pm2, with the question written as "Why build into javascript?". The build command is:

npm run build

which maps to `tsc --build` in the manifest. The development script is more informative, since it shows the whole loop: it clears `dist` with `rimraf`, runs `tsc-watch` in build mode, and starts the result under `node --inspect` when the compilation succeeds, without clearing the screen. That is a debug-friendly setup, with the inspector attached from the first run.

The compilation exists for a practical reason rather than a stylistic one. A bot that stays connected to WhatsApp wants to start quickly and stay up, and pm2 is how the README recommends running it. Compiling once and running plain JavaScript under a process manager is more predictable than running a TypeScript loader in production, and the dev script keeps the same entry point.

The `main` field points at `./dist/main.js`, and the start script runs `node ./dist/main.js` directly, so the build output is what actually runs.

Translations are generated from a list of languages

Internationalization is a build step of its own. The README explains that the project generates languages based on the list in `database/languages.json`, and that you can remove the languages you do not want to use, since the objects are stored in memory, with the exception of English and Indonesian because those are generated by default.

Two scripts exist for this:

# try this:
npm run generateLang
# if get incompatible error, try run:
npm run generateLangV2

The fallback pattern is worth noting. The first script is `node -r ./bin/generateLang ./bin/generateLang.arugaz`, and the second is `node ./bin/generateLangV2`, a separate implementation. The README's advice is to try the first and switch to the second if you hit an incompatible error, which suggests the two paths are not equally maintained.

The runtime side of the same feature is the `@arugaz/translator` package, and the generated files live in `languages/`, with `languages/en.json` and `languages/id.json` as the two that always exist. The `languages/` directory is also part of the lint and format scope, since the lint script also runs prettier over the JSON files in the languages directory as well as over the TypeScript sources.

Running under pm2 and pairing with a QR code

To run the bot, the README gives a single command:

npm start

and a process manager path for servers that should survive a reboot. If pm2 is not installed:

npm install -g pm2

then the managed start is:

npm run start:pm2

which runs `pm2 start ecosystem.config.js`, saves the process list and tails the logs for the `whatsappbot` application. The pm2 configuration lives in `ecosystem.config.js` at the repository root, which is where the process name, the script and any environment come from.

Two extra commands cover the restart case. The README notes that this starts the application when the server is restarted or rebooted, and shows the Unix path with `pm2 startup` to create a startup script and `pm2 save` to save the current app, and the Windows path with `pm2-windows-startup` installed globally and `pm2-startup install`.

After that, you scan the QR code. The README's last line in the usage section says exactly that. For hosting, the badges list Termux, self hosting, Railway, Heroku, Koyeb and Replit, so the expectation is a small container or a cheap platform rather than a large server.

Version drift, the licence, and what this is not

The version numbers in this repository need reading carefully. The manifest says version 3.0.0, while the release tags are 2.1.0 from 2020-11-27, 2.0.0 from 2020-11-14 and 1.1.5 from 2020-11-03, and the tag names include one labelled "updates downloader!". So the tagged releases and the code in the repository are on different lines, and the tags are roughly six years behind the manifest version. The repository is not archived and the last push was on 2026-10-19, so development continues even though the tags have not moved.

The licence story is a consequence of the dependency. The README says that since whatsapp-bot uses baileys, and Baileys is now available under the GPL-3.0 licence, the project is distributed under GPL-3.0, and the manifest records `GPL-3.0-or-later`.

The other boundary is the one the pairing model implies. A bot that connects by scanning a QR code holds a session for an account, and the connection is provided by a community library rather than by a supported channel with a contract behind it. That is fine for a hobby bot, a community tool or an internal automation, and it is the wrong foundation for something that has to be reliable for paying users. The alternative approach is to run the same bot logic against an official business channel, where the trade is losing the QR pairing and the multi-device session in exchange for a supported interface, and where the bot code itself still looks broadly similar.

Editorial conclusion

Adopt whatsapp-bot when you want a ready-made Node and TypeScript base for a WhatsApp bot, with a database layer, a plugin style dependency set and translation files already wired, and when you are prepared to run the bot on an unofficial client connection. Do not adopt it for a product that needs a supported channel, and do not assume the release tags describe the code. Verify first that Node 16 or newer and FFMPEG are present, that `npx prisma db push` applies the schema in `prisma/` to the MongoDB instance named in `MONGODB_URL`, that the language files you need exist under `languages/`, and that the version you take matches the 3.0.0 in package.json rather than the 2.1.0 tag from 2020-11-27, given that the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. arugaz/whatsapp-bot on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases