star-xd: a feature-heavy WhatsApp bot built on an unofficial client

An unofficial client is the foundation, and the warning says so

Star XD is described as an advanced WhatsApp bot with AI features, media tools and group management, built on Baileys by Malvin King. The Baileys library, published as @whiskeysockets/baileys and pinned at version 7.0.0-rc.9 in the dependency list, is an unofficial WhatsApp client library, and that single fact determines both what this project can do and what it risks.

It can do what the official client cannot, because it is not bound by the official client API. It can intercept and resend status messages, keep copies of view once media, and react to messages automatically, none of which the business API offers a user.

It also carries the risk that comes with that. The README's own security alert is blunt: never use your personal WhatsApp number as the bot number, because WhatsApp may detect automated activity and permanently ban your account, and it advises using a dedicated secondary number for bot deployment.

That warning is the most useful line in the README for anyone evaluating the project, because it is the vendor of the platform telling you the deployment will be detected. A project that told you the opposite would be the one to worry about.

The project is JavaScript rather than Python despite what the repository metadata says, and it runs on Node. The package is star-xd at version 3.5.0, an ES module whose entry point is index.js, with the application code under lib/ and the configuration under settings.js and malvin.json.

The audience is therefore clear: individuals and small communities running a WhatsApp identity as an automation agent, not enterprises looking for a supported messaging integration.

Fifteen feature groups, all marked as working

The feature table in the README lists fifteen menus and marks every one of them as supported, which is unusual clarity for a project of this kind.

The menus are Status Save + Send, Group, ChatBot, Downloading, Antidelete, Ai, Viewonce, Fun, Status Reply, Status Reacts, HeartReacts, Autoreacts, Call Rejecter, Polls and Broadcast.

Several of these are conventional bot features. Downloading saves media from messages, Group covers group management, ChatBot is a conversational mode, Polls creates polls, Broadcast sends a message to many chats, and Fun holds the novelty commands. The Ai menu is the one the project description leads with.

The rest are the ones that distinguish it from a general purpose WhatsApp library wrapper. Status Save + Send and Status Reply are about the disappearing status feature. Viewonce keeps the media that is normally shown once. Antidelete deals with the disappearing messages setting. Status Reacts, HeartReacts and Autoreacts are about reacting to messages, and Call Rejecter is about handling incoming calls.

Taken together, they describe a bot whose centre of gravity is the features WhatsApp deliberately made ephemeral. That is a coherent product decision rather than a random feature list, and it is also the part with the clearest terms-of-service exposure, since the antidelete and view once features exist to preserve content the platform is designed to destroy.

The README does not document what each command does in detail, so the menu names are the specification available to an evaluator.

Pairing a session means trusting a third party web service

Getting a WhatsApp account onto the bot is where the deployment stops looking like an ordinary self-hosted service.

There is a fork requirement in the README, marked as important: you must fork the STAR-XD repository first before accessing the session pairing web interface. Three pairing servers are linked, the first two live and the third marked as coming soon, and there is a note that if a server is down you should try an alternative because your session ID works on all servers.

That last sentence is the important one. The session identifier is portable across all three servers, which means the servers are interchangeable components in the pairing path rather than independent implementations. A pairing code is the credential that links a phone number to the bot process, and a note saying that a session ID works on any of several hosts is a description of a credential that can be presented to any of them.

For a project whose entire point is to own a WhatsApp identity, that is a sharp edge. Anyone running this is handing a session identifier to infrastructure they do not control, in exchange for a convenience that a local pairing flow would provide. The repository is the source of the pairing code, so the maintainers could substitute their own hosts at any time without changing the workflow.

The README does not describe the pairing protocol, does not say whether the session data is stored on the server, and does not publish a privacy policy for those hosts. The homepage is a YouTube channel rather than a documentation site, so there is no obvious place where that would be written down.

The right way to read this section is as an evaluation task: if the session credential matters to you, ask the maintainers what those servers do with it, or run the pairing yourself from a fork you control.

A configuration file for every hosting platform you can think of

The deployment story is broad, which is unusual and slightly revealing about the audience.

There are one-click deploy buttons for Heroku, Koyeb, Railway, Render, Replit and Fly.io, and separate links for two hosting resellers. Each of those platforms is backed by a configuration file in the repository, and the file list is long: heroku.yml, railway.json, render.yaml, fly.toml, app.json for the Heroku app template, Procfile, replit.nix and .replit, plus the Dockerfile and a sample.env for the environment variables.

The README also gives panel deployment advice, telling Pterodactyl users to use a Node.js 20 or newer egg, to set the startup command to npm install and npm start, and to ensure the panel uses Node.js 20 or newer, with a note that a Dockerfile is available for panels that support it.

