WAHA vs OpenWA — engine choice and OCI feasibility
Status: decision input, not a decision. Written 2026-10-08 at session exit. Question raised: WAHA looks better for multi-account work; is it feasible and how does it scale on Oracle Cloud (OCI)?
1. "Multiple agents" — what WAHA actually offers
WAHA's multi-account feature is sessions, not agents. There is no "agent" concept in the
WAHA API; the route surface is /api/sessions/*. If the intent is several AI agents each
driving their own WhatsApp account, WAHA sessions are the right primitive — but the agent
layer is yours to build (an n8n/Hermes worker per session, keyed by session name).
Worth separating two things that look alike:
| Want | Mechanism |
|---|---|
| N WhatsApp accounts, one control plane | WAHA sessions (one container, many accounts) |
| N agents, each with isolated access | One session per agent + per-agent API key/scope on your side |
OpenWA also does multi-session, so this is not a WAHA-exclusive capability. The real differentiators are the engines (§2) and the licence (§4).
2. Engines — the actual reason to prefer WAHA
WAHA ships four engines behind one API. The engine, not the wrapper, decides cost:
| Engine | Mechanism | Browser | RAM cost |
|---|---|---|---|
| WEBJS | whatsapp-web.js | Chromium | ~650 MB/session (measured, see §3) |
| WPP | wppconnect | Chromium | same class as WEBJS |
| NOWEB | Baileys (Node) | none | ~25 MB/session (measured, see §3) |
| GOWS | whatsmeow (Go) | none | cheapest; Go, low overhead |
This is the decisive capability. OpenWA also ships both a Chromium engine and a Baileys
engine (ENGINE_TYPE=baileys|webjs) — so the engine choice exists on both sides. WAHA's
advantage is GOWS (a third, browserless, Go implementation) and a published scaling model.
Published WAHA scaling (from WAHA docs)
| Sessions | WEBJS | NOWEB | GOWS |
|---|---|---|---|
| 10 | 3 CPU / 2.5 GB | 1 CPU / 2 GB | 0.5 CPU / 1 GB |
| 50 | 15 CPU / 20 GB | 2 CPU / 4 GB | 1.5 CPU / 3 GB |
| 500 | (not advised) | 3 CPU / 30 GB | — |
GOWS is ~5× cheaper than NOWEB and ~30× cheaper than WEBJS per session.
Source: waha.devlike.pro/docs/overview/faq + the "500+ sessions" scaling post.
3. What we measured locally (OpenWA, this workstation, x86_64)
Session at qr_ready, engineLoaded: true, engine actually loaded — not an empty container:
| Engine | avg | peak | procs | baseline before session | delta |
|---|---|---|---|---|---|
| whatsapp-web.js | 802 MB | 806 MB | 18 | 150 MB | ~650 MB/session |
| baileys | 152 MB | 152 MB | 5 | 127 MB | ~25 MB/session |
Reproduce: ./local/probe-memory.sh <project> [samples]
This confirms the browser is the entire cost. It also corrects an earlier note in this
repo claiming 8 GB is required: upstream's own compose defaults to 2g, and the 8g was a
deployment choice in stack/.env.example, not an engine requirement.
⚠️ Do not compare §3 to §2 directly. WAHA's numbers are vendor-published on unknown hardware and workload; ours are one idle session on a laptop. Same-box, same-probe measurement is the only honest comparison — see §6.
4. Licence — correcting a claim in this repo
OpenWA's own comparison table marks WAHA Core as "❌ Open Source". That is false.
devlikeapro/wahais Apache-2.0 (LICENSE, branchcore).- Per WAHA's FAQ: since
2026.6.1everything is free and open source — unlimited sessions, unlimited messages, all storages (PostgreSQL/S3/Mongo), security features. There is no longer a separate "Plus" image or paid tier.
⚠️ Repo docs lag reality: WAHA's own AGENTS.md still describes a Core/Plus split
("Plus extends core … multi-session orchestration"). Trust the FAQ and the licence file over
that stale doc — but verify against the actual image you pull, since this is exactly the
kind of claim that should not be taken on faith.
Action: fix the false "❌ Open Source" cell in OpenWA's comparison table — it is a factual error in our repo and it is the kind that loses credibility in review.
5. OCI feasibility — and the limit changed under us
Oracle halved the Always Free ARM allowance: 4 OCPU / 24 GB → 2 OCPU / 12 GB, enforced from 2026-08-18. It is a tenancy-wide budget, not a per-instance cap — one 2/12 box, or two 1/6 boxes, and the sum cannot exceed it. The two AMD micro instances (1/8 OCPU / 1 GB) are untouched. 200 GB block storage and 10 TB/month egress unchanged.
Any tutorial still saying 4 OCPU / 24 GB is out of date. Confirm the real ceiling in the tenancy's Limits, Quotas and Usage page — some fresh Free accounts report being UI-capped at 1 OCPU / 6 GB.
Does it fit? (2 OCPU / 12 GB)
| Stack | Needs (50 sessions) | Fits 2 OCPU / 12 GB? |
|---|---|---|
| WAHA GOWS | 1.5 CPU / 3 GB | ✅ comfortably (~50–100 sessions) |
| WAHA NOWEB | 2 CPU / 4 GB | ✅ (~50 sessions, CPU-tight) |
| WAHA WEBJS | 15 CPU / 20 GB | ❌ no — only ~10 sessions fits |
| OpenWA baileys (measured) | ~25 MB/session | ✅ RAM-wise; CPU-bound in practice |
| OpenWA webjs (measured) | ~650 MB/session | ❌ no — ~15 sessions max |
Verdict: browserless engines are the only viable path on OCI free. A Chromium engine cannot scale there on any engine wrapper. This is an engine decision that happens to determine the hosting decision — not the reverse.
The blocker nobody mentions: ARM
OCI free compute is aarch64. Our local box is x86_64, so none of the measurements in
§3 transfer. WAHA publishes ARM images (waha:arm, waha:noweb-arm) but GOWS ARM64
availability is unverified, and the Go bridge is the whole reason to pick WAHA. This must be
checked on the actual instance before committing.
Second constraint: free-tier capacity is scarce
Multiple 2026 reports describe Out of capacity on A1 in some regions and accounts UI-capped
below the documented 2/12. Upgrading to Pay As You Go reportedly restores 4 OCPU / 24 GB
free and gets capacity priority — worth knowing, since PAYG still bills $0 inside the free
allowance. Treat "can I even get an A1 instance" as a real risk, not a formality.
6. What to do next (in order)
- Measure WAHA on this box, same probe, same hardware. Pull
devlikeapro/waha, runGOWSandNOWEBandWEBJS, and measure withlocal/probe-memory.sh. Until this exists, §2 vs §3 is vendor-marketing vs one laptop sample. (Blocked earlier: the WAHA container was removed; the 4.14 GB image is still cached, so it is a quick restart.) - Verify GOWS on ARM64. If it does not run on aarch64, the OCI free path collapses to NOWEB — still viable, but a different cost profile.
- Confirm the tenancy's real ARM ceiling in Limits, Quotas and Usage before designing around 2 OCPU / 12 GB.
- Only then decide WAHA vs OpenWA. If the answer is "browserless only", both wrappers can do it, and the tiebreak becomes API ergonomics + licence, not capability.
- Fix the false "❌ Open Source" cell in OpenWA's comparison table.
7. Recommendation
Engine before wrapper. The 650 MB/session Chromium cost is what kills OCI free — not the choice between WAHA and OpenWA. Both ship a browserless engine; pick on that axis first.
WAHA is the better fit if you want a published scaling model, GOWS, and the free
Apache-2.0 multi-session story. OpenWA stays defensible if you value the existing
Supabase/R2 integration and the compose stack already wired in stack/. The local harness now
runs either engine side by side, so this is a cheap comparison to run — not an architectural
commitment.
Do not decide from the numbers in this document alone. §2 and §3 were produced on different hardware; step 1 exists precisely to remove that doubt.