DeskcommCRM: a self-hosted WhatsApp CRM with native AI agents

The problem DeskcommCRM targets: chat sales with no system of record

Small and mid-sized Brazilian businesses often run their entire sales operation inside WhatsApp. The conversation history lives on a phone, the follow-up depends on someone remembering, and the CRM, if there is one, is a separate tab nobody updates. DeskcommCRM is aimed at that gap. The README describes it as an open-source sales operating system with AI agents that attend, qualify and sell on WhatsApp, inside a CRM running on your own server, and frames the pitch against Kommo, Octadesk and Intercom with the line "Sem mensalidade, sem feature travada, seus dados com você".

The audience is narrower than "any business that sells by chat". The install documentation is written for someone who can open a terminal, SSH into a VPS and paste commands, and who has or can create a Supabase account and an LLM key. The README is published in Portuguese, English and Spanish, with the Portuguese version as the default, which says something about the primary market. If your team has no one comfortable with a shell, the installer's interactive prompts will not save you from that.

How the pieces fit: Next.js app, Supabase, WAHA and separate workers

The repository layout shows a Next.js 16 application in TypeScript, with Supabase providing Postgres, Auth and Storage. WhatsApp connectivity comes from WAHA, the WhatsApp HTTP API, and the local docker-compose.yml runs only that dependency, using the devlikeapro/waha:noweb image on host port 3030 mapped to container port 3000. The comment in that file notes that port 3000 is reserved for other dev tools, and that in production WAHA runs on a dedicated VPS behind Nginx with proxy_buffering off for SSE.

The webhook contract is explicit. WAHA is configured with WHATSAPP_HOOK_URL pointing at /api/v1/webhooks/waha, and WHATSAPP_HOOK_EVENTS lists message.any, message.ack, message.edited, message.revoked, session.status and state.change. Payloads are signed with an HMAC SHA512 secret, which the compose file says is validated server-side with crypto.timingSafeEqual. The API key is stored as a SHA512 hex hash, not plaintext, while the client sends the plaintext key in the X-Api-Key header.

Beyond the app image there are Dockerfile.scheduler and Dockerfile.worker, so automation and agent work run outside the request path. The package.json shows a db:reset script backed by supabase db reset and a db:migrate script whose body is still a TODO placeholder, which tells you schema changes are applied from supabase/baseline.sql rather than a migration chain. That is a real design decision worth knowing before you plan upgrades.

Installing DeskcommCRM on a VPS and connecting WhatsApp

The primary install path is a VPS with Docker. The README's first step is to connect from your own machine, replacing the port and IP the host sent you. If the host did not mention a port, it is 22 and can be omitted.

ssh -p PORTA root@SEU_IP

Once inside the server, clone the repository and run the installer. The README states you do not install Node or pnpm and do not compile anything, because the app image ships prebuilt; if Docker is missing, the installer asks and installs it.

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

The installer asks only for what is yours (domain, keys, admin password), validates each answer before continuing, generates the technical secrets itself, creates the Postgres extensions and applies supabase/baseline.sql, creates the first admin, brings the stack up with automatic HTTPS and checks health at the end. It also installs the automation cron and the update agent. The README states that running it again does not break anything because install.sh is idempotent.

For unattended runs, copy .env.hostgator.example to .env, fill it in and pass --yes.

bash hostgator-setup-kit/install.sh --yes

Before you start, the README lists what you need: a Docker-capable VPS with 4 GB of RAM recommended, a domain with an A record pointing at the VPS IP, a free Supabase account with three keys plus the Session pooler connection string, an OpenRouter, Anthropic or OpenAI key, and your WhatsApp number. The installer can create the Supabase project itself if you export SUPABASE_ACCESS_TOKEN first. After install, open https://<your-domain>, sign in as admin, and scan the WhatsApp QR code during onboarding. Two-factor authentication is optional and lives under Settings, Security; the first login does not require it.

Where the one-command story stops being one command

The installer's self-detection is the part most likely to bite. The README says that if your VPS already runs its own reverse proxy on ports 80 and 443, the installer detects it and publishes the CRM through that proxy instead of starting a Caddy that would not fit. In one specific case, a proxy running in --network host as Hostinger does, it asks rather than guesses, because publishing behind the wrong proxy installs a silent site "com sucesso". That is an honest admission that the happy path assumes a clean VPS.

