DeskcommCRM: a self-hosted WhatsApp sales CRM with AI agents, installed by one shell script

The problem DeskcommCRM picks: WhatsApp as the system of record

Most CRMs treat a chat as an attachment to a deal record. DeskcommCRM inverts that. The repository describes itself as an open source sales OS where AI agents "atendem, qualificam e vendem no WhatsApp", with the CRM running on your own server. The stated target is any business that sells by chat, and the named alternatives it positions against are Kommo, Octadesk and Intercom. That framing matters for who should read further: if your pipeline starts as a WhatsApp message and ends as a payment, the conversation is the primary object, and a CRM that stores conversations as first-class records is a different shape of tool from one that stores them as notes. The project also claims LGPD alignment and multi-tenancy, which points at Brazilian agencies and small SaaS operators running several client accounts on one deployment. The README is written in Portuguese first, with English and Spanish translations, and the partnership with HostGator plus a São Paulo datacenter reference confirm the intended market rather than leaving it implied.

How the pieces fit: Next.js, Supabase, WAHA and an MCP surface

The stack is visible from the badges and the installer description. The application is Next.js 16 with TypeScript in strict mode. Persistence, authentication and file storage come from Supabase, meaning Postgres plus Supabase Auth plus Supabase Storage. WhatsApp connectivity is delegated to WAHA, a separate WhatsApp HTTP API, with the option of the official Meta channel. The installer applies a schema from supabase/baseline.sql, creates the Postgres extensions, and then creates the first admin account. AI providers are pluggable at install time: the installer asks whether you want OpenRouter, Anthropic or OpenAI and takes the corresponding key. The topics list also names RAG and MCP, so the AI agents are intended to answer from retrieved context and to be callable from MCP clients, though the README excerpt does not document the retrieval pipeline or the tool schema. Treat the agent quality as something you have to evaluate on your own data, not something the repository material establishes. The multi-tenant and LGPD claims are likewise stated rather than demonstrated in the material available.

The install path is the product's real centre of gravity

The README does not bury the setup in a wiki. It walks through it: SSH into the VPS, clone the repository, run bash hostgator-setup-kit/install.sh. The claim is that you do not install Node, pnpm or build anything, because the application image ships prebuilt, and that Docker is installed by the script if it is missing. The prerequisites are a VPS with Docker (4 GB RAM recommended), a domain with an A record, a free Supabase account, an AI provider key, and a phone number to connect by QR code. There is a non-interactive path for repeatable deployments: copy .env.hostgator.example to .env, fill it in, and run bash hostgator-setup-kit/install.sh --yes. Two details in that flow are worth noting because they are where self-hosted installers usually fail. First, the installer validates each answer before continuing, so a wrong key is rejected at the prompt rather than three steps later. Second, it registers a cron for the automation engine, and the README states plainly that without it the QUANDO/SE/ENTÃO rules stay queued. It also installs an update agent, which is what makes the "Atualizar agora" button in the UI functional. The script is described as idempotent: rerunning it does not duplicate cron entries or recreate the admin user.

Reverse proxies, and the case where the installer asks instead of guessing

The installer assumes it may not own ports 80 and 443. On a VPS that already runs its own reverse proxy (the README names Hostinger, Coolify, Dokploy and CapRover), it detects the proxy and publishes the CRM through it rather than starting a Caddy instance that would fail to bind. The README is honest about one specific case: when the existing proxy runs in --network host mode, as it does on Hostinger, the installer asks the operator rather than choosing, on the grounds that publishing behind the wrong proxy produces an installation that reports success while serving nothing. That is a small design decision but a meaningful one, because silent success is the worst failure mode in this category. The kit also ships a CLAUDE.md describing the steps and known pitfalls, so the whole setup can be handed to Claude Code running on the VPS with the instruction to install it. Whether you want an LLM driving a root shell on your server is a separate question, and the README does not address it.

Updates from the sidebar, and what that implies about maintenance

The update flow is unusual for a self-hosted project and is the clearest signal of where the maintainers spend effort. When a new version exists, the sidebar footer shows a "Nova versão" indicator, visible only to the server owner, on the reasoning that notifying people who cannot act on it is noise. Clicking it opens Configurações → Atualização, which lists what changes. The releases in the material are frequent: v1.16.0, v1.16.1 and v1.17.0 all landed within roughly thirty-six hours in September 2026. That cadence is a maintenance fact you should plan around, not a compliment. A fast-moving Next.js and Supabase application on your own VPS means schema migrations and container pulls arrive regularly, and the in-app updater exists precisely because the maintainers expect operators to update often. Budget for reading release notes and for the possibility that the updater and the manual git pull path diverge. The README does not describe a rollback procedure, so your own backup routine for the Postgres database is the only safety net named anywhere in the material.

Where this is the wrong tool

The dependency on WAHA is the sharpest limitation. WhatsApp does not offer a stable, sanctioned path for unofficial automation, and any project built on an unofficial WhatsApp HTTP API inherits the risk of session loss, number restrictions and behaviour changes outside its control. The README offers the official Meta channel as an alternative, which is the safer route for a production number, but that path has its own approval and template constraints that the excerpt does not cover. Beyond the channel, the operational surface is real: you are responsible for a VPS, a Supabase project, a WAHA container and the automation cron. The installer reduces the setup cost, not the ownership cost. If nobody on your team is comfortable with SSH, Docker and Postgres connection strings, the one-command install will get you to a running system and then leave you there. The 4 GB RAM recommendation also means this is not a Raspberry Pi project. And if your sales run on email and a website widget, the WhatsApp-centric data model is the wrong centre of gravity; you would be paying the WAHA complexity for a channel you do not use.

Against Chatwoot, and against staying on Kommo

Chatwoot is the obvious open source comparison and the difference in approach is structural. Chatwoot is a multi-channel support inbox: email, web widget, WhatsApp and social channels converge into one agent workspace, and its centre of gravity is ticket handling and agent assignment. DeskcommCRM is narrower and more opinionated: WhatsApp is the channel, and the AI agents are expected to qualify and sell inside it, with the CRM record built around that conversation. If you need email and a website widget in the same inbox, Chatwoot covers ground DeskcommCRM does not claim to. If your entire funnel is WhatsApp and you want an agent handling first contact, DeskcommCRM's shape is closer to the job. Against Kommo and Octadesk, the trade is not features but control. Those are hosted products with support, onboarding and someone else holding the uptime. DeskcommCRM gives you the database, the licence is MIT, and the bill is a VPS plus your AI provider usage. What you give up is the phone number you can call when a WhatsApp session drops at 2 a.m.

Licence, cost and what to check before you commit

The licence is MIT, which permits commercial use, modification and redistribution with the copyright notice retained. That is permissive enough for an agency to run client accounts on one deployment, which the multi-tenant design anticipates. It also means the maintainers owe you no support obligation, and the README does not describe a commercial support tier. The recurring costs are yours to assemble: VPS, Supabase (a free tier is named, with the caveat that production usage may exceed it), AI provider tokens, and the WhatsApp channel. The README discloses that the HostGator link is an affiliate link that supports the project and offers a discount, which is worth knowing when you read the recommendation. Before you commit, verify the automation cron exists after install, confirm your Supabase connection string is the Session pooler variant the installer expects, and test that WAHA holds a session across a restart. Those three checks correspond to the three things the README itself flags as failure points.

Editorial conclusion

Adopt DeskcommCRM if your sales happen in WhatsApp threads and you are willing to run a VPS, a Supabase project and a WAHA connection yourself, because the installer and the in-app updater are where the project has put its effort. Do not adopt it if you need a hosted product with a support contract, or if your channel is email and web chat rather than WhatsApp. Before committing, verify three things: that the Supabase connection string you supply is the Session pooler one the installer expects, that the automation cron was actually registered (without it the QUANDO/SE/ENTÃO rules sit in the queue), and that WAHA holds a stable session on your host, since an unstable session is the failure that no amount of CRM code can hide.

Official sources

1. License: MIT
2. melgarafael/DeskcommCRM on GitHub
3. Project website
4. README
5. Releases