Frappe CRM: an AGPL-3.0 CRM built on the Frappe framework

What Frappe CRM replaces, and for whom

The README frames the project as a reaction to CRM pricing and complexity: many existing CRMs are, in its words, "either too complex, overly generic, or locked behind steep pricing models". The target user is a sales team that wants lead and deal tracking without a per-seat contract. The README states the tool is designed for modern sales teams with unlimited users, which is the sharpest thing about the positioning: seat count is not a billing unit here, because you host it.

The functional surface is deliberately narrow. Leads and deals live on a single page that collects activities, comments, notes and tasks. A Kanban board moves records between stages by drag and drop. Custom views apply filters, sorting and columns to lead and deal lists. Nothing in the README describes quoting, territory management, forecasting or marketing automation, so a team that needs those should treat this as a pipeline tool rather than a full revenue platform.

It is also a Frappe app before it is a product. That matters for who should read further: if you have never run a Frappe bench, the install section below is longer than you expect, and the payoff is a CRM bolted onto a general-purpose low-code framework you can extend.

Inside the repository: Vue 3 frontend, Python app, Frappe underneath

The repository layout separates a Python app directory (crm/) from a Vue frontend (frontend/), with frappe-ui vendored as a git submodule. The README names the two pillars under the hood: the Frappe framework as the full-stack web application framework, and Frappe UI as the Vue-based UI library. The primary language listed for the repository is Vue, which matches where most of the interface work happens.

Build wiring is explicit in pyproject.toml. The [tool.bench.assets] block sets build_dir to ./frontend, out_dir to ../crm/public/frontend, and index_html_path to ../crm/www/crm.html. In practice that means the compiled Vue bundle is emitted into the Python app's public directory and served through a single HTML entry point. The root package.json is private and only orchestrates: its dev script cds into frontend and runs yarn dev, its build script does the same with yarn build, and a postinstall hook installs the frontend dependencies.

Server-side dependencies are short. pyproject.toml requires Python 3.10 or newer and declares twilio==8.5.0, requests>=2.28.0 and tldextract>=5.0.0. Frappe itself is not declared there; a comment says it is "Installed and managed by bench", and [tool.bench.frappe-dependencies] pins frappe to >=16.0.0-dev,<=17.0.0-dev. The tldextract comment is worth reading: it is used for the enrichment crawler's same-site scoping, pinned to its bundled public suffix list snapshot so no network fetch happens at runtime. If you were expecting a crawler that phones home for domain data, that comment says otherwise.

Installing Frappe CRM in production with the easy-install script

The README documents two production paths. The managed one is Frappe Cloud, the project's official hosting service, with a signup link. The self-hosted one downloads a script and runs a deploy command. The README says the script sets up a production-ready instance with the necessary configurations in about five minutes; that is the project's own estimate, not a measurement.

First fetch the script:

wget https://frappe.io/easy-install.py

Then run the deployment, substituting your own email address and domain for the placeholders:

python3 ./easy-install.py deploy \
    --project=crm_prod_setup \
    --email=email.example.com \
    --image=ghcr.io/frappe/crm \
    --version=stable \
    --app=crm \
    --sitename subdomain.domain.tld

The README tells you to replace email.example.com with your email address and subdomain.domain.tld with the domain the CRM will be hosted on. The remaining flags are given as shown: the project name, the container image ghcr.io/frappe/crm, the stable version channel, and the app name crm. What you should see afterwards is a running site at your domain, backed by that image.

For local development the README is shorter and assumes a Frappe bench already exists. It points to the framework installation docs, then says to run bench start inside the frappe-bench directory and keep it running, then open a new terminal session and cd into frappe-bench. The README excerpt ends there, so the remaining development steps are not documented in the excerpt available here. The root package.json gives the frontend side of that loop: yarn dev, or npm run dev, which cds into frontend and starts the Vue dev server.

Calling, messaging and ERPNext: what the integrations actually require

Four integrations are listed, and they are not equal in effort. Twilio and Exotel are described as built-in: you configure them to make and receive calls from the CRM, and call recording is supported. Exotel routes calls through an agent's mobile phone rather than a browser session, which is a different operational model from Twilio's and worth checking against how your sales team actually works.

WhatsApp is not built in. The README says the Frappe WhatsApp app (shridarpatil/frappe_whatsapp) is used for sending and receiving messages. That means a second Frappe app to install and maintain, and a second project's release cadence to track. If WhatsApp is central to your sales process, this is the integration to evaluate first, because it is the one with an external dependency the CRM repository does not control.