The bigger limitation is operational. This is a self-hosted system with four moving parts: the Next.js app, Supabase (cloud or local), WAHA and the scheduler and worker containers. Nothing in the README suggests a managed fallback. If WAHA loses its WhatsApp session, if the Supabase project pauses, or if the cron stops, the CRM keeps rendering pages while conversations and automations quietly stop flowing. The README flags one of these directly: without the cron installed by the installer, the QUANDO/SE/ENTÃO rules stay parked in the queue.

There is also a hosting incentive to read carefully. The README promotes a HostGator VPS through a partner link and says signing through it supports the project and costs less. That does not make the software worse, but it means the recommended environment and the project's funding are the same decision, and you should evaluate the VPS on its own merits. Finally, if your sales happen over email, web forms or a marketplace inbox rather than WhatsApp, the product's center of gravity is somewhere you do not operate.

DeskcommCRM compared with Chatwoot and with hosted CRMs

The README names Kommo, Octadesk and Intercom as the closed alternatives it targets. The difference is not features so much as who holds the data and who pays per seat. Those products host your conversations and bill monthly; DeskcommCRM asks you to run Postgres through Supabase and a WhatsApp bridge yourself, and in exchange the README promises no monthly fee and no locked features.

A closer open-source comparison is Chatwoot, which is also self-hosted and also routes WhatsApp and other channels into a shared inbox. The architectural difference is where the intelligence sits. Chatwoot's model is agent-assisted support: humans answer, the tool organizes. DeskcommCRM's stated model is AI agents that attend and qualify first, with the CRM and the automation engine built around that, which is why the repository carries worker and scheduler images and an MCP-ready, multi-tenant posture. If you want a mature shared inbox with a large integration catalog, Chatwoot is the more conventional choice. If you want the agent in the driver's seat and are willing to own the WhatsApp bridge, DeskcommCRM is built for that shape.

One caveat on the closed comparison: the README does not publish a feature-by-feature matrix against Kommo, Octadesk or Intercom, so treat "open alternative" as a positioning statement about licensing and hosting, not a verified parity claim.

Licence, maintenance and what an upgrade actually costs

The licence is MIT, declared in LICENSE and on the README badge. In practice that means you can run, modify and redistribute the code, including commercially, provided the copyright notice and permission notice travel with it. It does not give you support, warranty or an indemnity, and it does not cover the third-party services the system depends on: Supabase, your LLM provider and WAHA each carry their own terms, and WAHA itself is distributed as a separate image with its own licensing. Nothing here is legal advice; if you resell the CRM, read the MIT text and each dependency's terms yourself.

Maintenance looks current. The last push to the repository was on 2026-09-10, and releases v1.17.0, v1.16.1 and v1.16.0 were published on 2026-09-08, 2026-09-07 and 2026-09-07 respectively. The repository is not archived. That is a fast release cadence, and it cuts both ways: you get fixes quickly, and you inherit the upgrade work quickly too.

The upgrade path is deliberately split. The README describes a screen-driven route, where the sidebar footer shows "Nova versão" only to the server owner, leading to Settings, Update. That route depends on the update agent the installer sets up, so if you skipped the installer you do not have the button. The alternative is the shell. Because db:migrate in package.json is still a TODO stub and schema is applied from supabase/baseline.sql, you should confirm how a given release expects the database to change before pulling a new image, rather than assuming a migration runs for you.

Editorial conclusion

Adopt DeskcommCRM if you sell through WhatsApp, want the conversation data on infrastructure you control, and can supply a Docker-capable VPS, a Supabase project and an OpenRouter, Anthropic or OpenAI key. Do not adopt it if you need a vendor to answer the phone when the stack breaks, or if you only sell through email and web forms, because the product is built around chat. Before committing, verify three things: that your VPS has the recommended 4 GB of RAM and that ports 80 and 443 are free or fronted by a proxy the installer can detect, that the Supabase connection string you supply is the Session pooler one the installer asks for, and that the cron installed by install.sh is actually running, since the README states that without it the QUANDO/SE/ENTÃO automation rules sit in the queue.

Frequently asked questions

Official sources

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