Twenty cloud vs self-hosted: which model fits your team
Choose Twenty Cloud if you want the vendor to run the platform and your data can live in their hosting, and self-host the free core if your data must stay in infrastructure you control and your staff can operate it. The deciding factors are less about the CRM itself and more about where data is allowed to sit, who on your team can run PostgreSQL, Redis and the Twenty server and worker, and whether the features you need are on a paid plan. Twenty's pricing page says the open-source core can be self-hosted for free, and it lists unlimited custom objects, fields, views and records plus REST and GraphQL APIs on all plans, so a small team with basic needs may not need a paid tier at all.
Self-hosting fits teams that already run containers and databases, can accept the monitoring and backup work, and want their CRM inside their own cloud account or data center. The Docker Compose self-hosting guide runs a server, a worker, PostgreSQL and Redis and asks for at least 2 GB of RAM. Your team owns patching, restores and upgrades for all four components. Before committing, confirm whether you need SSO, row-level permissions, audit logs or encryption key rotation, since the pricing page places these on the Organization and Enterprise plans, and check whether SCIM or IP allow-listing matter to your auditors, because those sit on Enterprise.
Twenty Cloud fits teams without database operators, or teams whose data residency rules the vendor's hosting can satisfy. Paid plans are priced per user, so the cost scales with headcount and recurs monthly, while self-hosting shifts cost toward staff time and infrastructure. Ask the vendor in writing where data is stored, how backups and restores work, what happens to data on exit, and which controls are included in the plan you buy. Build a short cost model for both options using your own user count and the plan that covers your required features.
How Twenty Cloud and self-hosted Twenty compare on the factors that decide the choice
This table sets Twenty's managed plans against running the free open-source core yourself, row by row on licensing, price, feature access, data location, upgrades and who operates the stack. Read each row against your compliance needs and your team's capacity to run PostgreSQL, Redis and workers, and mark anything the vendor has not confirmed as a question for your quote.
| Factor | Twenty Cloud (paid plans) | Self-hosted Twenty (free core) |
|---|---|---|
| Licensing | Vendor-operated service on the Pro, Organization and Enterprise plans. Licensing of the hosted service terms should be confirmed with Twenty. | Core is mostly AGPL-3.0 with an additional application exception. Files with an Enterprise license header are under a commercial license, and SDK and UI packages are MIT. |
| Price model | Pro at 9 US dollars per user per month, Organization at 19 US dollars per user per month, Enterprise from 50,000 US dollars a year (per Twenty's pricing page). | The open-source core can be self-hosted for free. You pay for your own infrastructure, staff time and any outside support. |
| Feature access | SSO, row-level permissions and audit logs on Organization and Enterprise. SCIM provisioning and IP allow-listing on Enterprise. | Core features and unlimited custom objects, fields, views and records. Paid-tier controls such as SSO, row-level permissions and audit logs are not part of the free core as published. |
| Data location | Hosted by Twenty. Hosting regions and data residency should be confirmed with the vendor before signing. | Runs in your own cloud account, data center or private network, so you choose where PostgreSQL and file data reside. |
| Upgrades | Handled by Twenty on its hosted service. Release cadence is frequent, for example v2.48.0 on October 16, 2026. Confirm maintenance windows and rollback terms. | You plan and apply each upgrade, including the server, worker, PostgreSQL and Redis images. Release notes and the Docker Compose guide set the steps. |
| Who operates the stack | Twenty operates the server, worker, PostgreSQL and Redis. Your team manages users, configuration and data. | Your team or a partner operates the server, worker, PostgreSQL and Redis, and needs at least 2 GB of RAM per the Docker Compose guide. |
| Support and SLA | Enterprise plan includes an SLA. Confirm the SLA terms and support tiers for other plans in writing. | No vendor SLA is published for the free core. Support depends on your own staff or a separate written agreement. |
Which features need a paid plan and which stay in the free core
Twenty's pricing page says the open-source core can be self-hosted for free. Every plan, including the free core, includes unlimited custom objects, fields, views and records, along with REST and GraphQL APIs and webhooks. That covers the data model and integration surface most small teams need to build a working CRM. The cost of the free core is the infrastructure and the people who run it, not a license fee.
- Data model and records: Unlimited custom objects, fields, views and records are included in all plans.
- Integration surface: REST and GraphQL APIs and webhooks are included in all plans.
- Self-hosting path: The Docker Compose guide runs a server, a worker, PostgreSQL and Redis, and asks for at least 2 GB of RAM.
- Operating burden: Your team owns upgrades, backups, patching and monitoring of those services.
- Paid-only controls: SSO, row-level permissions, audit logs and encryption key rotation are not part of the free core as listed on the pricing page.
Check the current pricing page and the repository's license headers before you rely on the free tier for a regulated workload.
The Organization plan is the first paid tier that adds access and audit controls. Twenty lists it at 19 US dollars per user per month, and it adds the controls that many security reviews ask about first: who can see which records, who signs in and what changed. The price is per user, so cost grows with headcount rather than with data volume or server size.
- Row-level permissions: Restricts which records each user can read or change.
- SAML or OIDC SSO: Connects sign-in to your existing identity provider.
- Audit logs: Records activity for review and investigation.
- Encryption key rotation: Supports rotating the keys that protect stored data.
- Per-user pricing: The 19 US dollar monthly rate applies to each user on the plan, as listed on the pricing page.
Confirm with Twenty whether these features work the same way on a self-hosted install of this tier as they do on Twenty Cloud.
The Enterprise plan is the top tier. Twenty lists it from 50,000 US dollars a year and adds single-tenant isolation, IP allow-listing, SCIM provisioning and an SLA. These controls matter most when user lifecycle, network boundaries and contractual support are part of the procurement decision. Enterprise code also falls under a commercial license rather than the AGPL-3.0 core.
- Single-tenant isolation: Dedicates the environment to one customer.
- IP allow-listing: Restricts access to approved network ranges.
- SCIM provisioning: Automates user creation and removal from your identity provider.
- SLA: A contractual service commitment, with terms to be read in the contract.
- Commercial license: Files marked with an Enterprise license header are under a commercial license, per the LICENSE file.
Ask Twenty for the written terms of the SLA and the list of Enterprise-licensed files before budgeting.
The pricing page separates plans by feature, but it does not settle how those features behave when you run the code yourself. SSO and audit features are gated in the vendor's plan structure. Whether the same gating applies to a self-hosted install of a paid tier is a question for the vendor, and the answer changes what you pay for. Treat the plan name as a commercial term until Twenty confirms the technical delivery model.
- Gating model: Confirm whether SSO, audit logs and row-level permissions are unlocked by a license key on your own servers.
- Enterprise-licensed files: Confirm which parts of a self-hosted build fall under the commercial license.
- Renewal and true-up: Ask how per-user counts are measured and reported for self-hosted deployments.
- Upgrade behavior: Ask whether paid features survive version upgrades without a separate action.
- Written scope: Get the answers in the quote so the gating is part of the agreed scope.
Do not assume a paid feature works on self-hosted infrastructure until you have the vendor's answer in writing.
Where your data lives, who holds the keys and what compliance evidence you can produce
Twenty Cloud and self-hosted Twenty put the same application in different hands. The cards below cover the decisions that move with that choice: where records sit, who controls identity and keys, what gets logged and what evidence each model can produce. Verify every point against the vendor's current documentation and contract before you rely on it.
Data location and residency
With Twenty Cloud, the vendor decides where the PostgreSQL and Redis data physically sits, and you rely on its data processing terms to know the region and sub-processors. With self-hosted Twenty, you choose the cloud account, data center or air-gapped network, so residency is a design decision you document yourself. Ask the vendor in writing which regions host your workspace, which sub-processors touch customer data, and how backups are stored and where.
Access control and identity integration
The pricing page places SAML or OIDC SSO, row-level permissions and audit logs on the Organization plan, and SCIM provisioning and IP allow-listing on Enterprise. Running the free core yourself means you must wire your own identity provider and access rules, and you must confirm which of those features the self-hosted build exposes without a paid plan. Document which controls you enforce at the network edge and which depend on the application.
Encryption key handling
Twenty's pricing page lists encryption key rotation among the Organization and Enterprise features. On the cloud service, the vendor generally runs key management, so your evidence is its written description of storage encryption and rotation. On self-hosted Twenty, you own the keys, the rotation schedule and the recovery procedure for PostgreSQL and Redis data. Ask whether rotation is available on your chosen tier and how keys are recovered if a key is lost.
Audit logging and retention
Audit logs are a paid feature on the Organization and Enterprise plans according to the pricing page. Under the cloud model, you need the vendor to confirm log content, retention period and whether you can export logs to your SIEM. Under self-hosting, you decide retention, protect logs from tampering and forward them off the host. Confirm which events are recorded for record exports, permission changes and API token use before you rely on them for an assessment.
Vendor responsibility for the cloud service
Under Twenty Cloud, the vendor operates patching, backups and availability, and its security commitments sit in the contract and its documentation. Under self-hosted Twenty, your team or your implementation partner carries those duties, including upgrades from frequent releases such as v2.48.0. Request the vendor's security documentation, its incident notification terms and any service level commitments, and confirm whether an SLA is part of the plan you buy.
Evidence each model produces
Neither model gives you a certification by default, so no cloud claim should be read as attestation. Your evidence file under the cloud model is the vendor's documentation, data processing terms and your own configuration records. Under self-hosting, you must document the host hardening, backup tests, access reviews and key procedures yourself, and an independent assessor decides what they accept. Ask the vendor which third-party reports exist and whether it will share them under NDA.
What your team runs in each model: PostgreSQL, Redis, workers and upgrades
This table lists the operating tasks behind a self-hosted Twenty deployment and shows who owns each one under Twenty Cloud and under the free core run by your team. Read the Twenty Cloud column as the questions to put to Twenty about its managed service, and the self-hosted column as the work your team would carry. The main takeaway is that self-hosting shifts every infrastructure task to your team, so the decision depends on how much of that work you can staff and keep current.
| Operating task | Twenty Cloud (paid plan) | Self-hosted Twenty (free core) |
|---|---|---|
| Provisioning the Docker Compose stack (server, worker, PostgreSQL, Redis) | Twenty operates the stack; confirm the hosting region and tenancy model in writing | Your team deploys the four services from the Docker Compose guide and maintains the configuration files |
| PostgreSQL backups and restores | Confirm backup frequency, retention and restore testing with Twenty | Your team designs, schedules, encrypts and regularly test-restores backups |
| Redis availability | Managed by Twenty; ask how failover is handled | Your team monitors Redis health, persistence settings and restarts after failure |
| Worker health (background jobs) | Managed by Twenty, including workflow and sync jobs | Your team watches the worker process, job queues and restarts, since workflows and email or calendar sync run there |
| Memory sizing against the documented minimum of 2 GB of RAM | Twenty chooses capacity; ask how it scales with your user count | Your team sizes the host above the 2 GB minimum and adds memory as users and integrations grow, because insufficient memory can crash processes |
| Patching and release upgrades | Twenty deploys releases on its schedule; ask about notice and rollback | Your team plans each upgrade, tests it against custom objects and integrations, and applies it, with frequent releases such as v2.48.0 on October 16, 2026 raising the cadence |
| Monitoring and alerting | Ask what Twenty monitors and what it exposes to you | Your team builds monitoring for all four services plus host metrics and database growth |
| Incident response | Ask for the support tier, response targets and escalation path in the contract | Your team owns triage, recovery and communication, with community resources as the only vendor-side help on the free core |
How upgrades reach you when Twenty ships releases every few days
Twenty ships frequent releases. v2.48.0 was released on October 16, 2026, one day after v2.47.0, according to the Twenty GitHub releases. For a self-hosted team, that cadence means every upgrade is an operational task you own: you read the release notes, decide whether a version is safe for your workspace, schedule a window, and apply it to the server and worker containers, which both need to move together with PostgreSQL and Redis left in a supported state. A Twenty Cloud customer receives those changes from the vendor, so the question shifts from "when do we apply it" to "when does the vendor apply it to us, and how much warning do we get."
Before you adopt a self-hosted release cadence, build the controls that make frequent upgrades reversible. Run a staging environment that mirrors your production Docker Compose stack, including your custom objects, fields, workflows and SSO settings, and test each new release there first. Take a full PostgreSQL backup and confirm you can restore it into a scratch instance before every production upgrade, since the database holds the workspace data and schema changes travel with the application. Write a rollback plan that names the previous image tag, the restore procedure and the person who can declare a rollback. Plan for a slower cadence than the release feed if your team cannot test each version within a few days.
Ask the vendor how cloud maintenance windows are scheduled, whether you can pick or defer a window, and how breaking changes to the API, custom object definitions or workflow behavior are announced before they reach your workspace. Ask whether release notes flag schema migrations and whether you get a staging or preview environment for testing. Compare those answers with your own capacity to run the staging and rollback steps above. Confirm the current terms and support arrangements directly with Twenty, since upgrade handling for each plan is not described in the supplied pricing details.
Moving Twenty between self-hosted and Twenty Cloud
This sequence moves a Twenty workspace in either direction without losing records, schema, permissions or integrations. It ends with the destination running the same data and access rules, and the source instance archived and retired.
Confirm export and API options first
Before any work starts, ask Twenty in writing which export paths exist for your plan and deployment: whether a bulk export tool is available, what the REST and GraphQL APIs can read, whether custom object definitions can be exported as code, and whether Twenty Cloud offers any database-level access. Ask whether file attachments are stored inside PostgreSQL or elsewhere. Done means you hold a written answer for each path, and you know which items must be rebuilt by hand.
Inventory objects, permissions, workflows and integrations
The workspace owner, with an administrator who knows the integrations, records every custom object, field, view, role, row-level permission rule, workflow, webhook endpoint, API key, email and calendar connection and SSO setting. Note which features depend on a paid plan, because a target plan without them will break the mapping. Done means a single inventory document exists and has been reviewed by someone who owns each integration.
Export records and database contents
On self-hosted Twenty, the platform team takes a consistent PostgreSQL dump of the database while writes are paused, then records its checksum. On Twenty Cloud, the export uses the path confirmed in the first step. Compare record counts per object between source and export, and confirm that attachments and any files outside the database were copied too. Done means the export files and counts match the source and are stored under your retention controls.
Map objects, roles and workflows
Build a mapping sheet that links each source object, field, role, row-level rule and workflow to its target. Custom objects defined as code must be ported into the target codebase or recreated in the target UI, depending on what the vendor confirmed. Check that the target plan supports SSO, row-level permissions and audit logs for every role that relies on them. Done means the mapping has been signed off by the data owner and the security lead.
Validate the import in a test environment
Load the export into a separate test instance, such as a second Docker Compose stack for self-hosted Twenty (which needs at least 2 GB of RAM for the server, worker, PostgreSQL and Redis) or a test workspace on Twenty Cloud if the vendor offers one. Test each role as a real user would, confirm workflows fire, and send a sample event to each webhook endpoint. Done means counts, permissions and workflow runs match the inventory, with failures logged and fixed.
Cut over users and integrations
Schedule a write freeze with the business owners, load the final export into the target, and repoint webhook endpoints, API clients, SSO settings and email and calendar sync. Ask each user to sign in and confirm access to their records. Keep the source in read-only mode until the checks pass. Done means every integration has delivered a test event to the new endpoint and all users have signed in successfully.
Retire the old instance
Once the cutover has held through your agreed observation period, store the final source dump and its checksum in an archive that meets your retention policy. Revoke old API keys and webhook secrets, remove the source service accounts, and decommission the old hosting or Twenty Cloud workspace according to the contract terms. Done means the archive is verified, no credentials for the source remain active, and the decommissioning record is filed.
What you pay for in each model and what changes the total
The subscription line in Twenty Cloud is the only fee you can see on the pricing page, and it is priced per user. The pricing page lists Pro at 9 US dollars per user per month, Organization at 19 US dollars per user per month, and Enterprise from 50,000 dollars a year. Multiply the seat count by the tier rate and you have a recurring figure that grows with every user you add, and that also rises when a feature you need sits behind a higher tier. The free self-hosted core carries no license fee, so its total cost is the infrastructure, the staff time and the services you buy around it. Those costs do not disappear in the cloud model. They are carried by the vendor and folded into the subscription.
On the self-hosted side, the costs shift to you and most of them recur. You pay for compute and storage for the server, the worker, PostgreSQL and Redis, which the Docker Compose guide runs together and for which it asks for at least 2 GB of RAM. You also pay for staff time on backups and restore tests, monitoring, certificate handling, and upgrades across Twenty's frequent releases. Some costs are one-time, such as initial setup, configuration of SSO and permissions if you need the paid-plan features on your own identity stack, and migration of existing CRM data. Environments multiply the recurring part: a staging copy that mirrors production doubles much of the hosting and upkeep. Ask whether the quote covers each of these separately.
When you request a quote from the vendor or a services partner, ask for the following in writing: the seat count and tier for each year, the price for any Enterprise term and whether it has a minimum, which features your plan includes, and who handles upgrades and security patches. For self-hosting, ask for a line-item scope covering installation, backups with a tested restore, monitoring, upgrade windows, and the number of environments. Confirm whether support hours and response commitments are part of the fee or sold separately. DeployOpen plans, implements and supports self-hosted platforms in your own infrastructure under fixed-scope agreements, so a written scope is the basis for any figure. Compare totals over the same period and the same user count, not the monthly rate alone.
Questions buyers ask before choosing Twenty Cloud or self-hosting
Is the free self-hosted Twenty core enough for a regulated team?
Often not on its own, because the free core does not include every control a regulator or auditor may ask about. Twenty's pricing page says the open-source core can be self-hosted for free, while SSO, row-level permissions, audit logs and encryption key rotation are listed for the Organization and Enterprise plans, and SCIM provisioning and IP allow-listing for Enterprise. Map your control requirements to those features before deciding. If you need any of them, price the paid plan alongside the infrastructure, or confirm with Twenty how the feature is delivered in your deployment model. Independent auditors, not DeployOpen or the vendor, decide whether your evidence is sufficient.
Which Twenty features require a paid plan?
Single sign-on, row-level permissions, audit logs and encryption key rotation are listed for the Organization and Enterprise plans. SCIM provisioning and IP allow-listing are listed for Enterprise. Per the pricing page, Pro is priced at 9 US dollars per user per month, Organization at 19 dollars per user per month, and Enterprise starts at 50,000 dollars a year. All plans, including the free core, include unlimited custom objects, fields, views and records, plus REST and GraphQL APIs and webhooks. Check the pricing page on the day you buy, because plan contents can change.
How much effort does running PostgreSQL and Redis take?
The effort is ongoing, not a one-time setup. Twenty's Docker Compose guide runs a server, a worker, PostgreSQL and Redis, and asks for at least 2 GB of RAM because insufficient memory can crash processes. Your team owns backups, patching, monitoring, storage growth and recovery testing for both databases, plus the worker queue that BullMQ uses on Redis. Cloud hosting moves that work to Twenty, while self-hosting keeps it in your hands. Ask Twenty which backup and restore procedure it documents, and test a restore in your own environment before go-live.
How often do Twenty upgrades arrive, and who applies them?
Twenty ships frequent releases. For example, v2.48.0 was released on October 16, 2026, one day after v2.47.0, according to the GitHub releases. Frequent releases mean you need a repeatable upgrade routine: read the release notes, back up PostgreSQL, apply the update to a staging copy, then promote it. On the cloud plans, Twenty applies upgrades for you. Self-hosting leaves that schedule with your team, so the question is whether you can keep pace with a release cadence and test custom objects and integrations after each change.
Can our own team run self-hosted Twenty without outside help?
It depends on your existing skills and staffing. Twenty is a TypeScript application built on NestJS, React, PostgreSQL and Redis, and it exposes GraphQL and REST APIs. A team that already runs Node.js services, Docker and PostgreSQL will recognize most of the work. A team whose hosting skills are centered on PHP with MySQL or MariaDB will face a new stack. Before deciding, name the person who owns upgrades, on-call response and database recovery. If nobody has time for that, cloud hosting or an outside operator may fit better.
How long does a migration to or from Twenty take?
The supplied facts do not give a migration duration, and the length depends on data volume, custom objects, integrations and how many users must cut over. Migration effort is driven by how much custom data model you have, how many workflows and API integrations point at Twenty, and whether you run a parallel period. Ask Twenty for its current export and import options, and ask DeployOpen or any services partner for a written scope and timeline before committing. Plan a test migration with real records in a staging environment first.
What does a services engagement for self-hosted Twenty cover?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and 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.
What licensing questions should we ask before self-hosting Twenty?
Twenty is mostly licensed under AGPL-3.0 with an additional application exception. Files marked with an Enterprise license header fall under a commercial license, and SDK and UI packages are MIT, according to the LICENSE file in the repository. Ask legal to review how your planned modifications, internal use and any customer-facing deployment interact with the AGPL and the exception. Confirm which files your deployment will touch, because enterprise-licensed code is governed separately.
How DeployOpen scopes, delivers and supports self-hosted Twenty
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Twenty, that means deciding whether the free core or a paid plan fits your requirements, then building and handing over the PostgreSQL, Redis and worker setup in writing before any work starts.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which Twenty features you need and whether each depends on a paid plan or enterprise-licensed code.
- Scope covers the hosting target, network boundaries, identity provider and the data you plan to store in the CRM.
How we build
- Deployment follows the Docker Compose layout of server, worker, PostgreSQL and Redis, sized to the memory the vendor guide requires.
- Configuration covers SSO, backups and upgrade procedures, with each setting documented against your environment.
- Testing checks the deployed instance, including worker jobs, email and calendar sync and API access, before handover.
How we hand over
- Handover includes documentation of the architecture, configuration, backup and restore steps and upgrade runbook.
- Your team receives written records of what was built, what was tested and which features remain on the free core.
- Open items, such as features that need a paid plan, are listed with the owner and the question to confirm with Twenty.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades follow Twenty's frequent release cadence, with each release tested in your environment before it reaches production.
- Ask any quote for the upgrade cadence, the backup scope and the response expectations, all written into the scope.