ERPNext integration extends the CRM to invoicing and accounting. The compatibility table lists ERPNext branches alongside Frappe branches, so the version you pair is a decision, not a default. Note the table's own labels: main, which is v1.x, is marked stable and pairs with Frappe v15.x and v16.x; develop, described as future/v2.x, is marked unstable and pairs with the develop branches of Frappe and ERPNext, described as future/v17. The repository's default branch is develop, so a git clone gives you the unstable line unless you switch.

Where Frappe CRM is the wrong choice

The framework dependency is the first real limitation. Frappe CRM is not a standalone application you drop on a server; it is a Frappe app, and the development instructions begin with setting up a bench. Teams without Frappe or Python operational experience inherit the framework's upgrade path along with the CRM. The pyproject.toml constraint on frappe, >=16.0.0-dev,<=17.0.0-dev, shows how tightly coupled the two are: a Frappe version bump is a CRM compatibility question.

The README does not document rollback, backup and restore procedures, or a data migration path away from the CRM. None of that appears in the README, so treat export and exit planning as something you would have to establish yourself before committing pipeline data. That is a genuine gap for a system of record.

The feature set is thin by design. There is no mention of forecasting, quote generation, territory assignment, marketing campaigns or a mobile application in the README. If your evaluation criteria include those, the project's own documentation does not claim to meet them, and you should not assume a Frappe app exists to fill each hole.

Finally, the licence is AGPL-3.0 for the repository, while the root package.json records GPL-3.0. That discrepancy is in the files themselves. AGPL-3.0 carries network-use obligations that GPL-3.0 does not, so if you plan to modify the code and expose it to users over a network, read the LICENSE file in the repository rather than the package metadata.

Frappe CRM against ERPNext CRM, Salesforce and Odoo

The most common comparison is with ERPNext, and it is not really a competitor: the README presents ERPNext as an integration target, extending CRM capabilities to invoicing and accounting. If you already run ERPNext, the CRM is an adjacent app on the same framework, and the compatibility table tells you which branches to pair. Choosing ERPNext's own CRM module instead keeps everything in one app but gives up the standalone Vue interface this project builds.

Against Salesforce the difference is structural rather than feature-by-feature. Salesforce is a hosted platform with per-seat pricing; Frappe CRM is code you deploy, with unlimited users as a stated design goal and no vendor seat meter. What you trade is operational responsibility: upgrades, backups, uptime and the Frappe version treadmill become yours, or Frappe Cloud's if you take the managed path. The README does not publish a feature comparison against Salesforce, so any capability gap you care about has to be checked against the documentation at docs.frappe.io/crm.

Odoo and Twenty sit closer in spirit, both open source and self-hostable. The distinguishing detail here is the substrate. Odoo brings its own app ecosystem and ORM; Twenty is a standalone CRM codebase. Frappe CRM's extensibility comes from Frappe's doctype model and low-code tooling, which is an advantage if your team already writes Frappe apps and a new stack to learn if it does not. There is a live demo at frappecrm-demo.frappe.cloud if you want to see the interface before committing to an install.

Maintenance cost, release cadence and licence obligations

The repository is not archived, and the last push was on 2026-09-23. Releases are frequent: v1.83.0 on 2026-09-02, v1.84.0 on 2026-09-15 and v1.85.0 on 2026-09-23. A cadence that tight means the stable line moves often, and the compatibility table is the thing to watch, because the CRM branch, the Frappe branch and the ERPNext branch have to agree.

Upgrade cost is therefore a version-matrix problem rather than a single command. The pyproject.toml bound on frappe, >=16.0.0-dev,<=17.0.0-dev, sets the window you can upgrade within, and the table separates the stable v1.x line on Frappe v15.x and v16.x from the unstable future/v2.x line on the develop branches. Running the default develop branch in production puts you on the line the project itself labels unstable.

On licensing: the repository is AGPL-3.0. The root package.json lists GPL-3.0, and both appear in the files, so read LICENSE for the authoritative text. AGPL-3.0 is a copyleft licence with a network clause, which is relevant to anyone modifying the code and serving it to users. This is not legal advice; if your organisation has rules about copyleft software in production, route the decision through whoever owns that policy.

Editorial conclusion

Adopt Frappe CRM if you already run Frappe or ERPNext and want lead and deal management with unlimited users on your own server; the compatibility table ties the stable v1.x branch to Frappe v15.x and v16.x, and the develop branch is labelled unstable for a future v17. Do not adopt it if you want a standalone CRM with no framework underneath, since installation goes through bench. Verify first that your Frappe branch matches the table, that your Twilio or Exotel account exists if you want calling, and that you accept AGPL-3.0 obligations for the code you run.

Frequently asked questions

Official sources

1. frappe/crm on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases