When the free Twenty core is enough and when a paid plan is needed
The free self-hosted core is enough when the team is small, no policy requires single sign-on, and the CRM is reached only from your internal network. It stops being enough when access control, identity or audit requirements call for controls that Twenty's pricing page lists under Organization or Enterprise: SSO, row-level permissions, audit logs, SCIM provisioning and IP allow-listing. Twenty lists Organization at 19 US dollars per user per month and Enterprise from 50,000 US dollars a year, per its pricing page. The free core carries no license fee, but you pay for hosting, staff time and the maintenance of the stack.
The free core fits teams that can meet their controls with role-based permissions and network-level restrictions. Its Docker Compose guide runs a server, a worker, PostgreSQL and Redis and asks for at least 2 GB of RAM, so the operating cost is infrastructure plus the time to apply frequent upgrades. Releases are frequent: v2.48.0 followed v2.47.0 by one day. Before you commit, confirm with Twenty exactly what role-based permissions cover in the free core and whether your auditors accept them as the access model for CRM records. If your policy requires that users see only certain records, that is a row-level permission question and points toward a paid plan.
Paid plans become necessary when your written requirements name a control the free core does not provide. For example (illustrative only): a 50-user team at the Organization list price would pay about 11,400 US dollars a year in subscription fees, before any implementation work. Enterprise adds SCIM and IP allow-listing and is priced from 50,000 US dollars a year. Ask Twenty whether paid features are available on your own infrastructure, which parts of the code fall under the Enterprise commercial license, and what the contract says about upgrades and support. Map each control in your policy to a named feature before you decide, and keep the free core if the mapping leaves nothing unmet.
Which Twenty capabilities are free and which are paid
This table sets the free self-hosted core against the Organization and Enterprise plans on the features Twenty's pricing page documents. Check marks show what the pricing page confirms for each tier, and text cells flag items the page does not list, which you should confirm with Twenty before relying on them. For regulated buyers, the main takeaway is that SSO, row-level permissions, audit logs and key rotation sit on paid tiers, not in the free core.
| Capability | Free self-hosted core | Organization | Enterprise |
|---|---|---|---|
| Unlimited custom objects, fields, views and records | Yes | Yes | Yes |
| REST and GraphQL APIs and webhooks | Yes | Yes | Yes |
| SSO (SAML or OIDC) | Not listed on pricing page, confirm with vendor | Listed on pricing page | Listed on pricing page |
| Row-level permissions | Not listed on pricing page, confirm with vendor | Listed on pricing page | Listed on pricing page |
| Audit logs | Not listed on pricing page, confirm with vendor | Listed on pricing page | Listed on pricing page |
| Encryption key rotation | Not listed on pricing page, confirm with vendor | Listed on pricing page | Listed on pricing page |
| SCIM provisioning | Not listed on pricing page, confirm with vendor | Not listed on pricing page, confirm with vendor | Listed on pricing page |
| IP allow-listing | Not listed on pricing page, confirm with vendor | Not listed on pricing page, confirm with vendor | Listed on pricing page |
| Single-tenant isolation | Not applicable to self-hosting in your own environment, confirm hosting model | Not listed on pricing page, confirm with vendor | Listed on pricing page |
How licensing, support and updates differ by edition
Twenty's free core, its paid plans and its enterprise-licensed files are separate things with separate terms. Read the license, the pricing terms and your own operating responsibilities together before assuming what a paid plan changes.
AGPL-3.0 core with an application exception
Twenty's repository is mostly licensed under AGPL-3.0 with an additional application exception. The exception is the text to read with your legal team, since it governs how you may use and modify the core inside your own organization. Confirm with counsel whether your planned customizations, internal integrations and any hosted offering to third parties fall within it before you build on the core.
Enterprise-header files
Files marked with an Enterprise license header are under a commercial license, not AGPL-3.0. Self-hosting the free core does not include them, so a feature that appears in the code may still require a paid agreement. Ask Twenty which modules carry the header in the version you plan to deploy, and keep that list with your architecture records.
MIT SDK and UI packages
The SDK and UI packages are MIT licensed, which is more permissive than the core. They are the parts most likely to be reused in internal apps or extensions. Permissive terms do not change the status of the server, which remains under the core license, so keep the license of each package separate in your software bill of materials.
What paid plans add in support
Twenty's pricing page lists an SLA for the Enterprise plan, which is the documented support commitment in the public material. Organization pricing lists SSO, row-level permissions and audit logs but does not present an SLA on the same page. Ask for the written support tiers, response targets and escalation path for each plan before treating them as equivalent.
Security updates stay with the operator
Under self-hosting, you apply Twenty releases, patch PostgreSQL and Redis, and track security fixes in the server and worker images. Twenty ships frequent releases, so a regular upgrade cadence is a standing task. Unless you agree a retainer that covers upgrades and continuous support, the patch and upgrade responsibility sits with your team.
Questions to settle before purchase
Before choosing a paid plan, confirm in writing which features are in the license of the version you will run, whether SSO and audit logs apply to self-hosted deployments, and who holds the upgrade and backup duty. Record the answers with the contract so that a later license or plan change does not silently alter your control set.
What the paid gates mean for regulated buyers
The paid gates matter most where access control and evidence are examined. Twenty's pricing page places SSO, row-level permissions and audit logs on the Organization and Enterprise plans, and SCIM provisioning and IP allow-listing on Enterprise. In a bank, a healthcare provider or a public body, those are the components an assessor will ask about: how staff authenticate (SAML or OIDC through a central identity provider), how records are limited to the people entitled to see them, who changed what and when, and whether access can be restricted to approved network ranges. Map each one to a control objective in your own framework before you decide whether the free core can carry the load. Role-based permissions in the free core are a different control from row-level permissions, so confirm which one your access policy actually needs.
DeployOpen prepares systems, configuration, documentation and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination. Ask your auditor, before build starts, which controls the free core can satisfy on its own, which need a compensating control you build yourself (for example, a reverse proxy or firewall that enforces IP restrictions and logs them), and which would require a paid plan. Also confirm how your regulator or customer contracts treat self-built logging compared with an audit log feature the vendor supports.
The practical decision is a short list of gates to test in a non-production workspace: SSO enforcement and account deprovisioning, the audit log's fields and retention, the behavior of row-level rules against your data model, and where IP restrictions are enforced. Request written confirmation of the plan each feature requires from Twenty before you cost the project, because the pricing page is the public reference and your contract is the binding one. Enterprise pricing on the pricing page is stated from 50,000 dollars a year, so for a small regulated team the comparison between a paid tier and building equivalent controls is a real budgeting question.
What drives the cost of each Twenty edition
What does Twenty charge per user for Pro, Organization and Enterprise?
Twenty's 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 US dollars a year. The Organization tier adds row-level permissions, SAML or OIDC SSO and audit logs, while Enterprise adds single-tenant isolation, IP allow-listing, SCIM provisioning and an SLA. Per-user prices multiply by your seat count, so a 40-seat team on Organization pays 760 US dollars a month before any tax or discount terms. Confirm current figures on the Twenty pricing page because published prices can change.
Is the Enterprise plan priced per user or as an annual figure?
The published Enterprise price is an annual figure, starting from 50,000 US dollars a year, not a per-user rate. The pricing page does not break that figure down by seat, so the amount you pay depends on the scope agreed with Twenty. Ask Twenty in writing what the annual fee covers, whether it includes single-tenant hosting, support terms and the SLA, and how it is invoiced and renewed. Check the same Twenty pricing page for the current wording.
What does the free self-hosted Twenty core cost to run each month?
The core license costs nothing, but running it is not free. Recurring costs include the compute for the server and worker, PostgreSQL and Redis hosting, storage and backups, and outbound networking. Twenty's Docker Compose guide asks for at least 2 GB of RAM because insufficient memory can crash processes, so the baseline is a host with that memory plus room for the database. Cloud and data center rates vary by provider and region, so price the four components against your own environment.
What one-time and recurring work does self-hosting Twenty require?
One-time work includes the initial install, configuring PostgreSQL and Redis, setting up TLS, and building the backup and restore process. Recurring work includes applying upgrades, since Twenty ships frequent releases, monitoring the worker queue, rotating secrets, testing restores and patching the host. Each item costs staff time, and that time is the largest hidden cost for most teams. Ask any implementation partner to list these tasks as separate line items so you can see which are one-time and which repeat each quarter.
Who gets paid for what when you buy a Twenty plan or run the core?
With a paid plan, you pay Twenty per seat or per year for the software and the features listed on its pricing page. Your cloud provider bills separately for the infrastructure you run, and your own staff or a services partner handle installation, upgrades and support. A fixed-scope implementation is quoted separately from the subscription, so keep the two out of one number. When you request a quote, ask which costs are included, which are the vendor's, and which fall to your team.
What should I ask for in a quote for a self-hosted Twenty deployment?
Ask for a written scope that names the Twenty edition, seat count, hosting location, and whether SSO, row-level permissions, audit logs, SCIM or IP allow-listing are in scope. Request separate line items for the initial build, PostgreSQL and Redis configuration, backup and restore testing, upgrade handling and staff training. Also ask what is excluded, how changes to scope are priced, and what support window applies after go-live. DeployOpen works from fixed, written scopes and does not publish a price list, so a quote follows from that scope.
Does the free core include the features regulated teams usually need?
According to Twenty's pricing page, the free open-source core includes unlimited custom objects, fields, views and records plus REST and GraphQL APIs and webhooks. SSO, row-level permissions, audit logs and encryption key rotation are listed for Organization and Enterprise, and SCIM and IP allow-listing for Enterprise. If your controls depend on those features, budget for the paid plan or an equivalent control you build yourself, and confirm the boundary on the Twenty pricing page before you decide.
How does the cost gap between the core and paid plans change over time?
The gap depends on seat count, how many controls you must meet, and how much in-house operating time you can spare. A small team with no SSO requirement may find the core and its staff time sufficient, while a regulated team needing audit logs and SSO may find the paid seat price cheaper than building and maintaining those controls. Model both options for your seat count over the period you plan to run the system, and include staff time and backup testing in the self-hosted column. This is an illustrative comparison, not a forecast.
Moving from the free core to a paid plan, or back
This sequence shows how a team moves from the free self-hosted Twenty core to an Organization or Enterprise plan, what each step proves, and what changes if the team later returns to the core. It is written so that security, compliance and platform owners can agree the scope before any licence is bought.
Confirm which paid features your controls require
Before anything is installed, the security lead lists the controls the regulator, auditor or internal policy expects, such as SSO, row-level access, audit logging, SCIM provisioning and IP allow-listing. Map each one to the plan that Twenty's pricing page lists for it. Ask Twenty in writing which plan includes each feature, whether features are tied to the Enterprise license header in the code, and how the licence is applied to a self-hosted instance. The step is done when the requirements list is signed by the security and compliance owners and matched to a named plan.
Back up and version the self-hosted instance
The platform team takes a full PostgreSQL backup, records the Twenty release in use, and stores the Docker Compose configuration, environment files and secrets under version control. Test a restore on a separate host before any change to the licence or plan. This matters because the plan change is applied to a running instance that holds CRM data. The step is done when a restore test completes and the team can name the release and configuration it would roll back to.
Apply the plan and enable SSO
The platform engineer applies the paid licence or plan to the instance as Twenty documents it, then configures SAML or OIDC against the corporate identity provider. Test sign-in with a small pilot group, including a user who is removed from the directory, to confirm that access follows the identity provider. Keep local administrator access for break-glass recovery and document who holds it. The step is done when pilot users sign in through SSO, the break-glass path is tested, and the change is recorded in the change log.
Migrate permissions to row-level rules
The CRM owner maps existing role-based permissions to row-level rules that limit which records each team or user can read and change. Start with the most sensitive objects, such as accounts, contracts and personal data fields, and test each rule with accounts from every role. Compare the results with the access matrix approved by the data owner. The step is done when every role has a documented test case that returns the expected records, and the matrix is updated to match the live configuration.
Validate audit log coverage
The security team runs a set of defined actions, such as creating a record, changing a field, exporting data, changing a permission and deleting a record, and checks that each one appears in the audit log with the user, time and object. Confirm with Twenty how long audit entries are retained, where they are stored and whether they can be exported to the team's log platform. The step is done when every test action is traced in the log and the retention and export answers are recorded for the auditor.
Complete provisioning, network and key checks
If the plan includes SCIM provisioning and IP allow-listing, the identity team tests account creation and removal from the directory and confirms that only approved networks can reach the instance. The security lead also confirms the encryption key rotation procedure that the plan lists, and whether rotating keys requires downtime. The step is done when a test joiner and leaver are provisioned and deprovisioned correctly, blocked addresses are refused, and the key rotation runbook has been rehearsed in a non-production copy.
Record the reverse path and data-control terms
Before the plan is accepted as final, the procurement and legal leads document what happens if the team returns to the free core: which paid features stop working, whether permission rules and SSO settings survive, and how data is exported. Ask Twenty to confirm the licence terms that apply to self-hosted Enterprise code, including whether files under the Enterprise license header are covered by a commercial agreement. The step is done when a written answer on downgrade behaviour and data export is on file and the exit plan is approved.
Questions buyers ask before choosing a Twenty plan
Can our team run the free self-hosted Twenty core without outside help?
Yes, if you have people who can operate a Docker Compose stack with a server, a worker, PostgreSQL and Redis, and who can handle backups, upgrades and monitoring. The Docker Compose self-hosting guide asks for at least 2 GB of RAM, and insufficient memory can crash processes, so size the host with headroom. The core itself is free under the AGPL-3.0 with an application exception, so the cost is staff time and infrastructure rather than a license fee. Whether your team has the skills is the real question. If nobody on the team has run PostgreSQL in production or patched a Redis-backed service, plan for that gap before the first go-live.
What does running the free Twenty core require from our infrastructure team?
The work falls into four areas. First, hosting: a server with at least 2 GB of RAM for the Docker Compose stack, plus network, TLS and reverse proxy setup. Second, data services: PostgreSQL for records and Redis for queued work, each needing backups, restore tests and capacity checks. Third, the application: applying new releases, which ship frequently, and testing custom objects and workflows after each upgrade. Fourth, identity and access: if you need single sign-on, row-level permissions or audit logs, those features sit on paid plans, so the free core handles access through role-based permissions alone. Ask your team to map each area to an owner before committing.
Which Twenty features require an Organization or Enterprise plan?
According to Twenty's pricing page, SSO, 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 only. The pricing page also says all plans include unlimited custom objects, fields, views and records, plus REST and GraphQL APIs and webhooks. For a regulated buyer, the practical split is that identity, access granularity and evidence features are the paid part, while the data model and APIs are not gated. Confirm the current feature list on the pricing page before you finalize a plan choice, since plan contents can change.
What does Twenty cost per user on the paid plans?
Twenty's 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 US dollars a year. These are subscription fees paid to Twenty for the hosted or licensed offering, and they recur for as long as you keep the plan. Your total cost also includes your own infrastructure if you self-host, plus staff time for setup and upgrades. Costs rise with user count on Pro and Organization, and Enterprise pricing depends on its own terms. Ask for the scope in writing and compare it with the per-user figures for your headcount.
How long does it take to move from the free core to a paid plan?
The supplied sources do not give a duration for moving between editions, so confirm it with Twenty and with your own environment before planning. The work depends on how the instance is hosted, how much custom data and configuration exists, whether identity moves to SAML or OIDC, and how many users need re-provisioning. Ask Twenty what the upgrade path looks like for your deployment model and whether any data or configuration changes are required. Test the move in a non-production copy first, and keep a verified backup of PostgreSQL before you start.
Can DeployOpen scope the work for a Twenty deployment, and what does a quote need?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. To get a useful quote, provide your user count, hosting target, identity provider, data volume, required plan features, backup and recovery expectations, and who will own operations afterward. Ongoing support and upgrades are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
Does the free core meet our compliance needs without paid features?
The answer depends on what your assessor asks for. The free core can be self-hosted within your own network, which keeps data residency under your control, and it includes role-based permissions. Items such as row-level permissions, audit logs, SSO and key rotation are paid features, so if your controls depend on them, the free core will need compensating controls or an upgrade. Compliance frameworks are assessed by independent auditors and certification bodies, not by DeployOpen or Twenty. Map your control requirements to the features first, then confirm with your assessor which evidence they will accept.
How DeployOpen scopes a Twenty edition decision
DeployOpen plans, implements, hardens, backs up and supports self-hosted Twenty inside your own infrastructure, whether that is your cloud account, a data center or an isolated network. The edition decision changes the scope of that work. If you stay on the free core, the work centers on the server, the worker, PostgreSQL and Redis, plus your own identity and access design. If you need SSO, row-level permissions or audit logs from the Organization or Enterprise plans, the scope also has to say how those features are configured, tested and evidenced against your requirements. Most engagements are fixed-scope, so the deliverables, environments and acceptance checks are agreed in writing before any work starts.
Before that scope is written, ask us and your Twenty account team to confirm which features each plan includes at the time of purchase, because plan contents can change. Confirm which controls your regulators or auditors expect to see, and whether a feature listed for a paid plan is one you can satisfy another way. DeployOpen prepares systems, configuration and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies do that work, so agree early on the evidence they will need from the environment.
Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope work. Ask for a written quote that splits one-time implementation from recurring retainer scope, and that states who handles Twenty release upgrades, database migrations and backups after go-live. DeployOpen does not publish a price list, and this page does not estimate what your engagement will cost. A quote follows from the written scope, so the edition decision and the scope decision should be made together.
How DeployOpen delivers Twenty on either edition
DeployOpen plans and implements self-hosted Twenty inside your own cloud accounts, data centers or air-gapped networks, whether you run the free core or a paid plan. We start from a written scope that settles which features your controls depend on, then build, document and hand over the deployment so your team can operate it.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We map which access controls your team needs, such as SSO, row-level permissions or audit logs, to the edition that provides them.
- The written scope states who holds the Twenty license terms and plan entitlements, so procurement knows what it is buying.
How we build
- We deploy the server, worker, PostgreSQL and Redis components in your environment, sized against the stated 2 GB minimum memory.
- We configure identity integration and role-based permissions against your directory, then test sign-in and access boundaries.
- We security test the deployment and record results, so you can review hardening decisions before go-live.
How we hand over
- You receive documentation covering architecture, configuration, backups and the upgrade steps for your chosen release line.
- We document which features sit behind a paid plan, so your compliance evidence matches what is actually enabled.
- Handover includes a walkthrough with your platform and security staff so operations stay with your team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Before any upgrade, we check release notes against your configuration and confirm the edition still covers your required controls.
- Confirm with Twenty and your own environment which plan terms apply to your deployment before you sign a contract.
