wacrm: a forkable WhatsApp CRM template built on Next.js and Supabase

The problem wacrm solves: one WhatsApp number, several agents, no per-seat invoice

A single WhatsApp Business number usually ends up in one person's phone. The moment two or three people need to answer from it, the options are a shared handset, a spreadsheet of who replied to whom, or a hosted CRM that charges per seat and holds the data. wacrm targets the third option's escape route. The README describes it as a template rather than a product: you fork the repository, point it at your own Supabase project and Meta app, and the conversations live in infrastructure you control. The intended user is a small sales or support team, or a solo operator, who is comfortable owning a Node.js deployment and a Postgres instance. The README is explicit that solo use stays single-user with zero setup, while team accounts are invite-by-link with owner, admin, agent and viewer roles, and that every install is account-scoped. That last detail matters: the shared inbox is not a global queue with a permissions overlay, it is scoped to an account, so staffing one number with a whole team is the supported pattern rather than a workaround.

What the modules actually cover, and what they assume about Meta

The feature list is broad but specific. Shared inbox runs on the official WhatsApp Business API with per-conversation assignment, status and notes. Contacts carry tags and custom fields, with CSV import and deduplication. Pipelines are Kanban boards where deals link back to conversations. Broadcasts use Meta-approved templates with delivery and read tracking plus per-recipient variable substitution. Automations are no-code, triggered on inbound messages, new contacts, keywords or a schedule, with conditional branches, waits, tags and webhooks, built in a visual editor. There is an AI reply assistant where you supply your own OpenAI or Anthropic key, stored encrypted, with one-click drafted replies and an optional auto-reply bot that has a per-conversation cap and a human handoff. A knowledge base can be attached, answering from your own FAQs, policies and product docs using hybrid retrieval: Postgres full-text, or semantic pgvector when an embeddings key is present. The dashboard reports response times, daily volume and pipeline value. Two surfaces sit outside the UI: a public REST API under /api/v1 with scoped, revocable API keys, documented in docs/public-api.md, and an MCP server in mcp-server/ that lets Claude, Cursor and other assistants drive the CRM, read-only by default with opt-in writes, documented in docs/mcp.md. The constraint running through all of this is Meta. Broadcasts need approved templates and the webhook needs HTTPS, which is why the deployment guidance pushes a managed host with automatic certificates rather than a bare VPS.

Architecture: Next.js 16 on Supabase, with RLS as the real boundary

The stack is deliberately unremarkable: Next.js 16 with the App Router, server actions and ISR, Supabase for Postgres and Auth, Tailwind for styling, TypeScript throughout. The README calls the stack boring on purpose so the learning curve is short, and for a template that is the right call, because the person forking it is also the person who will debug it. Data flow follows the usual shape. Meta sends webhooks into the app, which verifies them with HMAC before anything is written. Supabase stores conversations, contacts, deals and automation state. The browser reads through Next.js routes and server actions rather than talking to Postgres directly. Security primitives named in the README are token encryption with AES-256-GCM, row level security on every table, HMAC-verified webhooks, CSP, rate limiting, and CI that runs typecheck and build on every pull request. RLS on every table is the load-bearing claim here, because it means the database enforces account scoping even if an API route is written carelessly. The counterpoint is that RLS policies are also the thing most likely to break silently when you add a table or a join for your own custom fields. The README does not document a migration workflow for schema changes, so treat that as your problem, not the template's.

Getting it running: fork, clone, fill .env.local, npm run dev

The README's quick start is four commands plus an environment file. Fork the repository on GitHub first, then clone your fork, install, copy the example environment file and fill it in, and start the dev server:

git clone https://github.com/<your-username>/wacrm.git cd wacrm npm install cp .env.local.example .env.local npm run dev

The app serves on http://localhost:3000 and redirects to /login, or to /dashboard if a session already exists. The environment file needs Supabase and Meta credentials; the deployment section names the variable families as SUPABASE_*, WHATSAPP_* and ENCRYPTION_KEY, set from the hosting panel rather than a file on the server. ENCRYPTION_KEY is the one to think about before first run, because it protects stored tokens and AI provider keys with AES-256-GCM. If it changes between environments, previously encrypted values stop decrypting. The README points to docs/docker.md for a Dockerfile and Compose setup if you would rather not use a managed host. The recommended path is Hostinger: connect your fork in hPanel under Websites, Create, choose Node.js, paste the environment variables, and push to main, at which point the host builds and ships it. The README states that this repository's own main branch deploys that way. Note that the marketing site and self-host documentation live in a separate repository, ArnasDon/wacrm-site, which is where wacrm.tech and the step-by-step deployment guide are maintained.

