mrkeyoor.com_
Fri 11 Sept 13:56 UTC
Self-Hostedevaluationupdated 11 Sept 2026

DeskcommCRM review

DeskcommCRM is a Portuguese-first, self-hosted sales CRM for teams that handle leads and conversations through WhatsApp; English and Spanish README translations are available. It combines contact management, WhatsApp channels, automation, and AI agents while keeping the application and customer data under the operator's control.

trackingstars / 7d
Verdict

Our build completed in 195 seconds after a 45-second install, but the repository exposed no test script or target for us to run. DeskcommCRM is worth a serious pilot for a Portuguese-speaking, WhatsApp-led sales team that already knows how to operate a VPS. Do not treat the polished installer as proof of low operational burden: production still spans messaging, a database, provider keys, DNS, HTTPS, backups, and updates.

We ran it

Install✓ · 45s923 packages · 1251 MB
Build✓ · 195s
Testsn/ano test script
Repo3951 files~504,872 lines of source · 86.2 MB · 7 CI workflows · Dockerfile · tests dir

Answers from our run

Does DeskcommCRM build from source?

Dependencies installed in 45 seconds (923 packages), and the build succeeded in 195 seconds. We cloned commit 30bd6f5 into a clean Debian container with 3 CPUs and no project-specific setup.

Does DeskcommCRM have tests you can run?

Not through a standard command: the project exposes no test script or target that our harness could run.

Who should not use DeskcommCRM?

Teams wanting a fully managed SaaS with vendor-operated uptime and support

What are the alternatives to DeskcommCRM?

Chatwoot, Twenty, EspoCRM. Our build completed in 195 seconds after a 45-second install, but the repository exposed no test script or target for us to run.

Setup4/5One-command path, but several external accounts are still required
Docs4/5Detailed VPS guidance with English and Spanish translations
Community3/5Active release and 1,089 stars, with 89 open issues
Maturity3/5Builds cleanly, but our run found no executable test target

Who it’s for

Brazilian sales teams that rely heavily on WhatsApp
Operators willing to manage a VPS, domain, Supabase, and provider keys
Small businesses that want an MIT-licensed alternative to subscription CRMs
Technical agencies that can own backups, upgrades, and channel operations

Who it’s NOT for

Teams wanting a fully managed SaaS with vendor-operated uptime and support
Buyers who cannot maintain Docker, DNS, secrets, and a production database
Organizations that require a proven automated test result before adoption
Global teams that need English-first product guidance throughout the project

Setup reality

Our sandbox install succeeded in 45 seconds, installing 923 packages and consuming 1,251 MB; the production build also succeeded in 195 seconds on 3 CPUs with 8 GB RAM. That is encouraging, but no tests script or target was available, so tests were skipped despite a tests directory and 7 CI workflow files. The README's one-command VPS path automates substantial work, yet a real deployment still requires Docker-capable hosting, DNS, Supabase credentials, an AI provider key, a WhatsApp number, and careful ownership of backups and upgrades.

It is a WhatsApp sales system, not just a contact list

DeskcommCRM comes from a clear Brazilian context: its main README and installation guidance are in Portuguese, with English and Spanish translations. The project positions version 1.18.1 as an open alternative to Kommo, Octadesk, and Intercom, built around WhatsApp sales rather than generic customer records. Its MIT license also gives agencies and internal teams room to adapt it.

The product combines a self-hosted CRM, WhatsApp connectivity, sales automation, and AI agents intended to answer, qualify, and sell. Its documented stack includes Next.js 16, strict TypeScript, and Supabase for Postgres, authentication, and storage. Operators can connect OpenRouter, Anthropic, or OpenAI while keeping the application and customer data on infrastructure they control.

What happened when we ran it

We cloned commit 30bd6f5 into a fresh, unprivileged Debian container with 3 CPUs and 8 GB RAM. Installation succeeded in 45 seconds through pnpm, bringing in 923 packages and using 1,251 MB on disk. The production build completed successfully in 195 seconds. That is a credible first run for 3,951 files, about 504,872 source lines, and an 86.2 MB checkout.

Testing is the unresolved part. The repository had a tests directory and 7 CI workflow files, but no tests script or target that our harness could execute, so tests were skipped. The successful build proves the build path worked in our container, not that message delivery, authentication, migrations, automation queues, or rollback behaved correctly.

