Twenty vs EspoCRM

Twenty and EspoCRM are both open-source CRMs you can self-host instead of paying for Salesforce or HubSpot, and both cover the same core ground — contacts, companies, deals, pipelines. That's where the similarity ends. One is a from-scratch rebuild of what a CRM data model should look like in 2026; the other is a mature, traditional CRM that happens to be free and self-hostable. Picking between them is really picking between two different philosophies of what a CRM's UI owes you.

Same job, different weight class

Twenty is a TypeScript/NestJS/React application, built on Postgres with a GraphQL API in front of it. It's the newer of the two, rates a 3 out of 5 to deploy, needs 2 GB of RAM at minimum, and is mostly AGPL-3.0 licensed — files marked Enterprise, including its SSO and audit-log code, sit under a commercial licence instead. It's explicitly positioned as an open alternative to Salesforce, and it looks the part: a Notion-like interface where records, fields, and views are all first-class, editable objects rather than settings buried three menus deep.

EspoCRM is a PHP/JavaScript application, older and more established, running on a traditional MariaDB backend. It rates a 2 out of 5 to deploy, runs comfortably in 1 GB of RAM, and shares the same AGPL-3.0 license — so licensing is close to a wash, bar Twenty's Enterprise-marked files. The gap is in stack and resource footprint: EspoCRM is a classic LAMP-shaped app, and Twenty is a modern Node/React stack with the RAM appetite that comes with it.

Data model & UI: reinvented vs. refined

This is the real dividing line between the two projects.

• Twenty treats the entire CRM as a customizable object graph. Every record type — contacts, companies, opportunities, or anything you define — is a first-class object with fields you add, remove, and reshape without touching code, surfaced through views that feel closer to a Notion database than a form-driven enterprise app. The GraphQL API means every custom object you create is immediately queryable, which matters if you're building integrations or an internal tool on top of the CRM data. The trade-off is that this flexibility is still new: workflows and reporting are less deep than a CRM that's had a decade to accumulate them.
• EspoCRM takes the traditional path, but with a genuinely good visual entity and relationship builder — you can define custom entities, link them to existing ones, and adjust layouts through an admin UI without writing PHP. It's less "everything is a flexible object" and more "the standard CRM modules, plus a real schema editor when you need to extend them." Sales pipelines, marketing campaigns, and support cases are all built in and mature, not bolted on.

If you want a CRM that feels like your team's internal tool and is willing to accept some rough edges for it, that's Twenty. If you want the standard CRM feature set with a well-worn customization path, that's EspoCRM.

Architecture & install

Both ship official Docker paths, but the shape is different.

• Twenty installs from the official docker-compose.yml, pulling in a separate worker container, Postgres and Redis, with generated secrets (PG_DATABASE_PASSWORD, ENCRYPTION_KEY) via openssl rand. It's a single compose file, but the NestJS/React/GraphQL stack underneath is heavier, which is where the higher 2 GB RAM floor and 3 out of 5 difficulty rating come from.
• EspoCRM installs from the official espocrm/espocrm image plus a MariaDB container — standard LAMP-in-Docker. The one wrinkle worth knowing is the third container: a espocrm-daemon service running the same image with docker-daemon.sh as its entrypoint, dedicated to background jobs like email sync and workflow processing. Forget that container and the app still loads, but scheduled workflows and inbound email silently stop working — it's not optional infrastructure.

Neither install is hard, but EspoCRM's is the more forgiving one: fewer moving parts, lower RAM, and a stack (PHP + MariaDB) most self-hosters have debugged before.

Maturity & community

EspoCRM has been around considerably longer and it shows in the ecosystem: more extensions, more community-written guides, and a support forum with years of accumulated answers for edge cases. Twenty is younger and moving fast — its GitHub activity and funding are real signals of momentum, but the extension ecosystem and troubleshooting corpus are both thinner simply because there's been less time to build them. If something breaks at 11 p.m., EspoCRM is more likely to already have a forum thread; with Twenty you're more likely to be reading the source or filing an issue.

Which should you self-host?

Pick Twenty if…

• You want a modern, highly customizable data model — objects, fields, and views you can reshape without code, plus a GraphQL API for building on top of.
• Your team is comfortable in a TypeScript/React stack and doesn't mind a younger project with a smaller extension ecosystem.
• You have the 2 GB+ RAM headroom to spare and want a CRM that feels like an internal tool rather than an enterprise form.

Pick EspoCRM if…

• You want a lighter, cheaper-to-run CRM — it fits in 1 GB of RAM and deploys at a 2 out of 5 difficulty.
• You'd rather get traditional CRM workflows — sales pipelines, campaigns, support cases — working on day one than build your data model from scratch.
• You want the deeper bench of community extensions and documentation that comes with an established, PHP-based project.

Running either on a VPS

Both are within reach of a small VPS, but the sizing conversation isn't identical. EspoCRM's 1 GB floor fits the cheapest tier most providers sell; budget a bit more in practice once MariaDB and the daemon container are running alongside it. Twenty's 2 GB floor is a harder requirement — undersize it and the NestJS backend will be the first thing to struggle. Whichever you pick, if you're running EspoCRM, don't skip the espocrm-daemon container in your compose file — it's easy to omit and the symptom (workflows and email sync silently not running) is easy to miss until you go looking for it. If what you actually need is a support queue rather than a CRM, see Chatwoot vs Zammad.