DeskcommCRM: An Open Source WhatsApp CRM With AI Agents Built In

DeskcommCRM is an open source, self-hosted CRM built around one channel: WhatsApp. It is MIT-licensed, written in TypeScript on Next.js 16, and it ships AI agents as a first-class part of the product rather than a bolted-on chatbot widget.

The pitch from the maintainer, Rafael Melga, is direct — it is the open alternative to Kommo, Octadesk and Intercom for any business that sells over chat. No per-seat subscription, no features locked behind a tier, and the database sits on your own server.

The project started as an e-commerce CRM and the community pushed it somewhere broader. It now runs in clinics, real-estate agencies, agencies and info-product businesses — anywhere the sales conversation happens in a WhatsApp thread rather than an email chain. The product followed that drift and rebranded itself a "sales operating system", which is marketing language for a real architectural decision: the CRM is exposed over MCP, so an AI agent can operate the system instead of merely chatting next to it.

At the time of writing it has 1,550 stars and 514 forks, and the last commit landed the day this page was published. That fork-to-star ratio is unusually high — roughly one fork for every three stars — which for a self-hosted tool generally means people are actually deploying it, not just bookmarking it.

Search for a self-hosted WhatsApp CRM and you find surprisingly little. That is not an accident, and understanding why explains most of DeskcommCRM's design.

WhatsApp has no open protocol. There are exactly two ways to send a message programmatically:

1. The official Meta Cloud API. Legitimate, stable, and what Meta wants you to use. It also requires business verification, charges per conversation, and restricts you to pre-approved message templates outside a 24-hour customer service window. You cannot simply start messaging a lead.

2. An unofficial bridge. Software that authenticates as a real WhatsApp Web client by scanning a QR code with a phone. Full freedom, no templates, no per-message fees — and no blessing from Meta, with a genuine risk of the number being banned.

Most commercial "WhatsApp CRMs" resell the first option with a markup. Most open source projects implement the second and leave the ban risk entirely with you.

DeskcommCRM supports both, which is the sensible answer. It uses WAHA for QR-based connections so you can be running in an afternoon, and it speaks the Meta Cloud API — keeping approved templates in sync — for when you need to scale on official rails.

For the QR path it also implements the mitigations that serious operators use and hobby projects skip: send throttling, randomised jitter between messages, configurable time windows so you are not blasting messages at 3am, and STOP detection to honour opt-outs. None of that makes a QR connection officially sanctioned. It does meaningfully reduce the odds of a ban.

Plenty of CRMs have added an AI panel. The distinction here is that the agent has hands — it can operate the CRM, not just draft replies.

Per-tenant RAG. Each organisation gets its own knowledge base, embedded with pgvector in Postgres. The agent answers from your documents, your pricing, your policies — not a generic model's guesses.

Skills the agent runs on its own. Mid-conversation, the agent can execute a defined action rather than asking a human to go do it. This is the difference between a chatbot that says "let me check that for you" and one that actually checks.

Operational memory. Context that outlives a single conversation, so a returning customer is not greeted as a stranger.

Audited AI→human handoff. The agent recognises when it is out of its depth and escalates — and the handoff is logged. The AI is a first-class assignee in the queue, the same as a human rep, which is a cleaner model than treating the bot as a pre-filter everyone routes around.

Per-organisation spending caps. An agent looping on an expensive model is a real risk when you are paying per token. There is a hard ceiling per tenant.

Self-improvement, human-gated. Resolved conversations become new knowledge. An AI Evolution screen reports whether the agent is actually getting better, where it fails, and what remains untaught. The system generates Proposals — improvements it suggests for itself — which a human must approve before they apply as a new version. That last clause matters; unsupervised self-modification in a system that talks to paying customers is how you get an expensive incident.

You also choose your provider: OpenRouter, Anthropic, OpenAI or Google, selected at install and switchable later from the UI — per part of the system, so the model that holds conversations need not be the one that indexes documents. That is a genuinely thoughtful piece of design, and it means you are not locked to whichever vendor was fashionable when the project was started.

The surface area is larger than most open source CRMs. The screens break down roughly like this:

Two details worth pulling out.

Vocabulary is configurable per pipeline. A lead becomes a Customer, a Patient or a Buyer; "won" becomes Paid, Booked or Closed. It sounds cosmetic. It is the reason one codebase serves a clinic and a Shopify-style store without either feeling like it is using someone else's tool.

Automations are WHEN/IF/THEN rules built on a capture-source model. Every tenant gets a public endpoint that accepts leads from landing pages, forms, Zapier or n8n and drops them into a chosen pipeline stage. Rules then add tags, move leads, assign agents, send WhatsApp messages or call external webhooks.

There is a sharp engineering decision underneath: no database trigger ever makes an HTTP call. Every event becomes a row in an event_log table, and a cron route drains the queue once a minute. Anyone who has watched a Postgres trigger block on a dead external endpoint will recognise why that matters. The trade-off is that the cron job is load-bearing — without it, automations are created happily and simply never run.

This is a conventional, current stack, which is a compliment. There is nothing exotic to learn before you can contribute, and every component is something you can hire for.

The testing story is stronger than the typical self-hosted project. Merging to main requires passing verify (typecheck, lint, unit), build-and-size, e2e (44 Playwright specs against a real local Supabase) and invariants — which boots a clean Postgres, applies the schema in both install and update mode to prove idempotency, then runs 618 invariants across 98 files covering RBAC, scoping, routing and automations.

