Installing Salesforce alternative Twenty with Nuon

This is another post in our series where we show how to install a software vendor’s product with Nuon in a Bring Your Own Cloud (BYOC) way for stronger security and and a SaaS experience.

Twenty is a modern open-source CRM alternative to proprietary CRMs like Salesforce, HubSpot, Microsoft Dynamics 365, SAP, Oracle and Zoho. Think of Twenty as a more nimble, developer-friendly CRM option — one that leans into flexibility and lower cost.

The App Config almost entirely uses Kubernetes Manifests to deploy the Twenty app. Manifests are located in this GitHub repository and are maintained by the community.

What does Nuon do?

Nuon gives you a workflow to package your application, deploy it into customer accounts and make it feel like SaaS. With Nuon, you can continuously push updates, monitor and debug your application. We have designed Nuon with security first, and a zero-access model so your customer never has to grant you direct access to their account.

We deploy a runner alongside your application in a VM which powers the functionality of our platform. The runner is responsible for:

• Setting up and provisioning your application.
• Managing updates.
• Monitoring your application and letting you run debug scripts when things go wrong.

Nuon then gives you a control plane where you can push updates, debug when things go wrong, and proactively monitor for issues. You can offer a secure, automated experience without direct access to the customer account and toggle-able permissions for your customer.

Creating the App Config

An App Config is basically a collection of TOML files, Helm charts and Terraform to define the underlying infrastructure e.g., Kubernetes, and the Components to deploy an Application.

The Twenty App Config is in our example-app-configs GitHub repository.

Twenty Components and Architecture

Core Application Stack

Database Tier:

• PostgreSQL Database (twentycrm-db): Uses the specialized twentycrm/twenty-postgres-spilo image with persistent storage, configured with custom superuser credentials and optimized for CRM workloads.

Application Tier:

• Twenty Server (twentycrm-server): The main web application running on port 3000, using the official Twenty CRM Docker image with configurable release versions.
• Worker Process (twentycrm-worker): Background job processor for asynchronous tasks, sharing the same image but running in worker mode.
• Redis Cache (twentycrm-redis): In-memory data store for session management and caching.

Load Balancing & SSL:

• Application Load Balancer (ALB): AWS-managed load balancer with SSL termination using automatically provisioned certificates.
• Certificate Management: Automated SSL/TLS certificate provisioning for secure HTTPS access.

Infrastructure Configuration

Compute Resources:

• Configurable Kubernetes Nodes: Default setup uses t3a.medium instances with 4 desired to accommodate Twenty’s application and database pods.
• Resource Allocation: Each service has defined CPU/memory limits (256Mi-1024Mi RAM, 250m-1000m CPU).

Storage:

• Persistent Volumes: Separate persistent storage for database, server files, and Docker data.
• Local File Storage: Twenty CRM configured for local file storage within the Kubernetes cluster.

Security & Configuration Management

Secrets Management:

• Kubernetes Secrets: Secure storage of application secrets, database credentials, and JWT signing keys.
• Environment-based Configuration: Configurable PostgreSQL credentials, application secrets, and token expiration settings.

Network Security:

• Internal Service Communication: Services communicate within the twentycrm namespace using Kubernetes DNS.
• External Access: Only the ALB exposes the application publicly via HTTPS.

Traffic Flow Architecture

Internet → AWS ALB → Kubernetes Service → Pod

Public Internet Traffic arrives at the AWS Application Load Balancer

ALB terminates SSL/TLS and forwards HTTP traffic to the Kubernetes cluster

Kubernetes Ingress routes traffic to the internal twentycrm-server service

ClusterIP Service distributes traffic to the Twenty CRM server pods

Operational Features

Health Monitoring:

• Health Check Actions: Automated ALB health check validation to ensure application availability.

Installing Twenty in a Customer Cloud

The Twenty App Config and their TOML files are validated and uploaded to your Nuon control plane using the Nuon CLI.

git clone https://github.com/nuonco/example-app-configs
cd ~/example-app-configs/twenty
nuon login
nuon apps create -n twenty
nuon apps sync

The components are built as OCI artifacts and placed in a cloud container registry.

Through the Nuon web dashboard, an Install is kicked off and inputs provide defaults for the target installation.

A cloud provider stack is shared with the target cloud account profile which creates a VPC and a VM with the Nuon runner which phones home to get instructions or steps from the App Config to install the Twenty app.

Enterprise features include an Approvals workflow that asks the operator permission to proceed with an Apply step for each component in the App Config.

Once the installation is complete, the public URL is included in the Install’s README markdown in the Nuon dashboard and can be shared with the target cloud account user base to start using the Twenty application.

Conclusion

Software vendors like Twenty can invest in Nuon to unlock new revenue streams with customers who want a SaaS experience of instant access and no upgrade hassles while retaining their data in their cloud accounts.

Global 2000 companies and government agencies can invest in Nuon to package up and deploy all of their vendor and in-house developed apps for easier DevOps management, stronger security, and a SaaS-like multi-cloud experience.