A decision that looks technical but is really a business one
Connecting the first number on your own server takes an afternoon. A container, a QR code and the message goes out. The doubt shows up months later, when the product has eighty customers and each one has their own WhatsApp. At that point the question stops being "does it work?" and becomes "who wakes up when it goes down?".
There are serious, well-maintained open source projects for this, and they solve the protocol. What they do not solve is operations: keeping dozens of connections stable, isolated and observable, every single day. That is the part that decides between hosting it yourself and using a managed WhatsApp API.
Total cost: what goes into the bill
The server price is the smallest line. The table below lists what tends to show up as the operation grows, without numbers, because they depend on your scale and your team's cost.
| Item | Self-hosted | Managed |
|---|---|---|
| Servers | Your cloud provider; grows with the number of connections | Included |
| IP per connection | Buy, rotate and replace proxies | Included on D-API: each connection gets a dedicated IP |
| Monitoring | Build alerts for dropped connections, queues and errors | Connection status through the connection.status event |
| Reconnection | Your own scripts and manual intervention | Continuous self-healing |
| WhatsApp changes | Track releases, update, test, deploy | The vendor's responsibility |
| On-call | Someone on your team on standby | Vendor support |
| Isolation between customers | Depends on how you designed it | Each connection runs isolated, with its own credentials and webhook |
| Billing | Infrastructure cost plus team hours | Per connection, not per message (see pricing) |
The line that weighs the most almost never makes it into the spreadsheet: the engineering hours spent keeping connections alive instead of improving the product. For a SaaS, keeping WhatsApp up is not a differentiator; it is work the end user never sees.
What is actually hard about self-hosting
Reconnection and dropped sessions
WhatsApp connections drop: the phone gets replaced, the session is logged out from the phone, the protocol changes. Every drop needs to be detected, and every lost session means telling the customer to scan the QR code again. Without that, the customer finds out on their own, usually when an important message did not go out.
The domino effect
When every connection runs in the same process and goes out through the same IP, one badly behaved number can hurt the others, and a memory leak takes everyone down together. Isolating per connection fixes it, but it is infrastructure engineering that someone has to build and maintain.
Protocol updates
WhatsApp changes without notice. Open source projects tend to react quickly, but the update still has to reach your environment: read the changelog, roll it out to staging, test sending and receiving, and deploy without dropping active sessions.
Webhooks that cannot get lost
If your receiver goes down for a minute, someone has to resend that minute's events. On D-API, delivery is retried up to 7 times with exponential backoff; when self-hosting, that logic is yours. The details are in WhatsApp API webhooks.
When self-hosting makes sense
- Regulatory or contractual requirements that no data can pass through third-party infrastructure.
- Small, stable volume: a few internal numbers, with no customers depending on them.
- An infrastructure team with spare capacity and experience running stateful services.
- A need to customize the library's internal behavior beyond what an API exposes.
When managed pays off
- Each of your product's customers has their own number, and one going down becomes a support ticket.
- Your product team is small, and every sprint spent on infrastructure delays the roadmap.
- You need to provision connections through the API, with no manual process. See multiple numbers.
- You want the option to use the official WhatsApp API (Meta Cloud API) later without rewriting the integration. On D-API, official and unofficial use the same call format.
A checklist to decide
- How many connections will you have in 12 months?
- What does an hour of your engineering team cost, and how many hours go to WhatsApp each month today?
- What is the impact on your customers of WhatsApp being down for an hour?
- Is anyone on the team willing to be on call for it?
- Is there a requirement that rules out third-party infrastructure?
If the answers point to growth and a team with little slack, the next comparison is price. Start with WhatsApp API pricing and, if you run a product with many customers, the WhatsApp API for SaaS page.