TheMystic-Bot-MD: a plugin-driven WhatsApp bot built on Baileys

A chat surface over a large plugin directory, aimed at personal accounts

TheMystic-Bot-MD presents itself as an automated bot for WhatsApp built on Node.js, for people who want to trigger functions from a chat window instead of from a dashboard. The project description, written in Spanish, names the audience explicitly: people who want WhatsApp automation, or a personal WhatsApp bot that speaks several MD variants, specifically TheMystic. That framing matters, because the whole repository is organised around a personal, single-account scenario rather than around a managed customer-facing channel.

The feature surface is wide, in the way these Spanish-language WhatsApp bot projects usually are. The dependency list in package.json pulls in media tooling such as fluent-ffmpeg, file-type and browser-id3-writer, a lyrics lookup package, a Google text to speech API client, a Google translate API client, a phone number inspection library and a set of scraping helpers for music and app metadata. Add chart.js and d3-node for generated images, plus an express server, and the shape of the product becomes clear: a dispatcher that answers a chat command with a media file, a translated string, a lookup result or a rendered graphic.

For an engineer evaluating it, that broad surface is the first trade-off. Nothing in the project narrows the scope to a coherent domain, so the value of the tool depends entirely on which plugins in the plugins directory you actually intend to run.

Three npm scripts are the whole entry contract, and one of them is undocumented

The runtime contract of the project is small and easy to read, because it lives in the scripts block of package.json. The main file is index.js, the package is declared as an ES module, and the three runnable modes are start, qr and code. The eslint and eslintfix scripts are also present, and a .eslintrc.json sits at the root, so linting is part of the project rather than an afterthought.

    "start": "node --trace-deprecation index.js",
    "qr": "node index.js qr",
    "code": "node index.js code",

The qr mode exists to produce a pairing code, and the Dockerfile confirms how that is meant to work: after the ordinary install it adds one extra package that is not in the dependency list.

RUN npm install && npm install qrcode-terminal

That single line is the most useful install hint in the repository. A reader who runs npm install locally will not get a QR renderer, so the terminal output of the qr mode depends on that second install, which the Dockerfile performs automatically. The code mode is the sibling entry point for pairing, and the README does not document what it prints or how it differs from qr, so treat it as an undocumented alternative rather than a known flow.

Baileys carries the connection, and it is pinned to a release candidate

The actual WhatsApp connection is not code written by this project. It comes from baileys, listed in package.json as ^7.0.0-rc14, alongside @shineiichijo/marika, which appears to be a related wrapper, and @adiwajshing/keyed-db, a small key value store that a bot needs to remember things such as which user asked for what. Everything else in the repository is the command layer built on top of that pairing.

The repository root makes the layering visible. index.js and main.js drive the process, handler.js holds the dispatch logic, constants.js and config.js hold configuration and constant values, api.js holds outbound API calls, and server.js with index.html, views and web provide an HTTP surface. The plugins directory is where the commands live, and src is the rest of the source tree.

The pin deserves attention. A release candidate is not a stable release, and a caret range on an rc tag means an install can pull a build that the project has not settled on. For a long lived deployment this is the constraint to plan around, because the behaviour of the pairing layer can shift underneath your plugins without any change in your own code.

Deployment is a set of one-click buttons rather than a documented procedure

There is no installation tutorial in the README. What exists instead is a deployment gallery: badges for GitHub Codespaces, Glitch, Heroku, Koyeb, Repl.it, Render, Termux, Linux and Windows, each linking to a hosted deploy flow for the master branch. Two hosting resellers get their own sections with links to a client area and a control panel, Cafirexos and BoxMineWorld.

The container path is the most explicit of these, and the Dockerfile is short enough to read in one pass. It starts from node:lts-buster, installs ffmpeg, imagemagick and webp so media commands have real codecs behind them, copies package.json, installs, copies the source, and then opens a port.

FROM node:lts-buster

EXPOSE 5000
CMD ["node", "index.js", "--server"]

Note that the container runs the server flag rather than the bare start script, and that it listens on port 5000. Two other files support platform deploys without a container: render.yaml for Render and app.json for Heroku style one click deploys, alongside a Procfile. The README does not document any of these files, so a reader who wants to understand what the platform actually runs must read them in the repository.

The README opens with a deprecation notice about the plugin base

The banner at the top of the README is the first thing a reader sees and it changes how the project should be judged. It states that the last update of the base was 09/2026 and that the plugins are deprecated and the plugin project is outdated. The project description itself begins with the word DEPRECATED. The README also warns that the original author is not able to work on the project because of personal time constraints, and that the project is in the hands of contributors and users who want to send updates.

That changes what maintenance means here. The last push was on 2026-09-03, which is recent, but recent commits do not mean the plugin set is healthy. The three tagged releases, v1.0, v2.0 and v3.0, all carry the same date, 2024-12-05, so the tag list describes a one-off backfilled set rather than a release cadence you can plan around. The deprecation of the plugins is the more meaningful signal, and it points at the plugin directory as the fragile part of the system.

The README is also careful about affiliation. It states that the project is not affiliated, endorsed or associated with WhatsApp, which is a registered subsidiary of Meta Platforms Inc, and it separates official community links from the many unofficial places that claim the same name.

Where this bot is the wrong tool

The first wrong-tool case is any use that needs a contract with WhatsApp itself. The connection is carried by baileys, a community library, and the README says outright that the project has no official relationship with the platform. That rules out the requirements that come with an official business channel, such as documented limits, a support path when the protocol changes, or a channel that a platform policy change cannot simply sever.

The second case is a plugin that has to keep working. The plugin base is described as deprecated in the README, the original maintainer has stepped back, and the pairing library sits on an rc range. If a command is business critical, the realistic expectation is that you fork the plugin you need and own it.

The third case is a host you cannot install binaries on. The Dockerfile shows why: ffmpeg, imagemagick and webp are installed at the image level, so audio and image commands need a Linux image with those packages. A bare Node host is enough to run the dispatcher but not to run the media features, which is the bulk of the feature list. For a hobbyist running the Termux path on Android, the same three binaries have to be present there too, and the README does not describe that setup step by step.

Editorial conclusion

TheMystic-Bot-MD suits an engineer who wants a WhatsApp command surface for a personal account and is willing to own the pairing layer and the plugin base. It is the wrong choice for a business channel that needs an official API contract, an SLA, or a maintained plugin set. Before adopting, check the Baileys version in package.json, run the qr mode on a spare session, and read the deprecation notice at the top of the README, which names the last plugin base update as 09/2026.

Frequently asked questions

Official sources

1. BrunoSobrino/TheMystic-Bot-MD on GitHub
2. Issues
3. Project website
4. README
5. Releases