Flash-Md-V3, a WhatsApp bot whose supply chain starts in a Bitbucket fork

One npm start script boots a WhatsApp session

Flash-Md-V3 is a WhatsApp bot for personal use, written in JavaScript and packaged as a Node.js project. The package manifest names it an advanced WhatsApp multi-device bot using Baileys, with version 3.0.0, module type set to module and index.js as the main entry point. What is interesting is how little you have to do to start it. The start script is a single chained command, the dev script drops the loader entirely, and a postinstall hook rebuilds sharp with the Puppeteer download skipped, which keeps the install light on a small container. The runtime constraints are stated plainly in the manifest, with Node between 20.x and 24.x and npm at 9.x or above. The repository root holds index.js, flash.js, preload.js, config.js, anti.js, bc.js, plus commands/, utils/ and france/ directories, an .env-sample, a Procfile for PaaS detection, and an app.json.

The core library resolves to a personal Bitbucket account

Here is the detail worth reading before anything else. The Baileys dependency is not taken from the public npm registry, it is installed straight from a git URL:

npm install

That install pulls the WhatsApp protocol library from a Bitbucket repository under a personal account rather than from the published @whiskeysockets/baileys package, and the URL itself embeds an account name in front of the host. A git dependency is a reasonable pattern for a patch, and a terrible place to put one that nobody reviews, because the code can change after the commit you audited, and the person who controls that account can change what you install at any time. A bot that holds a logged in WhatsApp session deserves a dependency you can point at. For a team, this is the single line that decides the outcome of a security review.

Deployment recipes for six platforms, all built on the same two variables

The README is mostly a deployment table, and it is more useful than it first appears. Render, Koyeb and Railway all follow the same shape: link the GitHub repository, set the build command to npm install and the start command to npm start, then supply the environment variables. Heroku is handled through a separate deploy button and needs a credit card on the account. Bot-Hosting.net and Optiklink.com both expect you to download the ZIP of the main branch, upload and extract it into a Node.js project, and fill in the same environment values before starting the bot from a panel or a web console. The three variables are consistent across every platform, which means moving a running bot between hosts is mostly a copy of three lines. Termux on Android is the local alternative, and the README gives the exact command sequence for it, starting with a clone of the repository and ending with the bot running on the phone itself.

A Termux install is four commands

The Android path is the simplest way to see the project run without a cloud account. Install Termux, clone the repository, move into the directory, install the dependencies and start the bot:

git clone https://github.com/franceking1/FLASH-MD-V3.git
cd FLASH-MD-V3
npm install
npm start

What you should see is the start script running, which is the chained command that boots the client and then loads the entry point with the custom loader:

node flash.js && node --loader ./preload.js index.js

That first file is worth knowing about. flash.js runs before index.js and the preload loader is registered at process start, which is the shape projects use to patch module loading. On Render the start command is simply npm start, so the same chain runs there. The presence of an anti.js file at the root and the preload loader means the project is doing more than calling a public API, and the README does not explain what either file does, so treat that as unknown behaviour rather than assuming it is inert.

Session IDs come from an external site, and the fork link points at V2

Two rough edges sit in the getting started steps. A WhatsApp session identifier is obtained from a separate hosted service rather than generated by the repository, and the fork button in the README links to the Flash-Md-V2 repository, not to V3, so a new user following the instructions literally forks the wrong project. The deployment guidance for Render also carries a 24/7 instruction to add the Render app link to .env, which reads as a way to keep the session alive rather than a documented configuration key, and the .env-sample file at the root is where the actual variable names live: SESSION, YOUR_NUMBER and YOUR_LID. Note that the deployment table instructs a first deploy without the session variables and a second step to add them, which tells you the service starts and waits for a session rather than failing fast when it is missing.

The licence in the repository and the licence in package.json disagree

The repository is published under GPL-3.0, and the package manifest declares its license field as MIT. Those are different obligations, and the project does not explain which one governs a given copy, a fork or a redistribution. The README adds a warning of its own, telling users not to copy, modify or redistribute the bot without proper permission, to credit the original authors and the libraries used, and that misuse or abuse is prohibited. A GPL-3.0 file in the repository, an MIT field in the manifest and a restrictive notice in the README are three different signals, and picking one at random is not a defensible position for a business that plans to ship this internally. Settle the question against the LICENSE file and the upstream project before redistribution.

What a buyer gets and what they do not get

There is no GitHub release for this project, and the last push was on 2026-06-12, so there is no versioned artifact, no changelog and no upgrade path beyond whatever the main branch happens to contain on the day you clone it. The dependency list tells you what the bot is built from, and it is wide: axios, cheerio, express, ws, node-cron, pino and dotenv sit alongside media tooling such as ffmpeg-static, fluent-ffmpeg, sharp, jimp, puppeteer and acrcloud, plus a set of scraper and downloader packages. The optionalDependencies block means the heavy media stack is only installed when wanted, but the postinstall script still rebuilds sharp on every install, which is one more thing that can fail on a constrained host. The realistic alternative to the whole package is to write your own small service on top of the public Baileys package with express and axios, which is a day of work for a single group command but removes the personal fork, the licence ambiguity and the unversioned main branch from your supply chain.

Editorial conclusion

Flash-Md-V3 suits an individual who wants a featureful WhatsApp bot running on a personal account within an hour, and suits teams that accept an unaudited script that talks to a WhatsApp account under their own phone number. It does not suit a business that needs a maintained dependency chain, a clear licence, or an answer about who owns the account when the bot misbehaves, since the core library is pulled from a personal Bitbucket fork and no GitHub release exists. Before you deploy, read the pinned Baileys URL in package.json, decide which licence you are actually complying with, and check what the commands in the commands/ directory do before enabling them on a group with real members.

Frequently asked questions

Official sources

1. franceking1/Flash-Md-V3 on GitHub
2. Issues
3. License: GPL-3.0
4. README