There is also a performance tip that is worth reading twice, because it is a trade rather than a free improvement. For the best performance on cloud platforms, use MongoDB Atlas for database storage and set COMMAND_MODE to public. The second half of that is a switch that changes how commands are exposed, and the README does not document what public means here or who can then issue commands.

So the deployment surface is broad and the operational documentation is thin. You will find a button for almost every platform and a sentence of advice for each, but the questions of who can run the bot and against which database are decided by a single environment variable whose semantics are not written down anywhere in the repository.

The Docker image installs the native toolchain for media work

The Dockerfile is the clearest technical document in the repository, and it explains a lot about what the bot does.

The base is node:20-bullseye-slim, which pins the runtime. The apt layer installs ffmpeg, imagemagick, git, python3, make, g++, and libvips-dev, with a comment noting that sharp does not need to be built. That is a media processing toolchain: ffmpeg for video and audio conversion, imagemagick for image work, and libvips with sharp for image encoding.

The install step uses npm install with the legacy peer dependencies flag, and the comment above it says the point is to install without building from source using prebuilt binaries. The image then copies the loader, index.js, creates the data, session, temp, assets, lib and plugins directories, exposes port 5000, and runs the optimized start command.

That last detail is a nice touch. The npm scripts define start as node index.js, and start:optimized as node with a 512 megabyte old space cap, the optimize-for-size flag and a 100 millisecond garbage collection interval, which is a sensible configuration for a long-running process on a small container. There is also a start:fresh script that runs a data reset before starting, and separate reset-data and reset-session scripts for the same purpose, including a reset-session that removes the session directory with a recursive, forced removal.

The image is a good template for anyone who wants to see what a Baileys bot needs in practice: a Node runtime, a media toolchain, writable directories for session and data, and a single exposed port.

Plain JavaScript, no build step, and two test tiers

The package manifest is worth reading because it shows how little ceremony this project has.

The build script is literally an echo stating that no build step is needed because it is plain JavaScript. The main entry point is index.js, the type is module, and the directories section points at assets, lib, data and plugins. The project is plain Node with no bundler and no transpilation step, which is consistent with a codebase that ships as a directory of files to a host.

The test story is more organised than the build story. Vitest is the runner, with separate scripts for the unit tests and the integration tests, a watch mode, and a plain test script that runs everything. Linting uses ESLint over the JavaScript files, configured by eslint.config.mjs, and there is an audit script that runs npm audit while omitting the dev dependencies.

The development script uses nodemon watching the whole tree for JavaScript changes while ignoring node_modules and the data, session and temp directories, which is a sensible set of exclusions for a bot that writes state while running. The devDependencies include better-sqlite3, which needs a native build, and the Dockerfile installs make and g++ partly for that reason.

Overall, the codebase is a modern Node project with a conventional test and lint setup, and the only unusual thing about it is the size of the dependency list and the fact that the runtime it drives is WhatsApp itself.

The licence is claimed in one file and absent from another

There is a small inconsistency in the project's legal metadata that anyone reusing this code should resolve first.

The package.json in the repository declares the licence as MIT and names Malvin King as the author, with the homepage and repository pointing at the XdKing2/star-xd project. The repository itself is hosted at mrxdking/star-xd, the project description calls it a Python project, and the GitHub metadata records the licence as unknown. The top level of the repository contains no LICENSE file at all.

The naming mismatch is easy to explain: this looks like a fork or a rename of the original project, with the README, the badges and the package metadata still pointing at the original repository. That also explains the description saying Python while the code is JavaScript.

The licence question is the one that matters for reuse. A licence field in package.json is a claim, and it is a reasonably common practice, but it is not the same as a licence file with the terms in it, and the absence of a LICENSE file at the root leaves the terms genuinely unclear.

Other facts worth recording. The last push to the repository was on 2026-09-21, and there are no GitHub releases, so version tracking depends on the version field in package.json, currently 3.5.0. The topics cover none of the important operational questions, and the homepage is a YouTube channel rather than a documentation site, so the README and the video walkthroughs are the whole of the published documentation.

Editorial conclusion

star-xd suits someone who runs a WhatsApp account as a dedicated automation identity rather than a personal one, and who wants the fifteen feature groups the README lists without writing a Baileys integration from scratch. It does not suit a business that needs a supported messaging channel, because the whole thing runs on an unofficial client, and it does not suit you if your account is one you cannot afford to lose, because the project itself warns that WhatsApp may detect automated activity and permanently ban the number. Check three things before you deploy it: that you have a secondary number for the bot, that you have read how the session pairing works, since it is handled by an external web service, and that the licence position is acceptable to you, because the package metadata says MIT while the repository itself carries no licence file. The last push to the repository was on 2026-09-21 and the project publishes no GitHub releases.

Frequently asked questions

Official sources

1. Issues
2. mrxdking/star-xd on GitHub
3. Project website
4. README