Self-hosted Evolution API or WAHA vs a managed WhatsApp API: the real cost (TCO)

TCO (total cost of ownership) is everything you pay to keep the channel working over a period, not just the visible monthly fee. With open source software the license line is zero, and the bill moves to other lines: infrastructure, engineering time, risk and opportunity cost.

The most common mistake is to compare a zero license with the price of a managed service and conclude that self-hosting is free. The code is free. The server that runs 24 hours a day, the database, the backups, the updates when WhatsApp changes and the person who wakes up when the session drops all cost money, even when that cost is hidden inside someone's salary.

Checked on October 27, 2026. The WAHA website (waha.devlike.pro) states the project is free and open source, with no message limit, no time limit and no license expiry. The official Evolution API repository (github.com/EvolutionAPI/evolution-api) shows an Apache 2.0 license with extra brand-protection conditions, and lists Node.js 20 or later, PostgreSQL or MySQL, and Redis recommended for caching, with a Docker image available.

Evolution API connects in two ways: through a WhatsApp Web based session (Baileys), which the project describes as free and possibly limited compared with official options, and through Meta's Cloud API, which requires following Meta's policies and may charge per message. So Meta's cost still exists if you use the official mode, wherever the tool is hosted. Current billing rules are in WhatsApp Business API: costs and paths.

For a project by project comparison, see ZapZap vs Evolution API and ZapZap vs WAHA, which carry the sources for each.

Build the comparison by lines, not by impression. The table below lists what usually goes into the TCO of each model. The values are yours: fill them in with what you pay today.

The last line deserves emphasis: hosting or buying does not change the ban risk of the number, because it comes from unofficial use and your sending behavior, not from where the server sits. Anyone who sells the opposite is promising something they do not control. See anti-ban for WhatsApp.

Use this monthly formula for the self-hosting path: TCO = server + database and Redis + backup + (maintenance hours per month x hourly value) + expected cost of downtime. For the managed path: TCO = (number of instances x price per instance) + (integration hours per month x hourly value).

Practical steps: 1) count how many numbers you will have in 6 and in 12 months; 2) ask whoever runs infrastructure for an honest estimate of hours per month on updates, session drops and team support; 3) multiply by the hourly value, using the full cost of the professional, not just the salary; 4) estimate what an hour of channel downtime costs your operation (lost sales, stalled support); 5) add it up and compare over the same horizon.

At ZapZap the price is R$15 per active number per month, prepaid, with no per-message charge; the current value is on the pricing page. For the official Meta side, the API cost calculator uses the official rate in Brazilian reais, with the check date visible, and compares it against your volumes.

Self-hosting tends to win when you already have an infrastructure team with spare capacity, when a contract requires data to stay in your own environment, when you want to change the project's code, or when you run many numbers and can automate operations. In those cases the marginal cost of one more instance is small and control is worth it.

It also fits experiments and study: spinning up a test instance on a small server is a great way to learn how WhatsApp Web behaves. Just do not confuse a lab with serving customers.

The managed option tends to win when nobody in the company wants to be on call for the connection, when the team is small and each engineering hour is worth more than the price difference, when you need to start today, or when the operation depends on a stable channel to serve customers. Paying per number fixes the cost and turns the rest into forecasting.

There is also the vendor's scale effect: whoever runs many sessions has already hit the reconnection, queue and webhook problems you would face alone. The trade-off is depending on a third party and accepting the product's limits. If that bothers you, self-hosting is a legitimate answer.

Because the integration layer of both is HTTP with webhooks, you can start on the managed API, measure real volume for a few months and only then decide whether to bring it in-house. Write your code against a thin layer, with the base URL and keys in environment variables, and switching stays cheap.

The reverse works too: anyone who self-hosts and tires of being on call can move numbers to a managed API. Either way, every reconnected number needs a new QR code scan, so plan a window and warn the support team. Before deciding, test the managed API with a secondary number, using the welcome credit (no deposit, one per phone, after verifying the phone).