Twenty: A CRM You Can Version, Ship, and Extend with Code

What Twenty Actually Replaces

Twenty is positioned as the open alternative to Salesforce, but the README narrows that claim quickly. It is built for technical teams, not for sales operations staff who want a point-and-click admin. The pitch is that a CRM should be something you build, ship, and version like the rest of your stack. That means the target user is a developer or a team with engineering capacity. The problem it solves is the gap between rigid, closed CRM platforms and the need for a system that adapts as business processes change. Instead of clicking through a setup wizard, you define your data model in TypeScript files and deploy them. That is a fundamentally different workflow from Salesforce, where configuration lives inside the vendor's cloud and changes are tracked through their own release mechanisms.

The Data Model as Code Mechanism

The core mechanism is visible in the README's example. You import defineObject and FieldType from 'twenty-sdk/define', then declare an object with a singular name, a plural name, labels, and an array of fields. Each field has a name, a label, and a type like TEXT, CURRENCY, or DATE_TIME. This is not a drag-and-drop schema builder. It is a code-first schema that lives in your repository. The README also mentions 'objects, views, workflows, and agents' as building blocks, and it says you can extend them as code. The data flow is straightforward: you write TypeScript, run a CLI command to publish, and the app ships to your Twenty workspace. There is no mention of how migrations are handled or what happens when you change a field type after data exists. That is a gap the documentation would need to answer, but the design intent is clear: the schema is a versioned artifact.

Getting Running: Cloud, CLI, and Self-Hosting

Three installation paths appear in the README. The cloud route is the fastest: sign up at twenty.com and spin up a workspace in under a minute, with no infrastructure to manage. The second path is building an app with the CLI. You run npx create-twenty-app my-app to scaffold a project. Then you define objects as code, as shown in the example. Finally you run npx twenty app:publish --private to ship it to your workspace. The third path is self-hosting with Docker Compose, linked from the documentation. The README also points to a local setup guide for contributors. There is no mention of a specific Docker command, but the compose file is referenced. The presence of three paths suggests the project expects both managed and self-managed users. The CLI is the bridge between the two: you can develop against a cloud workspace or a self-hosted one, presumably.

The Stack and What It Implies for Operations

The README lists the stack: TypeScript, Nx, NestJS, BullMQ, PostgreSQL, Redis, React, Jotai, Linaria, and Lingui. That is a heavy set. A self-hosted deployment is not a single binary. You need PostgreSQL for persistence, Redis for queues, and BullMQ for background jobs. The backend is NestJS, which is a structured Node framework. The frontend is React with Jotai for state and Linaria for CSS-in-JS. This is a modern but operationally demanding stack. If you are considering self-hosting, you are not just running a CRM; you are running a distributed system with a queue broker and a relational database. The README does not give system requirements or a reference architecture beyond the Docker Compose link. That is a real consideration for teams without dedicated infrastructure experience.

Where Twenty Is the Wrong Tool

Twenty is not for everyone. If your sales team expects to configure fields and picklists through a GUI without touching code, this is the wrong fit. The entire pitch is code-first. The README says 'the CRM you build, ship, and version like the rest of your stack.' That implies a development workflow, code review, and deployment pipeline. Non-technical CRM administrators would be lost. Also, the README does not mention any migration tooling or rollback strategy for published apps. If you change a field type from TEXT to CURRENCY, what happens to existing records? The documentation might cover that, but the README does not. That is a potential failure mode for production use. The project also depends on Redis and BullMQ, so if you cannot run those in your environment, self-hosting is not viable.

A Real Alternative: Salesforce Itself

The obvious alternative is Salesforce, which Twenty explicitly targets. The difference in approach is stark. Salesforce uses a declarative, point-and-click configuration model where admins build objects, fields, and workflows in a web interface. Changes are deployed through change sets or a metadata API, but the primary interface is not code. Twenty inverts that: the schema is TypeScript, and deployment is a CLI command. For teams that already use infrastructure-as-code and version-controlled schemas, Twenty fits naturally. For teams that rely on Salesforce's vast ecosystem of AppExchange packages and its mature permission model, Twenty is a much younger project with a smaller ecosystem. The README does not mention any migration tool from Salesforce, so switching would mean rebuilding your data model in code. That is a significant effort.

Maintenance, Upgrades, and License Uncertainty

The repository shows active development with releases like v2.37.0 and v2.35.0 in late August 2026, which suggests a steady release cadence. However, the license field is marked unknown. That is a serious issue for enterprise adoption. You cannot legally adopt a project without knowing its license terms. The README does not state a license either. Before using Twenty, you must check the repository for a LICENSE file or contact the maintainers. The maintenance cost is also tied to the stack. Upgrading a NestJS and React monorepo with Nx is not trivial. The README mentions version control for apps as a feature, which implies you can roll back published versions, but how that works is not detailed. The self-hosting path means you own the upgrade process, including database migrations and Redis compatibility. This is not a set-and-forget system.

Editorial conclusion

Adopt Twenty if your team wants a CRM that is versioned, tested, and deployed through the same pipelines as your application code, and if you are comfortable with TypeScript, PostgreSQL, and Redis. Do not adopt it if you need a no-code CRM for non-technical staff or if you cannot commit to maintaining a self-hosted stack. Before adopting, verify the current license, which is not stated in the repository, and confirm that the app publishing and version control features work with your CI/CD setup. The project is actively developed with frequent releases, but its value depends entirely on whether your team treats the CRM as code.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes