WA-AKG: a self-hosted WhatsApp gateway on Baileys

The gateway sits between your code and WhatsApp

WA-AKG is a self-hosted WhatsApp gateway and dashboard, and the architecture diagram in the readme is the whole design in one picture.

A user or an application calls the REST API, the API layer of the gateway hands the request to the messaging engine, the engine talks to the WhatsApp server, and the data goes to the database in real time. In the other direction, events from WhatsApp come back as webhooks, and the gateway forwards them to an external system such as a CRM or another API.

The feature list fills in what that means in practice. Multi-session management connects and manages unlimited WhatsApp accounts simultaneously through QR code scans, so one deployment can be the phone number for support, another one for order updates and a third for a particular tenant, and each keeps its own session. The Pro WhatsApp Engine is powered by the Baileys library for what the readme calls high-speed, stable and secure WebSocket connections.

The product also includes a set of things that are not about the transport at all. An advanced scheduler does message planning with media support for images, video and documents. A smart auto-reply matches keywords with context support for group, private or all, and can attach media. Contacts are handled with LID, verified names and profile pictures. There is a sticker maker with background removal through a third-party service. And the whole thing is a REST API with 109 or more documented endpoints and an OpenAPI description served through a Swagger interface at the docs path.

The project is MIT licensed, its primary language is TypeScript, and the release history is 1.7.0 on 2026-10-19 with two betas before it, and the last push to the repository on the same day.

The engine is pinned to a release candidate

One line in the dependency list tells you the most about the risk in this project, and it is the WhatsApp engine.

The dependency is @whiskeysockets/baileys at 7.0.0-rc14, and it is pinned exactly rather than with a caret. Every other dependency in the manifest uses a range, so this one is deliberately frozen on a specific release candidate build.

That is a sensible thing to do and it comes with a caveat. A release candidate is a build that can still change, and the whole gateway sits on top of it, so a change in the engine's behaviour shows up as a change in your messaging. Pinning it means the deployment does not break on its own, which is the right trade for a self-hosted system, and it also means the upgrade is a deliberate act.

The rest of the dependency list is a normal modern application stack. Next at 16.1.1 with React, Prisma and its client for the database, the Radix UI primitives with Tailwind and the typography plugin for the interface, next-auth for authentication, next-intl for the translations, lucide-react for the icons, date-fns and moment with moment-timezone for the scheduler, node-cron and cron-parser for the cron expressions, bcryptjs for the password hashing, jimp for the image work, and a client for the background removal service.

Two versions are worth noting for a reader deciding whether to deploy. Next-auth is at a 5.0.0 beta, so the authentication layer is also on a pre-release, and the scheduler carries both moment and date-fns, which is duplication rather than a decision.

The scheduler, the auto reply and the broadcast queue

Three features do the day to day work of the gateway, and each one has a specific mechanism worth naming.

The scheduler is precise message planning with media support, so a message can carry an image, a video or a document and be sent at a chosen time. It is built on node-cron with cron-parser for the expressions and moment with moment-timezone for the time zones, which is the part that matters for a business that schedules across regions.

The auto-reply is keyword matching with context support, so a rule can apply to group chats, to private chats or to all of them, and the reply can carry media attachments. Alongside it there is granular access control, with whitelist and blacklist support for both bot commands and auto replies, which is how you stop a keyword rule from firing for a particular number.

The broadcast is the one to read the wording of carefully, because the readme describes it as safe broadcast with built-in anti-ban mechanisms and randomised delays of ten to thirty seconds plus batch processing. In practice that means the outbound messages are spread over time and sent in batches rather than in one burst. That is rate limiting by another name, and it exists because the transport underneath will throttle an account that sends too much too quickly.

The webhook payload example in the readme shows what comes back, with an event type of message.received, a session identifier, an ISO timestamp, and a data object holding the key with the remote JID, a fromMe flag and the message identifier, the sender in LID form, a type of TEXT and the content, an isGroup flag, and a quoted message with its own type, caption and media URL. The presence of the quoted block is what makes a webhook useful for a customer service tool, because the reply context survives.

Access control, webhooks and a hundred and nine endpoints

The readme claims a comprehensive OpenAPI and Swagger guide for all 109 or more endpoints, with the specification served through swagger-ui-react at the docs path, and there is a Swagger file at the root of the repository.

The API quick reference is the part that tells you whether this is usable, because it promises ready to use cURL and JavaScript snippets for instant integration. And the master project documentation covers the architecture, the database and the logic flow.

The webhook side is described as enterprise grade, with real-time event forwarding for messages, connections, status changes and group updates. That list is the interesting part, because a connection event is what tells an external system that a session dropped, and a status change is what tells it that a message was delivered or read. A gateway that only forwards inbound messages gives you half of what a business integration needs.

The access control model is short and worth spelling out. Whitelist and blacklist support applies to both bot commands and auto replies, so a number can be blocked from triggering a command while still being able to receive broadcasts, and the rules are set in the dashboard rather than in configuration files.

There is also an environment variable guide described as a configuration and security guide, which is where the session handling, the auth secret and the port live, and an internationalisation guide for the dashboard languages.

Three dashboard languages and a first class n8n integration

Two things in the readme stand out as the project trying to be more than a personal tool.

The first is the interface. The dashboard is available in English, Bahasa Indonesia and Portuguese from Brazil, with a built-in language switcher, and the internationalisation guide explains how the languages work and how to add or translate one. The mechanism is next-intl, and the test script in the package manifest runs the internationalisation tests specifically, which is the detail that suggests the translations are treated as something that can break.

The second is the n8n integration, and it is described as native support with official community nodes published to npm as n8n-nodes-wa-akg. There are two of them. The action node gives full control over messaging, groups, sessions, contacts and labels from inside a workflow, and the trigger node catches the real-time webhooks, such as a message received or a group joined, and starts a workflow.

That combination is what makes the gateway usable without writing code against the REST API at all. A team that already runs its automations in n8n can build the whole thing as a workflow, with the gateway handling the WhatsApp side and n8n handling the business logic, and the trigger node means the workflow reacts to events rather than polling.

The rest of the feature list is aimed at the dashboard, contacts with LID and verified names, a sticker maker with background removal through the remove.bg service, and the session management that lets one deployment hold several numbers.

Prisma, either database, and a PM2 process in production

The installation section is a conventional Node deployment with one twist, and the twist is that the server entry point is not the Next.js one.

The prerequisites are Node.js 20 or newer with 22 recommended, MySQL or PostgreSQL, Git, and PM2 installed globally. The setup is a clone, an install, a copy of the environment file, and then the two commands that matter:

# Push schema and generate Prisma Client
npm run db:push

# Create SuperAdmin account
npm run make-admin [email protected] password123

The first pushes the schema and generates the Prisma client, and the second creates the first administrator.

The development script is npx tsx src/server/index.ts rather than next dev, and the production start script runs the same entry point with NODE_ENV set to production. So the server is a TypeScript program that tsx executes, and the Next.js build is the front end and the API routes, which are then served by that entry point. The two are built separately and run together.

For production the readme recommends PM2, so the application restarts if the server reboots or crashes, and it offers two ways to do it. The automatic one is a start.sh script that checks the configuration, installs the dependencies, syncs the schema, compiles the production assets and starts or reloads PM2. The manual one is npm run build followed by the PM2 start with the ecosystem.config.js file, which is at the root of the repository.

There is also a Dockerfile and a docker-compose.yml, so a container deployment is possible, and the environment example file is the reference for what has to be set.

A 1.7 release, a beta branch and a repository that shows its work

The release history says this is an active project rather than a maintained one. Version 1.7.0 was published on 2026-10-19, the second beta of the same version an hour and a half earlier, and the first beta on 2026-09-21, with the last push to the repository on 2026-10-19.

The readme also points at a beta branch and at the pre-releases, with a tip saying that if you are looking for the latest features, check the beta branch or the pre-releases for experimental sources. So the project publishes stable and experimental lines side by side, and the experimental one is where a new Next.js or a new Baileys lands first.

The repository tree is worth a look, because it shows a working project rather than a curated one. There is a swagger.json, a components.json for the component library, a set of route listings in actual_routes.txt and all_routes.txt, a tmp-missing-APIs.txt, and several logs that were committed by accident, ts_errors.log, ts_errors_utf8.log, eslint-errors.txt and lint_output.txt. There are also small test scripts at the root, test-media.js, test-message.ts, test-prisma.js and test_db.ts, which are the kind of scratch files a developer writes to poke at a running system.

The scripts directory holds the administrative tasks, and the setup-admin script behind npm run make-admin is in there. The docs directory holds the user guide, the API documentation, the quick reference, the database setup, the project documentation, the environment variables and the internationalisation guide, and the prisma directory holds the schema.

So the project is documented like a product and committed like a working repository, and both of those are reasonable for something self-hosted that people are expected to run and extend.

Editorial conclusion

WA-AKG fits a team that has a business workflow to run over WhatsApp and wants to own the deployment, because the gateway exposes a documented API for messaging, groups, sessions, contacts and labels, and the dashboard, the scheduler and the webhook forwarding live in the same application. It is the wrong choice if you only need to send the occasional message, because there is an account linking step, a database and a process manager in the way, and it is the wrong choice if you need a supported platform rather than a library that talks to WhatsApp over the web protocol, since the engine is a release candidate build of Baileys. Before you deploy it, read the environment variable guide for the configuration and security settings, decide where the sessions and the media live, and check what the auto reply and broadcast features are allowed to do under WhatsApp's own terms.

Frequently asked questions

Official sources

1. License: MIT
2. mrifqidaffaaditya/WA-AKG on GitHub
3. Project website
4. README
5. Releases