If you've landed on this comparison, you've probably already ruled out the official WhatsApp Cloud API — too much approval friction, template review, or per-message billing for what you're trying to do. So you're choosing between two products that both sit on top of the same unofficial, WhatsApp Web–based connection: WAHA, the open-source project you run yourself, and WaHttp, a hosted version of the same idea with a dashboard and support attached.
That's an important thing to get straight before comparing pricing pages: this isn't an "official vs unofficial" decision. Both tools connect as a linked device the same way WhatsApp Web does, both carry the same terms-of-service exposure that comes with any unofficial client, and neither can promise a ban-proof number. What actually differs between them is who owns the infrastructure, who patches it when WhatsApp changes something, and what happens to your time and money either way. We built WaHttp, so take the framing with that in mind — but we'd be doing you a disservice if we didn't say plainly where WAHA is the better call.
What WAHA actually is
WAHA (WhatsApp HTTP API) is an open-source project maintained by devlikeapro, distributed as a Docker image. As of this writing it sits at roughly 7,600 stars and 1,800 forks on GitHub, licensed under Apache 2.0 for the core image. You run it on your own server — a VPS, a container platform, or your existing Kubernetes cluster — and it exposes a REST API with a Swagger UI and a basic dashboard for scanning QR codes and watching session status.
Worth correcting here, because it trips people up: for a long stretch, WAHA split its features between a free "Core" image (capped at one session, no media sending) and a paid "Plus" image (unlimited sessions, media, external storage) priced around $19–99/month depending on the tier. Several third-party roundups and comparison sites still repeat those numbers. That split is gone. WAHA's own documentation now states plainly that there's "no separate 'Plus' image anymore," that multi-session support, media messages, and storage backends are available to everyone, and that the project runs on optional donations rather than license checks. If you're reading an article that cites a WAHA Plus price, you're reading something stale — check WAHA's own docs before budgeting around a number you found elsewhere, because this is exactly the kind of detail that goes out of date fast.
What doesn't change: you still provide the server. WAHA supports several underlying engines (WEBJS and WPP run a real browser instance per session; NOWEB and GOWS connect over WebSocket without a browser and use noticeably less RAM). You pick the engine, size the box, handle Docker upgrades when WhatsApp's protocol shifts underneath the library, and own backups of the session credentials sitting in your volume.
What WaHttp actually is
WaHttp is the same underlying idea — a linked-device connection exposed as clean REST endpoints — run as a managed service. You don't touch Docker or a VPS. Current plans run from $5/month for one session with unlimited messages, up to $35/month for ten sessions on the Agency tier, with a custom Enterprise option for dedicated deployments and an SLA. Every paid tier includes the dashboard, webhooks (signed and retried, covering message and session events), API keys with role-based access, and an MCP endpoint for wiring an AI agent straight into WhatsApp. There's a free trial (100 messages/day for 24 hours, no card) and a 14-day money-back guarantee on paid plans.
The pitch is straightforward: you get the session-based cost advantage over the Cloud API without becoming the person who gets paged when a container falls over at 2 a.m.
The real cost comparison
"WAHA is free" is true and also the wrong way to think about it, because the software cost was never the expensive part. Running WAHA in production means a VPS (realistically $20–40/month for a handful of light sessions, more as you add WEBJS browser instances), a database if you want sessions to survive a restart ($15–50/month for managed Postgres), backups, monitoring, and TLS ($10–30/month), and — the part people underprice — the engineering time to actually keep it healthy: patching the image when WhatsApp's protocol drifts, re-pairing sessions that silently drop, and watching memory on browser-based engines, which commonly run 1GB+ of RAM per session. Even a conservative 4–8 hours a month at a $75/hour blended rate is $300–600. Put together, a small self-hosted WAHA deployment realistically lands somewhere around $50–120/month in infrastructure alone, before you count the time.
Against that, WaHttp's $5–35/month flat tiers look inexpensive almost by default — because you're not paying for infrastructure or your own ops time, you're paying for someone else to carry both. Where WAHA wins the cost argument is at real scale with in-house ops capacity already in place: a team running 50+ sessions that already operates Docker and Postgres for other services can likely run WAHA at a lower marginal cost per session than any hosted tier, because the heavy fixed costs (the ops person, the cluster) are already sunk. If you're starting from zero infrastructure for one to ten numbers, that math doesn't hold — you'd be standing up a server, a database, and monitoring to save a few dollars a month against a $5–35 flat fee.
Control and data residency
This is the category where self-hosting has a genuine, non-marketing advantage. With WAHA on your own server, session credentials, message content, and media never leave infrastructure you control. If your compliance team has a hard requirement that no third party ever holds WhatsApp session data — healthcare, finance, or anything under strict data-residency rules — self-hosted WAHA (or any of the open-source alternatives) is the honest answer, not a hosted product from us or anyone else. We said this plainly in our own self-hosting write-up and it's still true here: hosting WAHA yourself moves the processing, not Meta's visibility into message metadata, but it does remove the hosting vendor from the chain entirely.
With WaHttp, session credentials and message payloads pass through our infrastructure to deliver the dashboard, webhooks, and inbox features. For most use cases — order notifications, OTPs, support inboxes, internal alerting — that tradeoff is a non-issue in exchange for not running servers. For a regulated use case where "no third party, period" is a contractual requirement, it's a real reason to self-host instead.
Ban risk and protocol maintenance
Here the two are functionally identical, and it's worth being direct about that rather than implying otherwise. Both WAHA and WaHttp connect as a linked device over the same reverse-engineered protocol that every unofficial WhatsApp client uses. WhatsApp's terms of service don't carve out an exception for either one, enforcement looks at the same signals on both (send velocity, reply ratios, block/report rates, how "fresh" the number is), and WhatsApp publishes no official rate limit for linked devices — the "a few dozen messages a minute" figure you'll see repeated everywhere is a community rule of thumb, not a documented threshold. If you want the deeper mechanics and mitigation steps, see our dedicated guide: How to Avoid a WhatsApp Number Ban.
The one place this diverges slightly is protocol maintenance speed. WhatsApp changes its internal protocol without notice periodically, and when that happens, an unofficial client needs a patch. On WAHA, that's on you — you watch the repo, wait for a release, and redeploy. On WaHttp, that patch is our job, and it ships without you doing anything. Neither reduces your underlying ban exposure; the difference is purely in who's responsible for keeping the client working when WhatsApp moves the ground.
Vendor lock-in
WAHA's biggest structural advantage: it's Apache-2.0 licensed and runs anywhere that runs Docker. If you decide tomorrow you want to move from one VPS provider to another, or bring it in-house, there's no vendor relationship to unwind — you own the deployment outright. That's a real form of independence that a hosted product, by definition, can't fully match.
WaHttp's answer to lock-in is to keep the interface itself boring and portable: plain REST endpoints, standard webhook payloads, no proprietary SDK you'd have to rewrite around. If you outgrow us or want to self-host later, your integration code — the part that calls an HTTP endpoint and reads a JSON webhook — doesn't need to change much regardless of which session-based backend sits behind it. That's a mitigation, not a replacement for the fact that your sessions live on someone else's infrastructure while you're on the platform. If avoiding any vendor dependency at all is the priority, WAHA is the more honest fit.
Which one should you actually run?
If you have, or are willing to build, in-house ops capacity (someone comfortable with Docker, backups, and watching a server); you're running at a scale where infrastructure cost beats a flat per-session fee; or you have a hard data-residency requirement that rules out any third party touching session data — self-host WAHA. It's free, actively maintained, and that recent move to drop the Plus paywall only makes the case stronger.
If you want the session-based cost advantage without taking on server ownership, patching, or 2 a.m. pages; you're running one to ten numbers and want to be sending messages within minutes instead of days; or you want webhooks, roles, and an MCP endpoint without building them yourself — that's the gap WaHttp is built to fill. For context on how both stack up against the official route on cost specifically, see our breakdown of WhatsApp Cloud API vs. Session-Based APIs, and if you're evaluating WAHA against other self-hosted projects rather than a hosted one, our Evolution API vs. WAHA comparison covers that ground.
Plenty of teams land on a hybrid, too: self-host WAHA for a core, high-volume number where the ops investment pays for itself, and run a hosted tier for lower-volume or one-off numbers where standing up infrastructure isn't worth it. Both tools speak close enough to the same REST shape that running both isn't the operational headache it might sound like.