Multi-tenant isolation is enforced by RLS with a dedicated isolation test as a CI gate. For software where one leaked row means one customer reading another customer's WhatsApp conversations, that gate is the right call.

The intended path is a VPS with Docker. You SSH in and run three commands:

git clone https://github.com/melgarafael/DeskcommCRM.git
cd DeskcommCRM
bash hostgator-setup-kit/install.sh

You do not install Node, pnpm, or compile anything — the app image is prebuilt, and the installer offers to install Docker if it is missing.

What you need on hand before starting:

• A VPS with Docker, 4 GB RAM recommended
• A domain with an A record pointing at the VPS
• A Supabase account — three keys plus the session pooler connection string
• An AI key — OpenRouter, Anthropic or OpenAI
• A WhatsApp number to scan the QR code

The installer asks only for what is genuinely yours, generates every technical secret itself, and validates each answer as you give it rather than failing three steps later. It is idempotent — re-running does not duplicate the cron job or recreate your admin user.

Two nice touches. If your VPS already runs its own reverse proxy on ports 80 and 443 — Coolify, Dokploy, CapRover — the installer detects it and publishes through it instead of fighting for the port. And in the one ambiguous case (a proxy on --network host, as Hostinger does) it asks rather than guessing, because publishing behind the wrong proxy "succeeds" and leaves you with a silent website.

One warning if you plan to develop against it. Do not run supabase db push. Migrations 0001–0009 and 0013 are SELECT 1; stubs and the chain does not build from zero. The real schema lives in supabase/baseline.sql. The push command will report success and leave you with an empty database.

The headline is "no subscription, no gated features". That is true of the CRM itself — it is MIT, and nothing in the application is paywalled. It is not the whole bill.

WAHA Plus is a paid product. The stack specifies WAHA Plus with the NOWEB engine. WAHA's free Core image is limited to a single session and does not include media messaging; multiple sessions and media require WAHA Plus, distributed as a separate devlikeapro/waha-plus Docker image behind a subscription key — historically around $19/month. If you want a WhatsApp CRM that can send an image or run more than one number, budget for it. This is the single most important thing missing from the project's own pitch, and no competing write-up mentions it.

Supabase. The free tier is enough to evaluate. A real conversation history with embeddings is not a free-tier workload for long.

AI tokens. Every agent reply is a model call. The per-org spending cap exists precisely because this is the cost that surprises people.

The VPS. 4 GB RAM recommended, running 24/7 because WhatsApp sessions must stay connected.

Realistically you are looking at $40–80/month to run this properly, against roughly $30–50 per user per month for Kommo. It still wins on cost at any real team size, and it wins outright on data ownership. But "free" means "no licence fee", not "no bill".

One more disclosure worth making: the README's HostGator links are partner links, which the maintainer states openly. The project is developed in partnership with HostGator, and the one-command install kit is built around that environment. It works on any Docker VPS — but the recommendation is not neutral, and it is fair to know that.

Chatwoot is the obvious open source comparison and the one most people land on. Chatwoot is a mature, multi-channel support desk — email, web chat, social, WhatsApp through API providers. It is broader, more established, and better if you need a shared inbox across many channels. DeskcommCRM is narrower and deeper: WhatsApp-first, with a sales pipeline and agentic AI that Chatwoot does not natively match. If your business sells on WhatsApp rather than supports on many channels, the narrower tool fits better.

Kommo (formerly amoCRM) is the commercial target. Polished, hosted, per-seat, with a minimum contract term. You trade money and data custody for someone else running it. Kommo is the right answer for a non-technical sales team with no ops capacity — which is most sales teams, honestly.

Octadesk and Intercom are further up-market and further from self-hosting. Intercom in particular has moved hard toward AI support agents, with a price tag to match.

wacrm is the closest open source neighbour — a lighter self-hostable WhatsApp CRM template. It is simpler and quicker to grasp. DeskcommCRM is substantially more system: multi-tenancy, RBAC, RAG, MCP, an audit log. Whether that is an advantage or overhead depends entirely on whether you need those things.

The honest summary: DeskcommCRM occupies a genuinely underserved position. Self-hosted WhatsApp CRMs with real agentic AI are close to a category of one right now.

Good fit if you sell over WhatsApp at volume, you have someone who is comfortable with a VPS and Docker, you want your conversation data on infrastructure you control, and per-seat CRM pricing is starting to hurt. The agentic AI is genuinely ahead of what the commercial WhatsApp CRMs currently ship.

Poor fit if nobody on the team wants to own a server. This is self-hosted in the full sense: updates are yours to trigger, backups are yours to keep, and support is community goodwill with no SLA. The project is explicit that whoever hosts the instance is the data controller for every customer conversation in it, with the legal obligations that follow. That is not a footnote — it is a real responsibility you are accepting.

Be aware of the Brazilian centre of gravity. The primary README is Portuguese (English and Spanish translations are maintained). Privacy tooling is built for LGPD, Brazil's data protection law — closely modelled on GDPR, so it maps well, but it was not written against GDPR. The shipped e-commerce integration is Nuvemshop, which is large in Latin America and unknown elsewhere; Shopify and VTEX are on the roadmap, not in the box. If you are outside Latin America, none of this blocks you, but you are not the primary audience and it occasionally shows.

Verify before you trust. The maintainer sets a good example here — the README tells you to check the CI requirements with gh api rather than believing the list in the docs, noting it has already drifted twice. Apply the same standard to everything above: star counts, the WAHA pricing, and the roadmap all move. The figures here were checked on 12 September 2026.