I have shipped two generations of a WhatsApp Web automation platform that runs hundreds of concurrent tenant sessions. The first generation taught us what breaks at scale. The second was designed around those scars. Here is the shortest version of the playbook.
The two-process backbone: Laravel for control, Node for transport
Laravel handles tenants, billing, plans, templates, and the admin surface. A separate Node process owns the WhatsApp Web sessions, message queues, and the realtime socket layer. The two talk over a private HTTP API on localhost and a shared Redis instance.
Keep the WhatsApp library and any of its native dependencies out of the PHP process entirely. The PHP worker should never need to know that you are using baileys or wppconnect under the hood, only that there is a transport it can POST to.
Session isolation is the whole game
Every tenant gets its own authenticated session, its own message queue, and its own outbound rate window. Cross-tenant noise is the fastest way to get a number banned and to leak data into the wrong inbox.
On disk, store credentials per-tenant under a path that includes the tenant ID and never the phone number. Phone numbers can be reassigned. Tenant IDs are stable.
- Per-tenant Redis keyspaces for queues and counters
- A health probe per session that quietly reconnects without nuking auth state
- Backoff windows on outbound to mimic human cadence
- Hard caps on per-minute throughput, configurable per plan
Sockets without bringing the server to its knees
Realtime updates are the magic of the product but also the easiest way to torch your CPU. Slim the broadcast payload aggressively: send IDs and short status codes, not the entire message object. Clients fetch the full record on demand.
Nginx should proxy only the socket path to the Node process. Everything else stays on PHP-FPM. This keeps the socket server stateless from the browser POV and lets you scale it independently.
Operational concerns nobody warns you about
WhatsApp Web protocol churn is the single biggest source of incidents. Pin the transport library version, run a canary tenant on the next version for at least a week before rolling, and keep a one-command rollback script.
For plugin-style features, gate every plugin behind an explicit is_enabled flag and resolve the class only when the plugin is active. The composer autoloader is a red herring — it cannot tell you whether the tenant should see the feature.
Takeaway
A WhatsApp SaaS is really a session manager wearing a CRM. Get session isolation, broadcast payload size, and library version pinning right, and the rest of the product becomes ordinary Laravel work.
