Twenty: Open-Source CRM Built on Nx and TypeScript

Architecture and Monorepo Structure

The Twenty repository is organized as an Nx workspace that ties together more than twenty‑seven thousand source files and over 1.7 million lines of TypeScript‑heavy code. The monorepo splits the project into three top‑level folders – server, web and apps – each containing focused libraries for domain logic, API adapters and UI components. Server‑side code relies on NestJS and Express, exposing a GraphQL schema that is type‑generated and used to create a client SDK, while the web side ships React, Next.js and Angular applications that share ui libraries through the same Nx graph. All projects are written primarily in TypeScript, with ancillary files in JavaScript, Python, SQL, Shell, SCSS, CSS, HTML, JSON, YAML and Markdown. Testing lives alongside each library, powered by Jest for unit checks, Vitest for faster React unit tests and Playwright for end‑to‑end flows, yielding the reported 60 % test‑coverage baseline. Documentation is kept in Crowdin and rendered in more than ten languages, and the repository enforces Oxlint rules with CI‑driven auto‑fixes. Deployment assets include Dockerfiles, Kubernetes manifests and Helm charts that reference the platform’s reliance on PostgreSQL, Redis, BullMQ and a dozen third‑party services such as Recall, Fireflies, Slack, Linear and AWS S3. This Nx‑driven layout gives developers a visible dependency graph, atomic library versioning and a single place to run lint, test and build commands across the entire codebase.

Security Posture and Improvement Opportunities

Twenty’s architecture is solid, but the security posture shows clear gaps that can be closed with targeted automation and resilience patterns. The audit uncovered hardcoded test secrets such as test-secret-abc123 in the twenty‑partners module tests, indicating a risk of credential leakage if similar patterns appear in production code. No automated security scanning (SAST/DAST) is present in the CI pipeline, leaving the 922 dependencies unchecked for known vulnerabilities—a concern highlighted by the Dependabot configuration that sets open-pull-requests-limit: 0, which blocks routine security updates. External integrations with Recall, Fireflies, and People Data Labs lack circuit breakers, making the system vulnerable to cascading failures when those services experience downtime or latency spikes.

Improving the score from the current 68 in the production‑readiness security dimension requires concrete steps. Introduce a secret‑scanning step in GitHub Actions using tools like Snyk, Semgrep, or GitHub Advanced Security to catch hardcoded credentials before they merge. Add a dedicated security testing stage that runs dependency vulnerability scans and enforces failure thresholds. Apply the circuit breaker pattern—for example, with the opossum library—to all third‑party API calls, wrapping each Request with fallback logic and configurable time‑outs. These changes will directly address the critical findings, reduce the attack surface, and align the platform’s security posture with its otherwise strong architectural foundations.

Developer Experience: Testing, Documentation, and Tooling

Twenty’s developer experience is shaped by a testing foundation that records a test‑coverage sub‑score of 60, backed by Jest for unit tests, Vitest for faster unit runs, and Playwright for end‑to‑end scenarios. The Nx workspace lets the CI run these suites in parallel across GitHub Actions, giving quick feedback on the 1 725 466 lines of TypeScript that power the platform. Documentation is equally mature: the source is annotated and exported to Crowdin, producing translations in more than ten languages, while Oxlint enforces a strict linting rule set with auto‑fix capabilities that keep the codebase clean. GraphQL schemas are versioned and used to generate type‑safe client SDKs, reducing the gap between server contracts and frontend consumption. Tooling reinforces this flow – the monorepo is managed by Nx, which computes dependency graphs and enables incremental builds, and the repository uses TypeScript’s strict mode throughout, ensuring that every file benefits from compile‑time guarantees. CI pipelines also include cached Docker builds and Helm charts for Kubernetes, allowing developers to spin up a local stack that mirrors production. Together, these testing, documentation, and tooling practices give teams a reliable baseline for iterating on the CRM’s complex domain logic.

Production Readiness: Observability, CI/CD, and Deployment

Twenty already ships a solid foundation for operating in production. Its observability score sits at 65 out of 100, reflecting basic logging and metric collection but lacking distributed tracing; the recommendations call for adding OpenTelemetry instrumentation across services to close that gap. The project relies on GitHub Actions for its CI/CD, running parallel test execution powered by the Nx monorepo tooling, which keeps build times low despite a large codebase. Docker images are built and paired with Kubernetes Helm charts that define reusable production deployments for the API, worker, and frontend services. However, the current pipeline shows no evidence of automated secret scanning or dependency vulnerability checks, and Dependabot is configured with open-pull-requests-limit:0, preventing routine security updates from being raised. To move toward a truly production‑ready state, the team should introduce a security stage that runs tools such as Snyk or Semgrep, enable secret detection to catch hard‑coded test values like 'test-secret-abc123', and add circuit breaker patterns (for example opossum) around external calls to Recall, Fireflies, and People Data Labs. These changes would raise the observability and security sub‑scores while preserving the existing strength of the CI/CD workflow.

Extensibility: Third‑Party Integrations and API Design

Twenty’s extensibility hinges on a library of over a dozen third‑party services that are called from its NestJS backend and React front‑end. The metadata shows integrations with PostgreSQL, Redis, BullMQ, Recall, Fireflies, People Data Labs, Slack, Linear, Discord, Google APIs, Microsoft Graph, Stripe, AWS S3, AWS SES, Sentry and Crowdin, giving the platform a broad SaaS‑ecosystem footprint. Each integration lives behind a dedicated adapter in the apps or libs folders, and the GraphQL schema generates strongly typed client SDKs that consume these services.

However, the security audit notes three concrete gaps: hardcoded test secrets in the twenty‑partners module tests, the absence of any automated SAST/DAST stage in the CI pipeline, and missing circuit breaker patterns for external calls to Recall, Fireflies and People Data Labs. The recommendations therefore prescribe adding a secret‑scanning step using tools such as Semgrep or GitHub Advanced Security, wrapping every outbound HTTP request with a resilience library like opossum, and publishing OpenAPI specifications for all REST‑ish endpoints alongside the existing GraphQL definitions. Implementing these changes would tighten the contract between Twenty and its partners while reducing the risk of credential leakage and cascade failures.