wacrm: a self-hosted WhatsApp CRM template you fork instead of subscribe to

The problem wacrm solves, and who it is aimed at

A small sales team on WhatsApp usually ends up with one phone, one person holding it, and no record of what was promised. The official WhatsApp Business API removes the single-phone constraint but adds a Meta app, a phone number registration, webhook verification and template approval. Between those two states sits a gap that SaaS CRMs fill by charging per seat and holding your conversation history.

wacrm is aimed at the team that wants to close that gap itself. The README describes it as a template rather than a product: you fork the repository, point it at your own Supabase project, and the conversations, contacts and deals live in a database you control. The out-of-the-box list covers a shared inbox on the official WhatsApp Business API with per-conversation assignment, status and notes; contacts with tags and custom fields plus CSV import and deduplication; Kanban pipelines with deals linked to conversations; broadcasts using Meta-approved templates; and a visual builder for automations triggered by inbound messages, new contacts, keywords or a schedule.

That is a conventional CRM feature set. The distinguishing decision is distribution. There is no hosted tier in this repository, and no seat pricing, because there is no vendor between you and the database. The cost of that decision lands on you, and the rest of this article is mostly about where.

How wacrm is put together: Next.js, Supabase, and where the secrets sit

The stack is Next.js 16 with the App Router and Supabase for Postgres and Auth, with Tailwind for styling. package.json pins node >=20.0.0 and [email protected], and the dependency list is short and unremarkable: Supabase client libraries, dnd-kit for the Kanban board, xyflow for the automation graph, recharts for the dashboard, next-intl for translations. Nothing here requires a specialist to read.

The security primitives named in the README are worth stating precisely, because they are the parts you would otherwise have to write. WhatsApp tokens are encrypted with AES-256-GCM, row level security is enabled on every table, webhooks are HMAC-verified, and there is CSP and rate limiting. The AI assistant uses your own OpenAI or Anthropic key, stored encrypted, with no per-seat fee. A public REST API lives under /api/v1 with scoped, revocable keys, and there is a separate MCP server in mcp-server/ so an AI assistant can read the CRM, read-only by default with opt-in writes.

The Dockerfile makes the split between build-time and runtime secrets explicit, and this is the detail most likely to bite. NEXT_PUBLIC_* values are inlined into the client bundle during the build stage, so they arrive as build args. Server-only secrets such as the service role key, ENCRYPTION_KEY and META_APP_SECRET are read at runtime and, as the Dockerfile comment puts it, must not be baked into the image. If you change a NEXT_PUBLIC_* value later, the compose file notes that a rebuild is required.

Installing wacrm locally and reaching the dashboard

The README's quick start assumes you fork first, because the clone URL in the example points at your own username. Node 20 or newer is required. The four commands below are copied from the README; the copy step produces .env.local from the example file, and you fill in Supabase and Meta credentials before the dev server will be useful.

git clone https://github.com/<your-username>/wacrm.git
cd wacrm
npm install
cp .env.local.example .env.local   # fill in Supabase + Meta creds
npm run dev

Open http://localhost:3000. According to the README you are redirected to /login, or straight to /dashboard if you already have a session. The repository also ships a Docker path, documented in docs/docker.md, for people who would rather not install Node locally.

docker compose up --build

The compose file publishes the app on host port 3000 by default and pins PORT to 3000 inside the container, with a comment explaining that environment wins over env_file so a stray PORT in .env.local cannot desync the app from the port mapping or the healthcheck. Set HOST_PORT if 3000 is taken. The healthcheck fetches http://localhost:3000 every 30 seconds and treats any response under 500 as healthy, with a 15 second start period.

Before any of this matters, you need a Supabase project and a Meta app with a WhatsApp number. The README does not walk through Meta app creation in the section reproduced here; it points at wacrm.tech/docs for the deployment guide, and the marketing site lives in a separate repository, ArnasDon/wacrm-site. Treat the docs site as required reading rather than optional.

The deployment path wacrm actually recommends

The README does not present hosting as neutral. It states that wacrm is built to run on Hostinger, calls that the path the project tests, documents and recommends, and carries an affiliate referral code in the deploy links. That is worth naming plainly: the recommended path is also a monetised one. It does not invalidate the recommendation, but you should read it knowing the incentive exists.

The technical argument given is that Managed Node.js on Hostinger's Premium, Business and Cloud shared plans runs Next.js 16 with the App Router, server actions and ISR without you managing Node versions, processes or reverse proxies. The 60-second version is: fork the repository, create a Node.js site in hPanel and connect the fork, paste Supabase and Meta environment variables into the panel, then push to main. Environment variables and logs live in hPanel, so there is no .env file on the server. SSL is automatic, which the README notes matters because the WhatsApp Business webhook requires HTTPS.