Where wacrm is the wrong tool

Three cases stand out. The first is anyone who wants a vendor to own the WhatsApp relationship. wacrm does not abstract Meta away. You still create the Business API app, get templates approved, and keep the webhook reachable over HTTPS. If template rejection or number verification is the part you want outsourced, a hosted CRM is the honest answer, because forking this repository moves that work onto you without removing it. The second is teams without a Postgres or Supabase operator. The README advertises zero ops to start, and on a managed host that is roughly true for the Node process. It is not true for the database. RLS on every table is a security feature only while the policies are correct, and the material supplied here does not describe a migration tool, a seed script or a schema versioning convention. The third is scale beyond a small team. There is nothing in the README about queueing, worker processes, or how broadcasts behave when a large recipient list is submitted. Broadcasts with per-recipient variable substitution imply a send loop somewhere, and the documentation does not say whether that loop is bounded, retried, or rate-limit aware. Treat large broadcast volumes as unverified until you read the source. A fourth, softer limitation: the AI features assume you already have an OpenAI or Anthropic key and, for semantic retrieval, an embeddings key. Without the embeddings key you fall back to Postgres full-text search, which is a different retrieval quality, not a degraded version of the same one.

Alternatives, and the actual difference in approach

The obvious comparison is Chatwoot, the open source shared inbox that also supports WhatsApp among other channels. The difference is shape rather than features. Chatwoot is a product you deploy: it ships as a Rails application with its own database schema, its own upgrade path, and a plugin model for channels. You configure it and you upgrade it on its release cadence. wacrm is a template you fork: the code becomes yours, so custom fields, module removal and redesign are edits to your own repository rather than configuration against someone else's. That cuts both ways. With Chatwoot you inherit a maintained upgrade path and a larger surface of channels; with wacrm you inherit a Next.js codebase you are expected to modify, and no upstream merge story is described in the material here. A second comparison is building directly on the WhatsApp Business API with a generic CRM such as Twenty or a bespoke internal tool. That gives maximum control over the data model but leaves you writing the webhook verification, the token encryption, the inbox assignment model and the broadcast tracking yourself, which is precisely the work wacrm has already done. The honest framing is that wacrm sits between a hosted product and a from-scratch build, and it is a good fit only if you want to be the maintainer.

Maintenance cost, licence, and what to check before you fork

MIT is the permissive end of the spectrum: you can fork, rebrand, host and modify, including commercially, provided the licence and copyright notice are retained. That is not legal advice, and the WhatsApp name and logo carry their own trademark considerations that the README does not address. The real cost is not the licence, it is drift. A fork of a template diverges from upstream the moment you add a field, and the material gives no indication of how upstream changes are meant to reach forks. The repository shows no retrieved releases, so there is no tagged version to pin against, which means tracking main is the only visible option. Practical maintenance therefore looks like this: watch the upstream repository, read the diff before merging, and keep your Supabase schema changes in a form you can replay. The environment variables are the other long-lived obligation. SUPABASE_*, WHATSAPP_* and ENCRYPTION_KEY must stay consistent across local, staging and production, and rotating ENCRYPTION_KEY requires re-encrypting stored tokens rather than simply replacing the value. If you deploy on a managed Node host, the Node version, process supervision, reverse proxy and TLS certificates are someone else's problem, which is the main argument the README makes for that path. If you deploy with the Docker Compose setup in docs/docker.md, they are yours. Either way, the CI workflow in this repository runs typecheck and build on pull requests, and that is worth keeping wired to your fork, because it is the cheapest signal that an upstream merge did not break your customisations.

Editorial conclusion

Fork wacrm if you have a Meta WhatsApp Business API app, a Supabase project, and someone who can read a Next.js codebase when an upgrade breaks. Do not fork it if you want a vendor to hold your hand through Meta template approval or if nobody on the team will own the schema. Before committing, verify three things: that your Meta app is approved for the number you intend to share, that `ENCRYPTION_KEY` is set and stable in every environment, and that you have read docs/mcp.md, because the MCP server is read-only by default and opt-in writes change what an AI assistant can do to your data.

Official sources

1. ArnasDon/wacrm on GitHub
2. Issues
3. License: MIT
4. Project website
5. README