KHAN-MD is a WhatsApp group bot built on Baileys with a PM2 and Heroku deployment path

The bot runs on an unofficial WhatsApp client

KHAN-MD describes itself as a simple WhatsApp bot to manage groups, and the package.json description says it was created by JawadTechX. The README's own tagline describes it as built on Baileys, designed for speed, enhanced for stability.

The Baileys dependency is the defining technical fact, and the README makes it visible with a badge for Baileys alongside badges for WhatsApp MultiDevice and Node.js. In package.json the dependency is pinned as @whiskeysockets/baileys with the value github:WhiskeySockets/Baileys, so the package is taken from a git repository rather than from a published registry version.

That has two consequences. The first is that the library is not an official WhatsApp interface, and the pairing workflow in the README reflects that. To use the bot, you link a device through pairing portals, and the project hosts a pair code generator at khanmd-pairx.onrender.com under a heading called GET SESSION ID. The README notes that connection issues may require VPN activation, which is the kind of caveat that comes from a bot library depending on undocumented behaviour.

The second consequence is where breakage will show up. A library tracked from a repository rather than a tagged release can change under you, and a bot that talks to a messaging service is sensitive to protocol changes in a way that a library with a stable API is not. The README ships several one-click hosting buttons, and the README asks for stars and forks as part of the deployment steps, which suggests a community deployment pattern rather than a product with a support contract.

The dependency list is a catalogue of what the bot can do

The package.json dependencies are the most informative document in the repository, because in a bot project the feature list is the dependency list.

The media stack is the largest group. @ffmpeg-installer/ffmpeg and ffmpeg with fluent-ffmpeg handle video and audio processing. adm-zip handles archives, file-type detects file types, and jimp is listed at version latest for image processing. wa_set_pkg and wa-sticker-formatter are WhatsApp specific sticker tooling, and @ffmpeg-installer/ffmpeg plus file_size_url deal with size limits on outgoing media.

The text handling is a separate cluster. @vitalets/google-translate-api and translate-google-api give translation, google-tts-api gives text to speech, and axios and node-fetch with form-data handle outbound HTTP and multipart uploads. moment-timezone and the events package cover scheduling and time zones, and link-preview-js with cheerio produce link previews, with a cheerio release candidate pinned at 1.0.0-rc.12.

Then there is the download side. megajs points at MEGA file hosting, yt-search at YouTube search, and adm-zip and file-type again for handling what comes back. The result is a bot whose feature set reads like the command list of a group assistant: send media, convert media, translate, speak, fetch from cloud hosts, preview links, and manage the group.

The dependencies also reveal a maintenance posture. jimp is pinned to latest, and several packages are pinned to exact versions while others use carets, so a fresh install can pull in a different tree than the one the author tested.

Three deployment paths: PM2, Heroku and a Docker image

The npm scripts are the whole runtime story, and they are built around PM2.

"start": "pm2 start index.js --deep-monitoring --attach --name KHAN-MD",
"stop": "pm2 stop KHAN-MD",
"restart": "pm2 restart KHAN-MD"

PM2 keeps the process alive, and the deep-monitoring and attach flags mean the process is supervised and connected to the terminal, which is what you want when you are watching a bot respond in real time. The stop and restart scripts name the same process, so the operational vocabulary is a single named process rather than a set of systemd units.

The Dockerfile is short. It starts from node:lts-buster, sets the working directory to /app, copies the files in, runs npm install and installs pm2 globally, exposes port 9090, and starts with npm start. The exposed port is for the Express server that package.json also depends on, most likely the pairing dashboard and any web hooks.

For platform as a service, the repository carries a heroku.yml and an app.json, and the README offers one-click deploy buttons for Heroku, Replit, Koyeb, Railway, Render and Netlify. Those buttons point at a different repository path in the URL, github.com/JawadExtra/KHANXMD, which is worth noticing: the deployment templates are wired to a fork rather than to the repository you are reading.

The project also has a KHAN MD Mini site at khan-mdx.vercel.app, linked as a START KHAN MD button, and a Deploy On Panel section with a link to a zip archive of the main branch.

The source layout is small and the config is a single file

The top level of the repository is compact: index.js as the entry point, command.js, config.js, a Dockerfile, heroku.yml, app.json, a SECURITY.md, a LICENSE and the README. The package.json declares the type as module, so the code uses ES module syntax rather than CommonJS, and main points at index.js.

config.js is the file to look at first, because in a bot of this kind the configuration holds the session credentials and the bot identity. The README's deployment instructions say to add your setting variables after cloning or forking, and the presence of dotenv in the dependencies means those settings can come from an environment file as well as from the config module. Whether secrets are read from the environment or committed alongside the source is exactly the thing to check in a repository with a public fork and a public session generator site.

The command structure is the other half. index.js and command.js together are the whole application, with the plugins and command handlers presumably reached from there, which is a very small surface for a project with three dozen dependencies. There is no test directory and no lint configuration in the tree, so the quality gates that exist in the repository are limited to whatever runs in CI, if anything.

The maintenance state is modest. The last push was on 2026-09-05, the repository is not archived, and there are no GitHub releases even though the README announces a deploy of version 15.0.5 while package.json still says 15.0.0. The version number in the README and the version in the manifest have drifted, which is a small signal that the release notes and the package metadata are updated by different hands.

Where this kind of bot is the wrong choice

The first limit is the one the project itself is built on. The bot depends on an unofficial library and on a pairing flow rather than on an official WhatsApp Business API. That means there is no contractual guarantee of continued operation, no official support path when WhatsApp changes something, and a session that is fundamentally a logged in account rather than an API integration. For a business workflow that depends on the bot being up, that is a structural risk, not a configuration detail.

The second is the credential handling. A paired session is as sensitive as a password for the account it belongs to, and this project distributes that process through a public pair code generator site on Render. Using a third party site to generate your pairing code means the code transits infrastructure that is not yours. The SECURITY.md file in the repository should be read before deploying, and the fact that a separate pair code site exists at all is the reason to.

The third is the dependency surface for something that runs with access to a chat account. The dependency list includes unpinned latest versions, a release candidate of cheerio, and a git-sourced library, and a bot that processes incoming media and executes ffmpeg is a larger attack surface than the README's badges suggest.

The fourth is the feature depth versus the documentation. The README is a deployment funnel, with pairing, deployment buttons and a link to a Vercel demo, while the actual command list is not in the README at all. Anyone evaluating this needs to read the source or ask the community, and the project has no releases, no changelog in the tree and no documented command reference.

Editorial conclusion

KHAN-MD suits someone who wants to run a feature rich WhatsApp bot for their own groups and is comfortable with an unofficial client and a pairing step, and it is the wrong tool for a business that needs a supported, contractual WhatsApp integration, since the project depends on an unofficial library. Before deploying it, read SECURITY.md and check what the session credentials are, because a paired session is effectively a logged in account. Verify first that the bot library version in package.json, which is taken from a GitHub repository rather than a published version, still works with WhatsApp, since that dependency is where breakage will show up.

Frequently asked questions

Official sources

1. Issues
2. JawadTechYT/KHAN-MD on GitHub
3. License: Apache-2.0
4. Project website
5. README