Your shop wants WhatsApp alerts when a form submits, or support wants Chatwoot to answer DMs from the same inbox as email. Meta's official Cloud API is the right answer when lawyers are in the room — but it has templates, business verification, and per-conversation pricing. Meanwhile your team already has a spare SIM and a QR code habit from WhatsApp Web.
OpenWA (~15k stars, MIT) is a self-hosted WhatsApp API gateway: REST API, webhooks, multi-session dashboard, plugins for Chatwoot and Typebot, and community n8n nodes. It is not official WhatsApp. It talks to WhatsApp through reverse-engineered clients (whatsapp-web.js or Baileys), which is exactly why you need to read the risk section before you link a number.
What OpenWA actually does
At the core you get a NestJS API plus a React dashboard on one port (default 2785 in Docker):
- Multi-session — several WhatsApp accounts on one instance, each with its own QR / pairing flow
- REST + Swagger — send text, media, reactions, edits; groups, labels, channels; bulk sends with pacing hooks
- Webhooks — inbound events with HMAC verification and optional filters
- API keys — admin, operator, and viewer roles; optional scopes per session and per chat (so an automation only sees the groups you allow)
- Pluggable backends — SQLite for tinkering, PostgreSQL for production; local disk or S3/MinIO for media; optional Redis cache
Official plugins live in OpenWA-plugins — Chatwoot handoff, Typebot flows, and more on their "integration fabric." If you already run n8n, community nodes wire OpenWA into workflows without paying a middleman SaaS per message.
The part you must not skip: ban risk and compliance
OpenWA's own README is blunt, and we agree with it:
- Unofficial clients mean non-zero ban risk. WhatsApp looks for automation. No gateway can promise your number stays safe.
- Use a disposable number. Not your personal line, not your main business line. One you can re-provision if Meta restricts it.
- Do not cold-blast. First-contact spam to hundreds of strangers is how accounts die on any engine.
- Pace sends. Enable send pacing for warm-up caps; bulk helpers honor delays between messages. API rate limits protect your server, not WhatsApp's patience.
- Regulated / EU-scale commercial messaging? Use Meta's Cloud API. OpenWA is a fit for internal alerts, hobby projects, opted-in support on a dedicated line — not a HIPAA-approved blast platform.
Pick an engine with trade-offs in mind: whatsapp-web.js runs headless Chromium (heavier RAM, somewhat different risk profile); Baileys is lighter but has its own quirks. Neither is "approved" by Meta.
Why self-host instead of a hosted gateway?
Webhook and message metadata stay on your VPS. Logs, media archives (if you turn them on), and API keys live in your Postgres/SQLite — relevant when you want Canadian infrastructure and a clear data map for clients.
No per-seat gateway SaaS. You pay for the server and your SIM; you own upgrades and backups.
Fine-grained API keys. Chat-scoped keys let an AI agent or integration reply in two support groups without listing every DM on the account — useful when one WhatsApp line serves multiple brands.
Compose with tools you already run. Chatwoot, Typebot, n8n, custom PHP — all hit the same REST surface behind your reverse proxy.
What running it takes
Docker is the supported production path. Clone the repo and docker compose up -d for SQLite + local storage, or bring profiles for PostgreSQL, Redis, and MinIO (--profile postgres, --profile full). Dev quick start uses docker-compose.dev.yml; production uses the main compose file with a hardened image (non-root process, optional docker-socket-proxy for plugin orchestration — read their SECURITY.md if you enable infra plugins).
First boot prints a one-time admin API key to logs and /app/data/.api-key inside the container. Dashboard, API, and Swagger share port 2785 unless you remap it.
RAM: budget 2 GB for a single Baileys session; 4–8 GB+ if you run multiple whatsapp-web.js sessions with Chromium. CPU spikes during media download and browser startup.
Put TLS and auth in front — VPN, SSO proxy, or at minimum IP allowlists (OpenWA supports CIDR whitelisting). Never expose the dashboard raw on the internet. Per-session residential proxies are supported if datacenter IPs get flagged; that is a mitigation, not permission to spam.
Back up openwa-data volumes and external Postgres. Losing the session store means re-scanning QR codes and re-pairing every line.
Who it's for (and who should skip it)
Good fit: small teams wiring order-status or appointment reminders to people who already opted in, homelabbers automating personal notifications, agencies running a dedicated support WhatsApp on Chatwoot with a spare number.
Skip it: marketing blast lists, authentication OTP as your only channel, healthcare/finance without Cloud API sign-off, or anyone unwilling to maintain unofficial-client breakage when WhatsApp changes protocol.
Hosting it in Canada
We run Docker workloads on Canadian VPS with TLS, firewall rules, and backup scope that includes your database and media volumes — not the messages themselves on Meta's servers, but everything OpenWA stores locally. Pair with monitoring so you know when a session drops to qr_ready before customers notice.
Tell us session count, engine choice, and which integrations you need — we'll size RAM for Chromium vs Baileys and keep the gateway off the public internet unless you really mean it.
