WhatsAppBotMultiDevice

A multi-device WhatsApp bot built on Baileys (7.0.0-rc), running on Bun. It downloads media, makes stickers, searches the web, chats with an AI assistant (Eva, powered by Gemini), tracks group activity and ranks, and ships with an admin dashboard for managing it all.

• Commands for everyday use: stickers, YouTube / Instagram / Twitter / Reddit downloads, lyrics, translation, weather, reminders, Wikipedia, memes and more (full list below).
• Eva: a Gemini-powered group assistant that can chat and summarise the group's history.
• Group tools: welcome messages, rules, warnings, rank / XP, message counts, per-group feature toggles and command blocking.
• Admin dashboard (React + Vite) at /admin: status, QR pairing, groups, members, analytics, command stats, logs, broadcast and direct messages. Login is by admin password or Google OAuth.
• Performance: MongoDB-backed auth state and data, layered in-memory + Redis caches (group metadata, user devices), and a rate-limited send queue.
• Owner tooling: clearcache, stats, broadcast, toggle, DB control and more.

1. Set up the environment, at minimum MONGODB_KEY, MY_NUMBER, BOT_NUMBER, PREFIX, ADMIN_PASSWORD and SESSION_SECRET.
2. Start the bot (locally or with Docker, below).
3. Open the web page (http://localhost:8000) and scan the QR code with the WhatsApp account the bot should use (Linked devices > Link a device). The session is stored in MongoDB, so you only pair once.
4. Send -help from your MY_NUMBER account to check it replies, then -owner for the owner commands.

• Bun 1.x
• MongoDB (MONGODB_KEY)
• ffmpeg (FFMPEG_PATH, or the bundled ffmpeg-static)
• yt-dlp for YouTube downloads (YTDLP_PATH; the Docker image installs it)
• Optional: Redis for persistent caches (USE_REDIS=true)

cp .env.example .env     # then fill in the values (see below)
bun install
bun run build            # builds the dashboard
bun start                # or: bun run start:dev / start:production

Open http://localhost:8000 (or your PORT) and pair the bot by scanning the QR code. The dashboard lives at /admin; /health is the liveness probe.

Other scripts: bun run lint, bun run lint:fix, bun run fmt, bun run fmt:check. Maintenance scripts (DB backup, auth-state cleanup, LID migration) are in scripts/.

bun run --cwd dashboard dev    # http://localhost:5173, proxies /api to localhost:8000
bun run build                  # production build into public/app, served at /admin

Run the bot (bun start) alongside the Vite dev server.

Copy .env.example to .env. Never commit it.

cp .env.example .env
./build.sh up            # build + start detached

build.sh wraps the common tasks: logs, restart, update (git pull + rebuild), ytdlp (update yt-dlp in the container), health, env (check required vars), nginx and ssl (reverse proxy + Let's Encrypt, config in deploy/nginx/). Run ./build.sh with no arguments for the full list.

The container listens on 127.0.0.1:${PORT:-8080} only; put Nginx (or another TLS proxy) in front of it.

index.js          Express server, dashboard + API, boot
connection.js     WhatsApp socket startup and reconnects
core/             Baileys events: messages, group events, calls, connection, auth
commands/         One file per command, split by who may use it
  public/  group/members/  group/admins/  owner/
cache/            In-memory + Redis caches (group metadata, user devices)
queue/            Rate-limited outgoing message queue
db/               MongoDB access (members, groups, reminders, stats)
routes/           Dashboard / admin REST API
dashboard/        React + Vite admin UI (builds to public/app)
utils/            Command loader, roles, LID helpers, yt-dlp, safe fetch, ...
notify/           Admin event stream, Telegram and owner notifications
scripts/          Maintenance scripts (see below)
deploy/nginx/     Reverse-proxy config used by ./build.sh

An incoming message goes through core/messages.js, which resolves the sender's role, checks blocks and group feature toggles, finds the command via utils/commandLoader.js, and calls its handler. Replies are sent through queue/ to stay within WhatsApp's rate limits.

Create a file in the folder matching who may use it (commands/public, group/members, group/admins or owner). It is loaded automatically at startup.

const handler = async (sock, msg, from, args, msgInfoObj) => {
  const { sendMessageWTyping } = msgInfoObj;
  return sendMessageWTyping(from, { text: `pong ${args.join(" ")}` }, { quoted: msg });
};

export default () => ({
  cmd: ["ping2", "p2"], // name and aliases
  desc: "Reply with pong.", // shown in help
  usage: "ping2 <text>",
  handler,
});

msgInfoObj carries the prefix, sender JID, isGroup, the text after the command (evv), quoted-message info and send helpers. Look at a similar existing command for the fields you need. Before opening a PR, run bun run lint and bun run fmt:check.

Send help (or menu) in chat for the live list, or help <command> for details. Examples use a - prefix.

owner lists everything. Highlights: broadcast, hidetag, block / unblock, toggle (per-group features), stats, clearcache (flush group metadata and device caches, memory + Redis), clearhistory / evainfo (Eva memory), group / member / bot (DB records), jid / lid, removebot, and test (eval, disabled unless ENABLE_EVAL=true).

Run with bun scripts/<name>.js (they use the same .env).

• Keep .env out of version control and use a long random SESSION_SECRET.
• Leave ENABLE_EVAL unset in production: the test command runs arbitrary code with full server access.
• Leave CORS_ORIGINS empty unless another site must call the API; the dashboard is same-origin.
• Serve the dashboard over HTTPS (./build.sh ssl) and keep the container bound to localhost.
• This bot automates a WhatsApp account through an unofficial API. That can violate WhatsApp's terms and the account may be banned, so use a dedicated number, not your personal one.

Koyeb builds the repo's Dockerfile, which already includes Bun, ffmpeg and yt-dlp.

1. Create an account at koyeb.com and create a new app.
2. Choose GitHub as the source and select this repo.
3. Set the builder to Dockerfile. No build or run command is needed, the image starts the bot itself.
4. Add the environment variables as secrets. Set PORT=8080 and expose port 8080 as an HTTP service.
5. Set the health check to HTTP GET /health.
6. Deploy, then open the app URL and scan the QR code.

Koyeb's disk is ephemeral. That is fine here because the session and data live in MongoDB, but you do need MONGODB_KEY.

The button uses app.json and Procfile and asks for the required config vars. Heroku's default Node.js buildpack does not include Bun, but npm start runs bun index.js, so on the buildpack path you must add a Bun buildpack, or deploy as a container instead:

heroku stack:set container -a <app-name>

and add a heroku.yml that builds the Dockerfile (build: docker: web: Dockerfile). Heroku's filesystem is ephemeral and dynos restart daily, so MongoDB must hold the session. These Heroku files are older than the Docker setup; if the button fails, use Koyeb or Docker.

Issues and pull requests are welcome. Keep changes focused, run bun run lint and bun run fmt:check, and describe how you tested.

MIT, see LICENSE.

• Baileys

If you enjoy this project, please consider giving it a ⭐ on GitHub.