Baileys vs WAHA: Library or Service? (Decision Guide)

Here is the thing that reframes this whole comparison: WAHA's NOWEB engine is built on a fork of Baileys. WAHA's own engine documentation links it as github.com/devlikeapro/Baileys. So "Baileys vs WAHA" is not a choice between two ways of talking to WhatsApp. In one configuration, WAHA is Baileys, with an HTTP layer, a dashboard and a Docker image wrapped around it.

That changes the question. You are not picking a protocol. You are picking how much of the surrounding machinery you want to build yourself.

What Baileys gives you

Baileys is a TypeScript library, MIT licensed, with around 11,000 stars and an active maintainer in Rajeh Taher under the WhiskeySockets organisation. It connects to WhatsApp's multidevice protocol directly over WebSocket, with no browser involved, which is why it uses a fraction of the memory that Puppeteer-based libraries need per session.

What it gives you is function calls and an event emitter. What you write yourself is everything between those and a working system: an HTTP layer if your app is not Node, webhook delivery with retries if other services need to react to messages, session persistence and recovery, and the orchestration to run more than one number at once. That is not a criticism. A library is supposed to stop there.

Two practical notes before you commit. Version 7.0.0 introduced multiple breaking changes with a migration guide, so pin your version and read that guide before upgrading. And the project's documentation is openly described as a work in progress, with the older README still linked alongside it, so expect to read source occasionally. Our Baileys alternative comparison covers how it stacks up against the other libraries in this category if you are still deciding at that level.

What WAHA gives you

WAHA is a self-hosted WhatsApp HTTP API, Apache-2.0 for its Core edition, with around 7,600 stars. One docker run gets you a REST API on port 3000, interactive Swagger docs and a dashboard. Sessions are created with a POST, the login QR comes back from a screenshot endpoint, and sending a message is a POST with a chat ID and text. That is the layer Baileys deliberately leaves to you, already built.

It also abstracts the engine underneath. WAHA ships four: WEBJS and WPP, which drive a real Chromium through Puppeteer, and NOWEB and GOWS, which talk WebSocket directly using the Baileys fork and a Go library respectively. WEBJS is the default. The browser engines are heavier per session, the WebSocket engines are lighter and scale further on the same hardware.

One important caveat on that flexibility: WAHA's documentation warns that API responses and webhook payloads can differ significantly between engines. Pin one engine, build against it, and retest properly before switching. The engines are not drop-in replacements for each other.

The WAHA limit that catches people out

"Free and open source" does a lot of work in how WAHA gets described, and it is true of the Core edition. It is also worth knowing exactly where Core stops.

By one 2026 review of the project, Core gives you a single session, sends text, location and contacts, supports webhooks, and includes all four engines, with local file storage only. Media sending — images, voice, video, files — is reported as a paid feature, as is running more than one session, as are the PostgreSQL, MongoDB and S3 storage backends. The paid Plus edition is reported at around $19 a month and a PRO edition at around $99 with source access and team seats.

Treat those figures as indicative rather than confirmed. They come from a third-party write-up whose publisher sells a competing hosted API, and WAHA's own pricing path redirects to a support page that is excluded from search indexing. Check the current terms with the project directly before you budget. But the shape of the limit matters for the decision: if your use case needs media or a second number, the free tier will not carry you, and the comparison becomes Baileys-at-zero-cost against WAHA-at-a-subscription.

Choosing between them

Choose Baileys if your stack is already Node or TypeScript, you want no licence cost at any scale or session count, you need protocol-level control that a REST abstraction would hide, or you are building a product where the WhatsApp layer is core enough that owning it is worth the engineering. You will write the HTTP and webhook layers yourself, and you will maintain them.

Choose WAHA if your application is not written in Node, you want a REST API and Swagger docs today rather than after a sprint of plumbing, you value being able to switch engines when one breaks, and you are either within Core's single-session text-only envelope or happy to pay for Plus. Our WAHA alternative breakdown goes further into where its model fits and where it starts to chafe.

Choose neither if you did not actually want to run infrastructure. Both options leave you owning a server, session storage, uptime and the work of patching when WhatsApp shifts its protocol. A hosted flat-rate API removes that entirely: WaHttp, ours, is $5 a month for one session with unlimited messages up to $35 for ten, with REST endpoints and webhooks on every plan and no media restriction. The honest trade is that you give up infrastructure control and the ability to self-host for compliance reasons. Our self-hosted WhatsApp API guide sets out what running your own actually involves, so you can price that work before assuming free is cheaper.

Side by side

What neither one changes

Both connect as linked devices through WhatsApp's web protocol, outside Meta's official Business Platform. That exposure is identical whichever you choose, and wrapping a library in a REST API does nothing to alter how WhatsApp's enforcement systems read your account.

Baileys' own maintainers are unusually direct about this. The project states it does not condone use that violates WhatsApp's Terms of Service, tells users to proceed at their own discretion, and explicitly discourages bulk messaging, automated messaging and stalkerware. A WAHA review makes the same point from the other side, noting that WhatsApp publishes no official rate limit for linked devices, so the sending thresholds circulating in the community are heuristics rather than documented ceilings. Plan your pacing on that basis, and do not treat either tool's existence as permission.

Practical notes if you switch between them

Moving from Baileys to WAHA is mostly deletion: your send calls become HTTP POSTs and your event handlers become webhook endpoints, and the session management code you wrote comes out. Pick NOWEB as the engine if you want the closest behavioural match to what you had, since it is the Baileys fork.

Going the other direction is more work, because you take on everything WAHA was doing. Note also that NOWEB stores nothing by default, so the endpoints for listing contacts, chats and messages need the store switched on, and store settings should not be changed after pairing. History depth is governed by a full-sync setting, roughly three months when off and up to about a year when on. If you have been relying on WAHA's stored history, confirm what you actually have before you move it.