Knightbot-MD: A Baileys WhatsApp Group Admin Bot You Self-Host

The group admin problem Knightbot-MD targets

WhatsApp group administration does not scale by hand. Tagging every member of a large group means typing the same message repeatedly. Enforcing a no-links rule means watching the chat. Warning and removing disruptive members means remembering who was warned. Knightbot-MD exists to move those repeated actions behind chat commands. The README describes it as a bot "built using the Baileys library for group management, including features like tagging all members, muting/unmuting, and many more," and it is aimed at admins rather than at end users. The command list in the README is concrete: .tagall for tagging members, .tts for text-to-speech, .sticker for sticker creation, anti-link detection, and warn-and-manage controls restricted to admins. Tic-tac-toe is listed among the games, which tells you the project also wants to keep groups active, not just policed. That mix is the point. A single process handles moderation and engagement, and the operator is whoever holds the WhatsApp account the bot is linked to.

How the Baileys link and command routing work

Knightbot-MD does not use the official WhatsApp Business API. It uses @whiskeysockets/baileys, which the package.json pins at ^v7.0.0-rc.9, to speak the WhatsApp Web multi-device protocol. The README confirms the bot "uses the Baileys library to interact with the WhatsApp Web API and supports multi-device features." In practice you link the bot the same way you link a browser session: the bot authenticates as a companion device on your WhatsApp account. The README describes two paths. The manual path is to run the bot and scan a QR code from Linked Devices in WhatsApp. The README's deploy steps describe a second path where you generate a pair code through a hosted helper, then upload the resulting creds.json file into the session folder. The repository layout backs this up: index.js and main.js are entry points, commands/ holds the command implementations, lib/ holds shared code, config.js and settings.js hold configuration, and session/ is where credentials live. The consequence is that the bot is a client of your account, not a separate number. Anything the bot can do, it does with your account's permissions, and if the session credentials leak, whoever holds them holds that session.

Installing Knightbot-MD and running the first command

The README's prerequisites are Node.js and Git. The step-by-step setup is short: clone, install dependencies, run, scan. Clone the repository and move into it:

git clone https://github.com/mruniquehacker/Knightbot-MD.git
cd Knightbot-MD

Install the dependencies listed in package.json:

npm install

Start the bot:

node index.js

The README states that once the bot starts, a QR code appears in the terminal, and you scan it using the Linked Devices feature in WhatsApp. After the link succeeds, the session is written into the session/ directory, and later starts reuse it. package.json also defines npm start as node index.js, plus a start:optimized script that runs Node with --max-old-space-size=512 and --optimize-for-size, and a start:clean script that runs cleanup before the optimized start. Those scripts exist because a long-running bot accumulates state; the README does not explain what cleanup.js removes. The README's alternative path is the pair code flow: generate a code through the hosted helper it links, then upload the resulting creds.json file into the session folder. Once the bot is connected, an admin in a group sends .tagall to tag the members, or .sticker to convert media into a sticker. Only group admins can use the restricted commands, per the README's feature list.

Where Knightbot-MD breaks down

The first limitation is the host. A Baileys bot holds a live socket to WhatsApp, so the process has to stay running. The README's own deployment options are panels and VPS providers, which is an admission that a laptop that sleeps will drop the session. The second limitation is the session file. The README treats creds.json as something you generate and upload, but it does not document what happens when that file is lost, revoked, or leaked. There is no documented rollback, no key rotation procedure, and no guidance on backing up session/. The third limitation is version pinning. package.json depends on @whiskeysockets/baileys at ^v7.0.0-rc.9, a release candidate. A caret range on a release candidate means a minor publish can change protocol behaviour under you, and the README does not describe a tested upgrade path. The fourth is the absence of tests: the test script in package.json is echo "Error: no test specified" && exit 1. If you modify commands, nothing in the repository checks your change. Finally, this is the wrong tool if you want a bot on a number you do not control, or if you need an audit trail of moderation actions, because the README describes none.

Knightbot-MD compared with the official WhatsApp Business API

The real alternative is the official WhatsApp Business Platform API. The difference is architectural, not cosmetic. The official API gives you a separate business number, server-side message delivery through Meta's infrastructure, and a documented rate-limit and template model. Knightbot-MD gives you none of that. It links to your existing personal account as a companion device, and its capabilities are exactly the capabilities of that account. The trade runs both ways. The official API cannot run .tagall across a group the way a linked device can, because group administration through the API is not the same surface. Knightbot-MD can, because it is a client of your account. What you give up is stability and support. The official API has a vendor behind it; Knightbot-MD has a README, a Telegram group, a WhatsApp channel, and a YouTube tutorial. If your requirement is a bot that survives a WhatsApp protocol change without you touching code, the official API is the safer path. If your requirement is group admin commands on an existing account with no business verification, Knightbot-MD is the direct route.

Maintenance cost, licence and what the README leaves open

The last push to the repository was on 2026-05-11. The repository is not archived. That is the only maintenance signal available; there are no retrieved releases, so there is no changelog to read and no version history to compare against. Upgrading means editing package.json and reinstalling, and the README documents no migration steps, no breaking-change notes, and no compatibility statement for Baileys versions. Budget for that. The licence situation is genuinely confusing and worth flagging plainly. The README's License section states the project is licensed under the MIT License and links to an MIT page and a LICENSE file. package.json declares "license": "ISC". Those are different licences with different terms. The repository does contain a LICENSE file, and that file is the authoritative artifact, but the README does not quote it and its contents are not shown in the README. Do not assume MIT because the README says so. Check the LICENSE file in the fork you deploy, and if you redistribute the bot or ship it inside a product, resolve the discrepancy before you do. This is a factual inconsistency in the repository, not a legal opinion, and it is the kind of thing that matters more than the feature list.

Editorial conclusion

Adopt Knightbot-MD if you run a large WhatsApp group, you are comfortable with Node.js, and you have a host that stays online. Do not adopt it if you need a managed service, an uptime guarantee, or documented rollback and upgrade procedures, because the README does not describe any. Before you commit, verify the licence situation yourself: the README says MIT while package.json says ISC, and the repository's LICENSE file is the only thing that settles which one applies.

Frequently asked questions

Official sources

1. Issues
2. mruniquehacker/Knightbot-MD on GitHub
3. Project website
4. README