Evolution API vs Baileys: Wrapper or Raw Library?

Evolution API's default WhatsApp Web connection runs on Baileys underneath. That single fact reframes the whole comparison. You are not choosing between two different ways of talking to WhatsApp's protocol. In its default mode, Evolution is Baileys, wrapped in a REST API, a database layer and a dashboard. The real question is how much of that wrapping you want, and what it costs you to have it built in rather than built by you.

What Baileys gives you

Baileys is a TypeScript library, MIT licensed, maintained under the WhiskeySockets organisation with around 11,000 stars, 3,400 forks and roughly 293 open issues against 46 open pull requests. It connects to WhatsApp's multidevice protocol directly over WebSocket, with no browser and no database requirement baked in. You get function calls and an event emitter.

What you build yourself is everything between that and a deployable system: an HTTP layer, webhook delivery with retries, session persistence through whatever auth-state storage you choose, and orchestration if you are running more than one number. None of that is a flaw. A library is supposed to stop there, and our Baileys alternative comparison covers how it stacks up against the rest of the category if you are still deciding whether a raw library is the right starting point at all.

What Evolution API adds on top

Evolution takes that same Baileys connection and wraps it in a REST API with API-key auth, webhook signature validation, a management UI, and — this is the part that actually distinguishes it from every other Baileys wrapper in this category — the option to run instances against Meta's official Cloud API instead of the unofficial route, through the same API shape. Baileys cannot do that. Neither can WAHA. If you want the flexibility to run some numbers unofficially and others through Meta's sanctioned platform without maintaining two separate integrations, Evolution's dual-mode support is the one capability here that a raw library, however well-built, cannot replicate.

Beyond that, Evolution ships native integrations for Typebot, Chatwoot, n8n, Dify and OpenAI's audio-to-text, plus event streaming through RabbitMQ, Kafka, SQS, NATS, Pusher or Socket.io, and storage through S3 or MinIO. Baileys gives you events; Evolution gives you configuration where you would otherwise write connector code by hand.

The cost of that convenience: infrastructure weight

Baileys needs an auth-state store, and that is a choice you make yourself, down to a single JSON file for a prototype if you want. Evolution requires PostgreSQL for instances, messages and history, Redis for cache and session state, and a persistent volume for authentication data, with Prisma migrations run on boot. A missing migration table stops the server outright. High-throughput setups add RabbitMQ, Kafka or SQS on top of that. You are trading a storage decision for a four-to-six-service stack, with the backup, monitoring and failure modes that come with each piece of it.

Licensing, and where v2.4.0 actually stands today

Baileys is MIT, with no conditions beyond preserving the copyright notice.

Evolution is Apache-2.0 with added brand-protection conditions, and the activation requirement widely discussed for v2.4.0 is worth stating precisely rather than from memory. As of this writing, Evolution's latest stable release is still v2.3.7; version 2.4.0 sits at release-candidate stage (2.4.0-rc2), explicitly marked for validation rather than production use. The rc1 notes describe the change plainly: once 2.4.0 ships as stable, every instance must activate against Evolution Foundation's licensing server before serving API traffic, returning an HTTP 503 with LICENSE_REQUIRED until it does. The rc2 notes add a headless activation path using a registered operator email, as an alternative to the manual flow through the manager UI.

So if you deploy Evolution today on the stable tag, you are not yet hitting the activation wall. But it is coming, it has already reached a second release candidate, and pinning to 2.3.7 indefinitely to avoid it means giving up fixes on a codebase tracking an undocumented, frequently-shifting protocol. Our Evolution API alternative post goes deeper into that trade-off and what it looks like to migrate off Evolution entirely if the activation requirement is a dealbreaker for you.

Maturity signals

Reading both repositories directly: Baileys sits at roughly 11,000 stars, 3,400 forks, 293 open issues and 46 open pull requests. Evolution sits at roughly 9,900 stars, 7,300 forks, 158 open issues and 82 open pull requests, maintained by the Evolution Foundation. Evolution's higher fork count is a reasonable signal of people actually running their own customized deployments, which tracks with it being the heavier, more infrastructure-oriented project of the two. Neither issue count should be read as a quality verdict on its own, since tracker size reflects triage habits and userbase as much as defect rates.

Choosing

Choose Baileys if you want the lightest possible footprint, you are comfortable owning the HTTP layer and session storage yourself, MIT's lack of any conditions matters to you, and you do not need official Cloud API support in the same deployment.

Choose Evolution API if you specifically need the option to run Meta's official Cloud API alongside unofficial instances, you already use Typebot, Chatwoot, n8n or Dify and want native hooks instead of hand-written webhooks, and you are comfortable operating a Postgres-and-Redis stack or pinning to 2.3.7 to defer the activation requirement.

Choose neither if you did not want to own a server, a database and a patching schedule in the first place. Both options leave that work to you regardless of which one you pick. A hosted flat-rate API removes it: WaHttp, ours, is $5 a month for one session with unlimited messages up to $35 for ten, with REST endpoints and webhooks included and nothing to deploy. Our self-hosted WhatsApp API guide prices out what running either option actually costs in infrastructure and engineering time before you commit to either one.

Side by side

What neither one changes

In its default unofficial mode, Evolution connects exactly the way Baileys does, as a linked device outside Meta's official Business Platform, carrying the same terms-of-service exposure. Baileys' maintainers are explicit that they do not condone use violating WhatsApp's terms and discourage bulk or automated messaging; that exposure does not shrink because a REST layer and a database sit on top of the same connection. Evolution's one way out of this is its official Cloud API mode, which is Meta's sanctioned platform rather than a linked-device client. If compliance is the deciding factor, that single mode is the whole decision, independent of anything else in this comparison.

If you switch between them

Moving from raw Baileys to Evolution is mostly subtraction: your send calls become REST requests, your event handlers become webhook endpoints, and the session code you wrote comes out, replaced by whatever Evolution's instance and database layer handles instead. Moving the other direction means taking that work back on yourself, plus rebuilding anything you had wired into Evolution's native integrations as direct Baileys event handling. Either way, confirm which licence tier and version you are migrating to before you start, since the activation requirement changes the calculus of staying current on Evolution going forward.