None of this is mandatory. The Dockerfile and docker-compose.yml in the repository are a complete alternative, and nothing in the compose file references Hostinger. If your team already runs containers, the shared-hosting route buys you convenience and costs you control over the runtime.

Where wacrm stops being the right tool

The first limitation is structural: this is a template, and templates drift. The README says forking gives you full ownership and full customisation, and that is true, but it also means upstream changes are yours to merge by hand. There are no retrieved releases to pin against, only a version field in package.json reading 0.8.0, so the practical upgrade unit is a commit range on main plus CHANGELOG.md. A team that heavily restyles the UI and rewrites the automation schema will find that every upstream change is a merge conflict.

The second is operational ownership. The webhook endpoint is public by necessity, which is why the README mentions edge DDoS protection and daily backups as part of the recommended host. If you self-host on a bare VPS, those are yours to arrange. Nothing in the repository appears to be a managed service that pages you when delivery stops.

The third is the Meta dependency, which no amount of forking removes. Broadcasts require Meta-approved templates, and the number has to be registered on the official WhatsApp Business API. If your use case is a personal number sending bulk messages, this is the wrong tool and would likely get the number restricted anyway. The README is explicit that the shared inbox runs on the official API, not on an unofficial client.

Finally, the AI features are bring-your-own-key. The README describes hybrid retrieval over a knowledge base using Postgres full-text search, or semantic pgvector when an embeddings key is set. That is a configuration you must complete; it is not a feature that works because you installed the app.

Alternatives, and the actual difference in approach

The closest alternative in kind is Chatwoot, an open source shared inbox that also connects WhatsApp and also expects you to run it. The difference is scope. Chatwoot is a support inbox first and its data model is built around conversations and agents; wacrm is built around a CRM, so deals, pipelines and contacts are first-class objects rather than additions, and the automation builder and broadcast module ship in the same repository. If your team's centre of gravity is ticket triage, Chatwoot's shape fits better. If it is a sales pipeline fed by WhatsApp conversations, wacrm's does.

The other alternative is not a project but a category: a hosted WhatsApp CRM where the vendor operates the Meta integration, the database and the upgrades. You pay per seat and your data sits in their tenant. wacrm's answer to that is in the README's own framing, full ownership with no SaaS lock-in and no seat pricing. The honest trade is that you also inherit the on-call rotation, and for a two-person team that may be a bad deal regardless of the licence.

One more comparison worth making, since it comes up in search: people looking for wacrm sometimes arrive from OpenWA or similar unofficial WhatsApp clients. Those sit on a different foundation entirely. wacrm uses the official WhatsApp Business API, which means Meta approval gates and template review, and in exchange the connection is not something Meta can shut down as an unauthorised client.

Licence, maintenance and what an upgrade actually costs

wacrm is MIT licensed, and package.json carries the same identifier with Arnas Donauskas as author. MIT is permissive: you can fork, modify, rebrand and run it commercially, and the repository's own positioning invites exactly that. The obligation is to keep the copyright notice and licence text with the code. That is a statement about the licence terms as written, not legal advice; if you are folding the code into a product you sell, have your own counsel read it.

Maintenance is the part to weigh carefully. The repository is not archived, and the last push to main was on 2026-09-07, which makes it current. There are no retrieved releases, so there is no tagged version to track and no changelog entry to diff against beyond CHANGELOG.md in the tree. In practice your upgrade path is: read CHANGELOG.md, pull main into your fork, resolve conflicts, run npm run typecheck and npm run test, then rebuild. The Docker path adds one wrinkle the compose file states directly: changing any NEXT_PUBLIC_* variable requires docker compose up --build, because those values are inlined at build time.

CI runs typecheck and build on every pull request according to the README, and the repository ships vitest with test and test:watch scripts. That is a reasonable safety net for a fork, but it only covers what the tests cover. Your own customisations are your own to test.

Editorial conclusion

Adopt wacrm if you have a developer who can run a Next.js app and a Supabase project, and you want the inbox, pipeline and broadcast code to live in your own repository rather than in someone else's tenant. Do not adopt it if you need a vendor to answer the phone when a webhook stops delivering, or if nobody on the team can read TypeScript. Before you commit, verify three things in your own fork: that your Supabase schema applies cleanly from the supabase directory, that the WhatsApp webhook signature check passes against your Meta app secret, and that a production build runs with only the environment variables listed in .env.local.example. The last push to main was on 2026-09-07, so the template is current as of this writing; read CHANGELOG.md before you pull, because a fork that has diverged from main will not merge cleanly.

Frequently asked questions

Official sources

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