Choose Docker Compose or Kubernetes for Twenty?
If you are deciding how to run self-hosted Twenty, start with the documented path. Docker Compose is the deployment the core team documents and supports, and it runs the server, the worker, PostgreSQL and Redis together on one stack. The Helm chart for Kubernetes is community-maintained, so its support boundary sits with whoever publishes and patches it. Compose fits a team that wants a supported single-host install it can back up, upgrade and troubleshoot with a small set of moving parts, provided the host has at least 2 GB of RAM as the Twenty self-hosting guide requires, and provided you accept that scaling is largely a matter of resizing that host.
Kubernetes is worth its cost when you already run a cluster with trained operators, when you need the server and worker scheduled, scaled and restarted by a platform your organization already monitors, or when your policy requires workloads to follow the same deployment and admission controls as everything else. Each of those advantages only holds if the team can own the chart version, its values files and its upgrade path. Confirm with the chart maintainer which Twenty releases it tracks, how quickly it follows them, and what it does with your PostgreSQL and Redis, because those decisions are not covered by the core team's support.
Kubernetes also adds burden that has to be justified on its own terms. You take on cluster lifecycle, certificates, etcd and Secrets handling, which Kubernetes stores unencrypted in etcd by default unless you configure encryption at rest. If the database and cache stay inside the cluster, you also own their backups and failover. Before choosing Kubernetes, write down who patches the cluster, who restores PostgreSQL, and who owns the chart, and treat any gap in that list as a reason to stay on Compose.
How the two deployment models compare for Twenty
This table compares the core-team Docker Compose guide with the community-maintained Helm chart on support boundaries, components, scaling, failover, upgrades, secrets, skills and cost drivers. Read each row as a question to settle with Twenty or your platform team before choosing. The main takeaway is that Compose keeps the footprint small and the support boundary clear, while Kubernetes adds cluster duties you own before Twenty runs at all.
| Area | Docker Compose (core-team guide) | Kubernetes (community Helm chart) |
|---|---|---|
| Support boundary | Covered by Twenty's own self-hosting guide for the Compose stack | Community-maintained chart; confirm which parts, versions and upgrades Twenty will support |
| Components run | Server, worker, PostgreSQL and Redis defined in the Compose setup | Chart deploys the Twenty workloads; confirm whether PostgreSQL and Redis are bundled or external |
| Scaling server and worker | Scaling depends on host capacity; confirm whether the guide supports multiple replicas | Replica counts set through chart values; confirm worker behavior with BullMQ jobs and shared Redis |
| Availability and failover | Single host by default, so a host failure stops every component | Cluster HA is separate from app HA; kubeadm HA asks for at least three control plane nodes and a TCP load balancer on port 6443 |
| Upgrade path | Move to a new Twenty release, which ships often; confirm migration steps for each release | Two layers to upgrade: the cluster (one minor version at a time) and the chart; confirm chart-to-release mapping |
| Secrets and access control | Secrets handled through the host configuration; confirm how the guide recommends storing them | Kubernetes Secrets sit unencrypted in etcd by default; enable encryption at rest and least-privilege RBAC |
| Required skills | Docker, Linux host hardening, PostgreSQL and Redis administration | Cluster administration, etcd snapshot backups, RBAC, Pod Security Standards and networking |
| What drives cost | Host size (at least 2 GB RAM per the guide), storage, backups and staff time | Control plane and worker nodes, etcd backups, upgrade effort and platform staff time; request a scoped quote |
What each deployment runs and where state lives
Both deployments run the same Twenty components, but Kubernetes adds a control plane whose own state needs protecting. The cards below set out what the Compose stack contains, what the Helm chart changes, where PostgreSQL and Redis can sit, and how the backend uses them. Confirm each chart detail with its maintainers before you rely on it.
Compose stack and memory floor
The Docker Compose guide runs a server, a worker, PostgreSQL and Redis on a single host and asks for at least 2 GB of RAM. The guide's reason matters: insufficient memory can crash processes. A host sized at the minimum has little headroom for worker jobs during imports or bulk updates, so measure memory under your real workload before you fix the host size. Also ask the core team how they recommend scaling the worker.
Helm chart topology
The community-maintained Helm chart maps the same Twenty components onto Kubernetes workloads, so the server, worker, PostgreSQL and Redis each need a placement decision. Confirm how the chart maps the server and worker, which Kubernetes versions it tests against, and which values combinations its maintainers support. Those answers decide whether a chart upgrade is routine or a project your team owns.
PostgreSQL and Redis placement
PostgreSQL and Redis can run inside the cluster as chart-managed workloads or outside it as separately operated services. Inside the cluster, your team owns storage classes, backups and failover. Outside it, you own network paths, credentials and recovery through another system. BullMQ jobs are stored in Redis, so a Redis outage stalls background work even when PostgreSQL is healthy. Confirm which placements the chart supports.
Backend stack and APIs
Twenty's backend runs on NestJS with BullMQ, PostgreSQL and Redis, and its React frontend talks to GraphQL and REST APIs. The server and worker share these data stores, so scaling either one changes load on PostgreSQL and Redis. Review that shared load before you add replicas. Integrations built on the REST or GraphQL endpoints also depend on how your ingress routes traffic into the cluster.
Cluster state in etcd
A self-managed Kubernetes cluster keeps its own state in etcd, which needs an odd number of members, and the project recommends five members in production. A kubeadm high availability setup needs at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443. You also need a tested backup routine using etcdctl snapshot save. This layer exists only because you chose Kubernetes, so count it in your effort estimate.
Scaling the server and worker without guessing
Scaling the Twenty server and scaling the worker are separate decisions, and they should be made separately. The server answers API and UI requests, while the worker runs background jobs such as workflow automation and email and calendar sync through BullMQ. A team may need more worker capacity long before it needs more front-end capacity, or the reverse. The Docker Compose guide runs one server, one worker, PostgreSQL and Redis, so scaling that file means editing the service definitions yourself. Compose can run several containers of a service on one host, but it does not spread them across machines unless you add tooling such as a multi-host orchestrator, which moves you into the operating model the Kubernetes option already describes. Before you add a second worker, confirm with the maintainers whether concurrent workers are supported for your release, and whether any job type must run only once.
On Kubernetes, replica count, restarts and rollouts are handled by the platform, which is the main reason teams choose it. That convenience does not prove the application is safe to run as several replicas. Check that the community chart exposes replica settings for both the server and the worker, and that your configuration does not assume a single writer for scheduled or queued jobs. Also confirm how the chart handles database migrations when more than one pod starts at once. Treat these as open questions for the chart maintainers and the Twenty project until you have tested them in a staging cluster with your own configuration.
Placement of PostgreSQL and Redis decides your failure domains. If both run inside the same node or the same Compose host, one hardware failure takes out the application, its queue and its data together. A managed or separately operated PostgreSQL with tested point-in-time backups usually gives you a clearer recovery path, but someone must own that backup and restore process, and it may not be your application team. Redis holds queue state for the worker, so decide whether losing in-flight jobs is acceptable or whether you need persistence and failover. Write down who restores each component, how long that restore has been tested, and what happens to queued work during a restore before you scale beyond one replica.
When Kubernetes is worth the added operating work
This sequence tests whether a single well-run Compose host still meets the requirement, and only moves to Kubernetes when a specific check fails. Each step closes with a written answer the team can take into a design review.
Confirm whether an existing cluster already exists
The platform lead checks whether the organization already runs production Kubernetes clusters that a Twenty deployment could join under the same ownership, monitoring and backup routines. If no cluster exists, building one for a single CRM is a separate platform project with its own control plane, etcd and load balancer work. The step closes with a yes or no answer and a named owner for the cluster if the answer is yes.
Inventory skills for cluster operations
The infrastructure team lists who can operate Kubernetes day to day, including upgrades, certificate rotation, RBAC, ingress and storage, and who would be on call when a node fails. Twenty's Docker Compose guide already covers a server, a worker, PostgreSQL and Redis, so the question is whether the team can troubleshoot a cluster as well as those four services. The step closes when the team agrees on how many people hold each skill, with at least two people able to act on an incident.
Document any policy requiring cluster-level controls
The security and compliance lead reviews written policy for requirements such as admission control, network policy, namespace isolation or pod security enforcement that the organization applies at cluster level. Kubernetes provides Pod Security Standards and RBAC for these purposes, but a Compose host does not offer the same native model, so compensating controls must be described. The step closes with a list of required controls and a note on whether each can be met on a single host, which the auditor or policy owner should confirm.
Map environments that must match each other
The platform lead lists the environments needed, such as development, test, staging and production, and whether they must run the same orchestration model. Compose files can express separate environments on separate hosts, while Kubernetes can host several environments in one cluster with namespaces, but that sharing adds blast radius that must be planned. The step closes when the team records each environment, its data separation rule and the tool used to keep configurations in step.
Test availability targets against one host
The service owner writes the uptime and recovery expectations agreed with business users, then checks whether a single host with tested backups and a documented restore procedure can meet them. A single Compose host is a single point of failure, so high availability needs a separate design such as a standby host or an orchestrator with multiple nodes. The step closes with a pass or fail result per target, and any failed target is passed to the next check.
Assess capacity for upgrades and etcd care
The platform team estimates the recurring work of running Kubernetes, including minor version upgrades that must go one minor version at a time, kubelet versions kept within the allowed skew, and etcd backups taken with a tested restore path. Kubernetes releases a new minor version about three times per year and supports only the three most recent minors, so the work recurs. The step closes when the team confirms named people with time for upgrade windows, or records that they do not, which points back to a single well-run Compose host.
Stop at Compose when checks are met
If the existing cluster, skills, policy, environments, availability and upgrade capacity checks all favor a single host, the team keeps the core-team-supported Docker Compose deployment and records the decision. The team then sets scaling, PostgreSQL and Redis placement, backup and upgrade routines on that host. The step closes with a signed design note that names the trigger conditions for revisiting Kubernetes, such as a new policy requirement or a failed availability target.
Upgrades, backups and monitoring under each model
This table compares who runs upgrades, backups and monitoring for Twenty under Docker Compose and under a community Helm chart on Kubernetes. Read each row as a question to answer with your own team: who holds the pager, who restores the database and which skills you already have.
| Operating task | Docker Compose | Kubernetes with community Helm chart |
|---|---|---|
| Release cadence to track | Twenty ships frequent releases, such as v2.48.0 on October 16, 2026. Each release needs a planned pull, restart and smoke test. | Twenty releases still apply, plus Kubernetes minor releases about three times a year. Two release trains must be planned together. |
| Upgrade steps | Pull the new images, review release notes, run the migration path described in the self-hosting guide and verify the server and worker. | Same Twenty steps, plus chart version changes and cluster upgrades. Kube-apiserver upgrades come first, one minor version at a time, then other control plane components and kubelets. |
| PostgreSQL backups | Your team schedules dumps or volume snapshots and tests restores. Recovery is simpler because one host holds the data. | Your team owns backups of the database, whether it runs in or outside the cluster. Backup jobs, retention and restore drills must be designed and tested. |
| Redis data | Redis holds queue and cache state that workers depend on. Confirm with the Twenty docs which Redis data must survive a restore. | Same question, with Redis pods and volumes to manage. Confirm persistence settings and whether a restore must include Redis. |
| Cluster state backups | Not applicable beyond the host and its volumes. | etcd needs a backup plan. Kubernetes documentation describes etcdctl snapshot save for backups and etcdutl for restores. |
| Monitoring and logging | Host metrics, container logs and Postgres and Redis health checks. Tooling is chosen and run by your team. | Cluster, node, pod and etcd metrics plus Twenty server and worker signals. Expect a larger monitoring stack to build and maintain. |
| Skills the model requires | Linux administration, Docker, PostgreSQL and Redis operations, plus reverse proxy and TLS management. | Kubernetes administration, Helm, etcd operations, RBAC and secret handling, plus everything the Compose column needs. |
What running the cluster adds to the work
Choosing Kubernetes means the CRM team inherits a control plane, not just a set of containers. The kubeadm high availability pattern calls for at least three control plane nodes with a TCP load balancer in front of kube-apiserver on port 6443, and the team must decide whether etcd runs stacked on those nodes or as an external cluster. Whoever owns the cluster, whether the client platform team or DeployOpen under a written scope, has to size and patch those nodes. Ask the Helm chart maintainers and your platform team who signs for control plane availability before the first deployment, because a Twenty outage caused by a failed control plane is a different incident from one caused by the application.
etcd adds a second stateful system with its own rules. Kubernetes documentation says etcd should run with an odd number of members, recommends five members in production, and requires a backup plan, using etcdctl snapshot save for backups and etcdutl for restores. Backup scheduling, restore rehearsal and retention are recurring work that Docker Compose does not create in the same form. Confirm who runs those snapshots, where they are stored, and how often the team has actually restored one into a test cluster. Note that Twenty's own data lives in PostgreSQL, so etcd backups do not replace database backups.
Secrets need explicit hardening. The Kubernetes secrets guidance states that Secrets are stored unencrypted in etcd by default, so the platform owner must configure encryption at rest and restrict list and watch access with least-privilege RBAC, or move sensitive values to an external store through the Secrets Store CSI Driver. Those values typically include the Twenty application secret, PostgreSQL credentials and Redis credentials. Version support is the last recurring cost: the project maintains only the three most recent minor releases, and the version skew policy requires control plane upgrades one minor version at a time. Confirm the cluster's target minor version and the upgrade calendar in writing before committing.
Questions buyers ask before choosing a deployment model
Does the Twenty core team support the Docker Compose deployment?
Yes, the Docker Compose deployment is the path the core team documents for self-hosting, so it has the clearest support boundary. The guide runs a server, a worker, PostgreSQL and Redis, and asks for at least 2 GB of RAM because insufficient memory can crash processes. Ask the vendor to confirm in writing which image tags and upgrade steps are covered and what falls outside support. Your reverse proxy, TLS certificates, backups, host patching and monitoring stay with your team or your implementation partner, whichever model you pick.
Does the core team support the community Helm chart for Twenty?
Confirm this before you rely on the chart, because the Helm chart is community-maintained and should be treated as a community artifact unless the vendor states otherwise. Ask the Twenty team whether any part of the chart, its default values or its upgrade path is covered by their support, and get the answer in your support terms. Then check the chart's maintainers, release cadence and open issues. Compare the chart version against the Twenty release you plan to run, since Twenty ships frequent releases, with v2.48.0 released on October 16, 2026. Without written support, chart defects and upgrade breakage fall to your team or partner.
What drives the effort and cost of each deployment model?
Both models carry one-time setup and recurring operations, but the cost components differ. For Compose, the main costs are one host or virtual machine sized for the server, worker, PostgreSQL and Redis, plus the time to harden and back up that host. For Kubernetes, you add the cluster itself:
- control plane and worker nodes, a load balancer and persistent storage
- platform skills to run upgrades, policy and secrets
- monitoring and on-call coverage for the cluster, not only the application
Effort rises with user count, data volume, availability targets and the number of environments. Ask any quote to split one-time work (design, hardening, migration) from recurring work (upgrades, patching, backups, support) and to name who is paid for each line.
How long does a migration from Compose to Kubernetes take?
No migration duration has been established for this move, so do not plan around any single number. The time depends on the size of the PostgreSQL database, the volume of attachments and files, how much Redis state must be preserved, the DNS and TLS cutover, and how long your change window can tolerate downtime. Ask any provider for a schedule tied to a written scope, including a rehearsal on a copy of production data and a rollback plan. Ask what the estimate assumes about data volume, access to the target cluster and your approval steps, since those assumptions usually decide whether the schedule holds.
Can a small team run Twenty on Docker Compose without a platform team?
Yes, a small team can run the Compose stack if it already operates Linux hosts, Docker, PostgreSQL and Redis and can keep those components patched. The team also needs a tested backup and restore routine for PostgreSQL and a process for applying Twenty upgrades on a schedule. The stated 2 GB RAM minimum is a floor for the stack, not a sizing guide for your user count, so confirm capacity with a test that reflects your workload. If nobody on the team has those operating skills, a retainer for upgrades and monitoring usually costs less in risk than learning them during an incident.
What skills does Kubernetes require beyond Docker Compose?
Kubernetes adds a cluster to operate, so the team needs skills in cluster lifecycle, storage, networking, access control and upgrades. Specific areas to check:
- High availability: the kubeadm guide describes stacked or external etcd topologies, with at least three control plane nodes and a TCP load balancer in front of the API server on port 6443.
- etcd: the documentation recommends an odd number of members, five in production, plus regular snapshots with etcdctl and restores with etcdutl.
- Secrets: Secrets are stored unencrypted in etcd by default, so encryption at rest and least-privilege RBAC must be configured.
- Upgrades: the version skew policy sets the order of component upgrades. Confirm your platform team can follow it.
When is Kubernetes worth the extra effort for Twenty?
Kubernetes is worth the extra effort when your organization already runs clusters, has a platform team that owns upgrades and policy, and needs the Twenty workload to follow the same controls as other services. It can also suit multi-node layouts that your team must manage consistently across environments. It is usually hard to justify for a single team with a modest user base and no existing cluster, where a well-run Compose host with tested backups covers the need. Deployment model does not change which features are included. Check plan-level features such as SSO, row-level permissions and audit logs on the pricing page before you decide.
Can DeployOpen plan and implement either model within a fixed written scope?
Yes, DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications, which independent auditors and certification bodies provide.
How DeployOpen scopes and supports Twenty deployments
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Twenty, that means deciding with your team whether Docker Compose or Kubernetes fits your operating model, then building and handing over the chosen path in writing.
How we scope
- Written scope names the target runtime, Docker Compose or Kubernetes, before any work starts.
- Scope records who runs the server, worker, PostgreSQL and Redis, and who owns upgrades.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing up front.
How we build
- Deploy Twenty with the chosen topology inside your infrastructure, with sizing based on your load.
- Configure PostgreSQL and Redis placement, backups, secrets handling and network boundaries as agreed.
- Test the deployment, including worker behavior and restart recovery, before it is accepted.
How we hand over
- Deliver runbooks for upgrades, scaling changes, backups and restores in your environment.
- Document the support boundary, showing which components are your team's and which are vendor-supported.
- Walk your operators through the running system so routine changes stay with your own staff.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately.
- Retainers can cover Twenty release tracking, patch windows and periodic restore tests.
- Confirm response expectations and what a retainer excludes before you sign, since terms are set per scope.