The installer addresses real production chores

The strongest part of the pitch is the operational detail. The setup kit says it generates technical secrets, installs Postgres extensions, applies the baseline schema, creates the first administrator, starts the stack with HTTPS, installs the automation cron, and enables the update agent. The README recommends 4 GB RAM and provides both an idempotent interactive path and a prepared non-interactive mode.

Proxy handling reflects problems self-hosters actually encounter. The installer checks whether ports 80 and 443 are already occupied and adapts instead of blindly starting Caddy. For a host-network proxy configuration, it asks the operator rather than guessing. Updates can back up the database, move through visible stages, and roll back, while an agent checks requests every 5 minutes.

Onboarding still crosses several services. You need 1 Docker-capable VPS, a domain with an A record, Supabase credentials and a session-pooler string, an AI provider key, and a WhatsApp number connected by QR code or Meta's official channel. Optional 2-factor authentication uses Google Authenticator or Authy. This is manageable for an operator, not a no-ops experience.

The rough edges are operational and evidentiary

The dependency footprint is large: our installation placed 923 packages across 1,251 MB before the build. That is not automatically excessive for a full CRM, but it widens the maintenance surface. Docker and Compose files help packaging, yet operators should still scan images, control upgrades, protect environment files, and rehearse database restoration rather than assuming scripts cover every local change.

The missing executable test target is the clearest caution. A production build is not a regression suite for customer conversations. With 89 open issues, evaluators should inspect reports relevant to their exact WhatsApp channel and hosting pattern. The supplied evidence does not show response or closure times, so the issue count alone cannot establish either healthy engagement or neglect.

Language is another consideration. English documentation exists, making evaluation possible outside Brazil, but the primary material is Portuguese-first. A 3-language README set is welcome, although international teams should verify the deeper runbook and interface language. The promoted 1-command curl route is convenient; on a customer-data server, cloning and inspecting the local setup kit first is the more defensible practice.

Community activity is promising, not conclusive

The latest release, v1.18.1, and the last push both landed on 2026-09-11, which is strong evidence of current development. Seven CI workflow files show attention to automation, and the repository appeared in the supplied GitHub Trending item. None of that tells us how quickly maintainers review security reports, support upgrades, or resolve channel-specific breakage, so a pilot still needs its own acceptance checks.

The project has 1,089 stars and 89 open issues, enough visibility to suggest real interest but not enough evidence to infer a dependable support organization. The README is unusually candid about update-agent delays, rollback, proxy conflicts, and optional 2-factor authentication. That practical documentation raises confidence, while the absent runnable test result prevents a higher maturity judgment from our review.

Where it fits in a real stack

DeskcommCRM sits at the application layer, with Supabase holding data and identity, WhatsApp providing the customer channel, and OpenRouter, Anthropic, or OpenAI supplying AI capability. A reverse proxy and HTTPS expose it, while cron drives automation and the 5-minute update polling cycle. The recommended 4 GB VPS must be treated as production infrastructure, with monitoring, backups, access controls, and recovery ownership.

Choose it when WhatsApp is central to revenue work and your team can operate that 6-part chain of app, database, messaging, AI provider, proxy, and scheduled jobs. Avoid it when you want vendor-owned uptime or need a verified automated test baseline today. The 45-second install and 195-second build make a controlled pilot reasonable, but live adoption should follow channel, restore, migration, and rollback exercises.

Alternatives

ProjectWhat it isPick it when
Chatwoot gh↗An open-source customer support inbox with multiple messaging channels.Pick this instead when support operations and omnichannel inboxes matter more than a sales-first CRM.
Twenty gh↗A modern open-source CRM focused on flexible records and sales workflows.Pick this instead when you want a general-purpose CRM and WhatsApp is not the center of the workflow.
EspoCRMA mature open-source CRM with broad sales and business-management features.Pick this instead when established CRM breadth matters more than native AI-agent positioning.

What people are saying

  1. [github-trending] melgarafael/DeskcommCRM

Sources

  1. DeskcommCRM GitHub repository
  2. DeskcommCRM homepage

More self-hosted reviews

Douyin_TikTok_Download_API · halo · server · gpustack · ground-station · mastodon · the whole board →