Nearly everyone searching for a self-hosted or on-premises WhatsApp API is doing it for one of two reasons. Either a compliance requirement says customer message content cannot sit on a third party's servers, or the per-message bill on a hosted platform has become indefensible.
Those are both good reasons. They also lead to different answers, and one of them has a much shorter path than people expect.
First, the thing that changed
The official on-premises WhatsApp Business API is gone. Meta announced its deprecation in October 2023 and ended support on 23 October 2025. New number registrations stopped before that with error code 1005, the final client version expired, and on-premises endpoints no longer deliver messages.
That matters because "on premise WhatsApp API" used to mean something specific and sanctioned: a Docker container Meta shipped, running inside your own network, connected to WhatsApp's infrastructure with Meta's blessing. Regulated organisations chose it precisely because message content never touched a vendor.
That option no longer exists. Meta's replacement is the Cloud API, which is hosted by Meta and only by Meta. There is no compliant on-premises deployment of the official WhatsApp Business Platform in 2026, at any price, for any customer. If you have inherited a codebase pointing at a self-hosted WhatsApp container, it stopped working, and the Cloud API comparison covers the migration path.
So when people say "self-hosted WhatsApp API" today, they mean something different: running the WhatsApp Web protocol yourself, on your own hardware, without a vendor in the middle.
What you are actually deploying
The architecture is the same as any session-based API, except you run the bridge.
A library authenticates as a companion device on WhatsApp's multi-device protocol, the same mechanism WhatsApp Web uses. It holds a WebSocket connection, persists the session credentials, and exposes HTTP endpoints. You scan a QR code once, and after that it is a REST API you own.
Be clear about what this does not change: automating a standard WhatsApp account this way is against Meta's terms of service regardless of whose server it runs on. Self-hosting solves a data residency problem. It does not solve a compliance-with-Meta problem, and no amount of infrastructure control converts an unofficial client into a sanctioned one. Any evaluation that treats self-hosting as the compliant option has the analysis backwards.
The projects worth evaluating
Baileys is the foundation most of this ecosystem sits on. A TypeScript implementation speaking the multi-device protocol directly over WebSocket, no browser involved. It is a library rather than a service, so you build the HTTP layer, the session store and the queueing yourself. Actively maintained, and its README is explicit that it is unaffiliated with WhatsApp and that the maintainers do not condone terms violations.
whatsapp-web.js drives a headless Chromium instance. Heavier on memory, occasionally more resilient to protocol changes because it is using the real web client, and simpler to reason about when something breaks.
WAHA wraps that capability in a documented, Dockerised REST API with a dashboard and a Swagger UI. Apache-2.0, and it offers three engines: WEBJS (browser-based), NOWEB (Baileys-style WebSocket) and GOWS (Go WebSocket). This is the most turnkey option in the category, and it changed significantly in 2026: from version 2026.6.1, the features that previously required a paid Plus subscription, including multi-session and media, ship in the free public image. The tiered Core/Plus/PRO structure was replaced with a symbolic community support tier. If you evaluated WAHA before mid-2026 and rejected it over the single-session limit, look again.
Evolution API is the integration-heavy choice, popular in the n8n and Typebot ecosystem. Apache-2.0 with brand-protection conditions attached, so read the licence rather than assuming standard Apache terms.
WPPConnect and CodeChat round out the field with similar trade-offs.
Whichever you pick, understand the maintenance model. These are community projects tracking an undocumented protocol that changes without notice. Star counts and recent commits are the closest thing to a reliability signal you have.
A deployment that will survive a reboot
The minimum viable Docker Compose, using WAHA as the example:
yaml
Four decisions in there are the ones that matter.
Bind to localhost, not 0.0.0.0. Put a reverse proxy with TLS in front. An exposed WhatsApp API on a public port is a way to lose a number to somebody else's script.
Persist the session volume. This is the single most common self-hosting failure. Session credentials live on disk, and if that volume is ephemeral, every container restart forces a fresh QR scan. Re-authenticating repeatedly is also a registration-layer signal that raises ban risk, so this bug costs more than inconvenience.
Back up sessions and encryption keys together. Restoring a database without the key that encrypts its credentials leaves you with unrecoverable data.
Plan storage for media. Inbound images and voice notes accumulate quickly. Set a retention policy on day one rather than discovering it when the disk fills.
For anything beyond a prototype, add PostgreSQL rather than the default file store, and put a queue in front of outbound sends so a burst does not go out at machine pace.
What actually breaks
Six months of running this yourself looks like the following.
Protocol drift. WhatsApp changes something internal, the library breaks, and you are down until the maintainer ships a fix and you deploy it. This is the defining operational risk of self-hosting and the reason most teams eventually leave. It happens without warning, usually at the worst time, and there is no support contract to invoke.
Session drops. Phones go offline, WhatsApp expires companion devices, containers restart. Build reconnection handling and alerting for session.disconnected before you need it, because a dropped session fails silently: sends queue, nothing errors loudly, and you find out from a customer.
Memory. Browser-based engines are heavy. Budget 1GB or more per session on WEBJS. WebSocket engines are far lighter. Ten sessions on a 2GB box will not work.
Webhook throughput. A single-process deployment handling triggers and executions together starts dropping events under bursty load well before CPU looks stressed. Queue mode with Redis is worth building in from the start rather than retrofitting.
Multi-session scaling. Managing three numbers is a config change. Managing thirty is a distributed systems problem involving session affinity, health checks and orchestration.
The GDPR argument, examined honestly
This is the real reason enterprises look at self-hosting, so it deserves precision rather than reassurance.
What self-hosting genuinely gives you. Message content and session credentials stay inside infrastructure you control. You choose the jurisdiction, so an EU-only deployment keeps processing within the EU and removes the international transfer question under Chapter V entirely. You set retention rather than accepting a vendor's. There is no third-party processor to assess, contract with or audit, which removes an entire Article 28 workstream. For organisations whose DPIA cannot get past "customer conversation content is stored by a third party," this is decisive.
What it does not give you. You are still the controller, and every obligation that attaches to that role remains: lawful basis, data subject rights, breach notification, records of processing. Self-hosting moves the processing, not the responsibility, and it makes you the processor too, which means your own security posture is now the thing being audited.
Nor does it remove Meta from the picture. Messages traverse WhatsApp's network. End-to-end encryption protects content in transit, but metadata (who messaged whom, when, from what device) is Meta's, and no deployment choice changes that. If your compliance position depends on Meta processing nothing at all, WhatsApp is the wrong channel, not the wrong hosting model.
And the terms of service point stands. A self-hosted unofficial client is still an unofficial client. A regulated organisation choosing this route is accepting a channel that can be terminated by the counterparty without appeal, which is a business continuity question your risk register should reflect.
The cost, counted properly
The pitch for self-hosting is that it is free. The licence is. Running it is not.
| Line itemRealistic monthly | |
| VPS, 2 vCPU / 4GB, few sessions | $20–40 |
| Managed PostgreSQL | $15–50 |
| Backups, monitoring, TLS | $10–30 |
| Engineering time, 4–8 hrs/month at $75/hr | $300–600 |
| Incident response when the protocol shifts | Variable, occasionally significant |
Infrastructure lands around $50 to $120. Engineering dominates, and the incident line is the one nobody forecasts.
Set that against hosted flat-rate session pricing in the $5 to $35 range for one to ten numbers, and the arithmetic is unkind unless one of two conditions holds: you are running enough sessions that per-session fees genuinely exceed a server, or a compliance requirement makes third-party hosting impossible at any price. Outside those, self-hosting is usually a decision to pay engineers instead of paying a vendor. The pricing breakdown has the comparison against per-message models, where the case for owning your own infrastructure is considerably stronger.
The middle option
There is a deployment shape between "hosted multi-tenant SaaS" and "your team owns a Docker Compose file": a dedicated instance, isolated from other customers, deployed and maintained by the vendor, in a region you specify.
You get the data isolation and residency control that drive most self-hosting decisions, and someone else absorbs protocol drift, patching and reconnection engineering. You give up root access and some configuration freedom.
WaHttp offers this as a dedicated deployment on Enterprise plans through JahaSoft, with custom integrations and an SLA. Specifics like region selection, deployment model and contractual terms are scoped per customer rather than published, so talk to us if that shape fits your requirements. If your blocker is genuinely "no third party may hold message content," a fully self-managed open source deployment is still the honest answer, and this section is not it.
Common Questions Asked by Users
Can I self-host the official WhatsApp Business API? No. Meta's on-premises API reached end of life on 23 October 2025 and no longer delivers messages. The Cloud API is hosted exclusively by Meta, with no on-premises deployment option.
What is the best open source WhatsApp API? WAHA is the most turnkey, being Apache-2.0, Dockerised and well documented, with paid-tier features folded into the free image from version 2026.6.1. Evolution API suits integration-heavy stacks. Baileys is the underlying library if you want to build your own service layer.
Does self-hosting make a WhatsApp API GDPR compliant? It solves data residency and removes a third-party processor, which is often the blocking issue in a DPIA. It does not make you compliant by itself: controller obligations, lawful basis and data subject rights all remain, and Meta still handles message metadata.
Can I choose where my WhatsApp data is stored? On a self-hosted deployment, yes, entirely. On hosted platforms it depends on the vendor, and dedicated deployments usually allow a region choice while multi-tenant plans usually do not. Ask before assuming.
How much server do I need? For a few sessions on a WebSocket engine, 2 vCPU and 4GB is comfortable. Browser-based engines need roughly 1GB per session, so size by engine and session count rather than by message volume.
Is a self-hosted WhatsApp API safer from bans? No. Ban risk tracks sending behaviour, not hosting location. A self-hosted deployment sending cold messages at machine pace gets restricted exactly as fast as a hosted one, and you lose the server-side pacing hosted providers apply by default.
What happens when WhatsApp changes its protocol? Unofficial clients break until maintainers ship a fix. Self-hosted, you own the outage and the upgrade. This is the main operational risk of the model and the most common reason teams migrate to a managed provider.