When Teleport Community Edition is enough and when Enterprise is needed
The Community license depends on your organization's size and revenue, and Enterprise is needed for single sign-on beyond GitHub, access requests, Device Trust or FIPS builds. Start by checking the Community Edition license against your headcount and annual revenue. The distributed Community builds are available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. If you fall outside those limits, the choice is already made for you, and the remaining questions are about which Enterprise deployment model fits. Confirm the employee and revenue figures with your legal or procurement team, since the license text is the governing document, not a summary.
A Community deployment fits a small team that authenticates through GitHub, that is comfortable with roles being requested through the CLI, and that does not need device posture checks before a session starts. Certificate-based access for SSH, Kubernetes, PostgreSQL, MySQL and the other supported resources works in both editions, and session recording with playback is included in Community. The practical risk is growth: if headcount or revenue crosses the license threshold, you will need to move to a commercial edition, so plan that change before you build runbooks, role mappings and automation around the Community setup. Ask Teleport how a license transition would affect your existing configuration and certificates.
Enterprise is the right choice when access governance is a formal requirement. The features that matter most are SSO through Okta, Microsoft Entra ID or Google Workspace, just-in-time access requests and reviews under Identity Governance, moderated sessions and dual authorization for privileged actions, Device Trust, and HSM support. Self-hosted Enterprise is also the only route to FIPS binaries and FedRAMP controls, so a regulated team that must show FIPS-validated cryptography should confirm with Teleport which build and deployment model meet its specific standard. Before you commit, read the Teleport feature matrix against your own control requirements and request a written quote that lists the resources, users and support level it covers.
Which Teleport features are paid and which are free
This table compares the Teleport capabilities that Community Edition includes with those that require Enterprise. Read each row against your identity provider, approval model and audit obligations, because a missing feature often means changing a workflow, not just flipping a setting. Session recording with playback is included in both editions, so audit playback alone does not force an upgrade.
| Capability | Community Edition | Enterprise |
|---|---|---|
| Single sign-on providers | GitHub only | Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML |
| Role requests | Roles can only be requested through the CLI | Just-in-time access requests and reviews |
| Identity Governance | Not included | Access lists, access reviews, locks and SCIM provisioning |
| Session recording with playback | Included | Included |
| Moderated sessions and dual authorization | Not included | Included, so sensitive sessions can require a second person to approve or observe |
| Device Trust | Not included | Included, so access can depend on the health and registration state of the device |
| HSM support | Not included | Included, relevant if your CA keys must live in a hardware security module |
| FedRAMP controls and FIPS binaries | Not included | Self-hosted Enterprise only, so confirm the exact scope with Teleport before planning around it |
How licensing, support and updates differ by edition
Teleport's licensing is split across its source tree, so the edition you run depends on both the code and the organization using it. The cards below separate the source license, the Community limits, the critical patch exception and the terms you must confirm before choosing Enterprise.
Mixed source code licenses
Teleport's API module is licensed under Apache 2.0 and the rest of the source code under AGPL-3.0. Community Edition builds distributed by Teleport use a modified Apache 2.0 license, so the license attached to a binary is not the same as the license on every file in the repository. Check which artifact you intend to deploy and read its license before you build internal tooling on top of it.
Community license size limit
The Community Edition license covers distributed builds only for organizations with fewer than 100 employees and less than $10,000,000 in annual revenue. Count affiliates and contractors with care, and confirm with Teleport how it measures the threshold for your corporate structure. An organization that crosses either limit needs to change editions, not just keep running the same binary.
Critical security patch exception
The Community license includes an exception for designated critical security patch versions, so a Community deployment can still receive those fixes even when the organization is over the size limit. The exception covers only versions Teleport designates, so ask Teleport which releases qualify and how it will notify you. Do not assume every patch release falls under it.
Release tracking on the changelog
Teleport 18.11.4 was released on October 14, 2026, following 18.11.3 on October 2, 2026. Track point releases on the changelog and map each one to the edition you run. Confirm the support window for each major line with Teleport before you plan an upgrade cycle, because the changelog does not promise one.
Enterprise terms to confirm
Enterprise is licensed through a commercial agreement that the public license files do not describe. Ask Teleport for the subscription terms, the pricing basis for active users and protected resources, the support response commitments, and the rights to receive patches for each release line. Get these in writing before you rely on Enterprise for production access.
How the Community license limit applies to your organization
The Community Edition limit is set by organization size, not by how you use Teleport. The distributed Community builds are available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, according to the Teleport Community Edition license. Before you deploy, count your headcount and annual revenue against both thresholds, and record the date and figures you used. The license allows an exception for designated critical security patch versions, so confirm with Teleport exactly which builds that covers and how long you may run them if you cross the limit.
A growing company can cross either threshold without changing a line of its configuration. Hiring, an acquisition or a strong year of revenue can move you out of the Community license while your clusters keep running the same version. Plan for that moment in advance: decide who owns the monitoring of headcount and revenue, what triggers a licensing review, and whether your roadmap for access requests, Device Trust or FIPS builds needs Enterprise before you hit the threshold. Teleport's pricing page says customers pay for active users and protected resources and does not publish prices, so ask for a written quote based on your own counts.
The facts supplied here do not settle how employees are counted (for example, part-time, contractor or seasonal staff) or how revenue is measured across a corporate group with affiliated entities. Confirm both directly with Teleport and with your legal team, and get the answer in writing, because the result decides which edition you may lawfully run. Ask Teleport whether affiliates are counted together with your organization and whether the same rules apply to subsidiaries you operate in other countries.
Which edition fits each team situation
Community Edition fits a team that is under the license thresholds, signs users in through GitHub, and does not need a formal approval step before access is granted. The Community license makes distributed builds available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so the first check is whether your organization meets both conditions today and whether it will keep meeting them. Enterprise is worth its cost when the team grows past those limits or needs controls Community does not offer.
- Identity source: Community limits single sign-on to GitHub, so every engineer needs a GitHub identity that your team can govern.
- Approvals: Community roles can only be requested through the CLI, which suits teams that accept informal, peer-agreed access.
- Recording: Session recording with playback is available in both editions, so audit of sessions does not by itself justify Enterprise.
- Growth trigger: Headcount or revenue growth past the Community thresholds moves you out of the license, regardless of how well the platform is running.
Confirm the current license terms and your headcount and revenue against the Teleport Community Edition license before you standardize on it.
A regulated team that already runs Okta or Microsoft Entra ID usually needs its privileged access to follow the same identity lifecycle as the rest of the company. In Teleport, that means Enterprise, because Community does not offer those identity providers and Enterprise adds just-in-time access requests and reviews as part of Identity Governance. The cost is justified when your auditors expect approvals, access reviews and deprovisioning to be evidenced, not just logged.
- SSO providers: Enterprise supports Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML, which covers the identity providers named in this scenario.
- Access requests: Just-in-time requests and reviews replace informal approvals with recorded decisions.
- Access lists and reviews: Identity Governance adds access lists, access reviews and locks, which map to the recurring review step most assessors ask about.
- SCIM provisioning: Enterprise includes SCIM provisioning, so account changes in the directory can flow through to Teleport.
- Moderated sessions: Only Enterprise offers moderated sessions and dual authorization for high-risk sessions.
Confirm with your assessor which evidence they need, then ask Teleport to confirm the exact Identity Governance features and connector versions in your edition before you rely on them.
Teams that must restrict access to managed hardware or run cryptographic modules validated to FIPS standards have no Community path. The feature matrix places Device Trust and HSM support in Enterprise, and FIPS binaries and FedRAMP controls only in self-hosted Enterprise. Enterprise is not optional in this scenario, so the question is whether the requirement is firm or merely preferred, and which deployment model you must run.
- Device Trust: Enterprise only, so confirm your device management tooling can supply the signals Teleport requires before you commit.
- HSM support: Enterprise only, relevant if keys must live in a hardware security module under your key custody rules.
- FIPS binaries: Self-hosted Enterprise only, so a cloud-hosted tenant will not meet this requirement by itself.
- FedRAMP controls: Also self-hosted Enterprise only, which matters for public sector and federal contractors.
- Deployment: Teleport can run on premises, in the cloud or in a hybrid environment, so match the deployment model to the binary you need.
Confirm the FIPS validation status of the specific binary version you will deploy with your compliance lead and the vendor, because validation applies to particular builds.
What each edition costs and what drives the bill
This table separates the cost components of running Teleport Community Edition and Teleport Enterprise, showing who is paid, whether each item is one-time or recurring, and what drives it. Teleport does not publish prices, so use the rows to build the scope you send for a written quote and to compare what each edition's bill would include.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Teleport Enterprise subscription | Teleport, for the licensed edition | Recurring | Active users and protected resources, per Teleport's pricing page |
| Community Edition use | No subscription fee applies only if your organization meets the license limit | Recurring (internal effort only) | Fewer than 100 employees and under $10,000,000 annual revenue, per the Community license |
| Initial deployment and configuration | Internal staff or an implementation partner such as DeployOpen, under a written scope | One-time | Number of clusters, deployment model (on premises, cloud or hybrid), and integrations with identity providers |
| Identity provider and SSO integration | Internal staff or implementer | One-time, plus upkeep when IdP changes | Enterprise SSO options (Google Workspace, Entra ID, Okta, SAML, OIDC) versus GitHub-only SSO in Community |
| Access request and review workflow setup | Internal staff or implementer | One-time, then ongoing review effort | Number of approvers, access lists and review cycles that Identity Governance adds |
| Operating effort and upgrades | Internal platform or security team | Recurring | Release cadence, HA design, backups and on-call coverage for the cluster |
| Support level | Teleport, under the agreed support terms | Recurring | Support tier and response expectations, which the reader must confirm in writing |
| Retainer or ongoing support | DeployOpen or another provider, under a separate written agreement | Recurring, optional | Upgrade, testing and documentation scope agreed in advance |
Moving from Community to Enterprise, and back
This sequence moves a Teleport deployment between Community Edition and Enterprise without losing audit history or breaking established access paths. Each step closes with a check you can file as evidence, and the final step covers organizations that outgrow the Community limits and must move to a licensed edition.
Confirm license eligibility against current limits
Before any technical work, the security or legal owner confirms that the organization still meets the Community Edition license terms: fewer than 100 employees and less than $10,000,000 in annual revenue, as set out in Teleport's Community Edition license. Ask Teleport to confirm how the limits apply to your corporate structure and whether the critical security patch exception covers the versions you run. Done means a dated eligibility record, signed by the approver, with a scheduled date for the next review.
Map GitHub SSO and CLI role workflows
The platform team lists every user who signs in through GitHub SSO and every role requested today through the CLI, because Community Edition supports only those paths. For each entry, record the teams that depend on it, the services that rely on GitHub team membership, and any role granted by hand. Done means a workflow inventory a reviewer can walk through line by line, with each item marked as moving, changing or retiring in the Enterprise design.
Configure Enterprise SSO and access requests
Enterprise supports Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML single sign-on, and includes just-in-time access requests and reviews as part of Identity Governance. An identity engineer connects your chosen provider to a test cluster, sets the approvers for requests, and confirms that a user can request a role, receive approval and have the access expire as designed. Done means a written test record showing one full request cycle, stored with the change ticket.
Migrate roles and access lists
Translate the inventory into Enterprise roles and access lists, grouping users by responsibility and keeping GitHub team names only as a reference. If your policy requires them, configure access reviews, locks and SCIM provisioning now, and confirm each one with the owner of the workflow it affects. Done means a comparison of each user's effective resources before and after the migration, with every difference either removed or signed off by the resource owner.
Validate session recording and audit trails
Session recording with playback is available in both editions, but moderated sessions, dual authorization and Device Trust are Enterprise only, so confirm which of these your controls depend on before cutover. A security engineer starts a recorded SSH, Kubernetes and database session on the Enterprise cluster, plays it back, and checks that audit events reach your log platform with the fields investigators need. Confirm retention with your compliance lead. Done means a filed test record covering playback and log ingestion.
Cut over users and retire Community builds
Announce the cutover to affected teams, point logins to the Enterprise SSO path, and keep the Community cluster available only until every inventoried workflow is confirmed. Once users confirm that access works, remove GitHub-only sign-in and the manual CLI role grants. Done means a closed change ticket, updated runbooks, a list of revoked Community-era credentials, and an archived copy of the old configuration that your audit team has approved.
Move to a licensed edition when limits are exceeded
If the organization grows past the Community limits, it can no longer use the Community builds under that license, so moving to a licensed edition is required and should be scheduled as soon as the threshold is confirmed. Repeat the inventory and validation steps for any Community-only setting in use. Teleport's pricing page says customers pay for active users and protected resources, so ask for a written quote based on your user and resource counts. Moving back down is possible only if the limits are met again, and Enterprise-only controls such as Device Trust must then be removed or replaced. Done means a signed licensing decision and a cutover record.
Questions buyers ask before choosing a Teleport edition
Can a company over the Community Edition limits still use Community?
No, not under the license for distributed Community builds. The Teleport Community Edition license makes the builds available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Counsel should read the full license text and compare it against the company's headcount and revenue at the time of use, since growth can move an organization past the limit. Organizations that exceed the thresholds should ask Teleport about Enterprise licensing before deploying further, and should confirm how the critical security patch exception applies to their situation in writing.
How does Teleport price Enterprise, and what drives the cost?
Teleport does not publish prices. Its pricing page says customers pay for active users and protected resources, and that Teleport can be deployed on premises, in the cloud or in a hybrid environment. The main cost drivers are therefore the number of active users, the number and type of protected resources (SSH nodes, Kubernetes clusters, databases, desktops and similar), and the deployment model. Ask for a quote that lists the user and resource counts it assumes, which Enterprise features are included (for example, Identity Governance, Device Trust or FIPS builds), whether support is included, and how the price changes as users or resources grow. Compare that quote with the internal effort to run the platform, which recurs alongside the license.
How long does it take to move from Community to Enterprise?
The timeline depends on the license agreement, the size of the estate and how much of the current configuration must change. Teleport does not publish an upgrade duration, so ask for one in writing. Work that usually matters includes reconfiguring single sign-on from GitHub to an Enterprise identity provider such as Okta, Microsoft Entra ID or Google Workspace, moving role requests from the CLI into access request workflows, and re-testing access policies against the protected resources. Because Teleport uses one binary, the technical change is not the largest item. Plan a test environment and a cutover window, and confirm with Teleport which steps require a fresh deployment and which are in-place changes.
How much internal effort does each edition need to run?
Both editions run the same core platform, so the baseline operating effort is similar: certificate authority management, cluster upgrades, user and role administration, and monitoring. The difference comes from the features you turn on. Community requires CLI-based role requests and GitHub SSO, which means access approvals are handled outside the platform. Enterprise adds access requests, access lists, access reviews, locks and SCIM provisioning, which move that work into the product but also add configuration, review cadence and integration with your identity provider. Estimate your team's hours against the workflows you will actually run, and confirm with Teleport which of these are operated by your staff versus its support team.
Can a consultant or partner implement Enterprise features for us?
Yes, DeployOpen can plan, implement, integrate, harden, document and support self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Teleport Enterprise is a commercial product, though, so the license relationship sits with Teleport. Before engaging a partner, confirm with Teleport which features your license covers, what partner or reseller arrangements Teleport allows, and who supports the software in production. DeployOpen is not an official partner, reseller or certified provider of Teleport unless that is stated separately.
Which Enterprise controls need confirmation with Teleport before purchase?
Several controls depend on the edition and deployment, so confirm each one with Teleport rather than assuming it. The key items are:
- Single sign-on providers: Community is limited to GitHub, while Enterprise lists Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML.
- Device Trust and moderated sessions or dual authorization, which the feature matrix lists only for Enterprise.
- FIPS binaries and FedRAMP controls, which the feature matrix lists only for self-hosted Enterprise.
- HSM support and the exact session recording features in your deployment model.
Request written confirmation against the current Teleport feature matrix for your deployment type.
Does Community Edition still suit a small team with strong security needs?
It can, provided the organization stays within the license limits and the team accepts the Community feature set. Community still provides certificate-based access with automatic expiration, which replaces shared SSH keys and Kubernetes tokens, and it keeps session recording with playback. The trade-offs are GitHub-only SSO and CLI-only role requests, so approval evidence and identity lifecycle work happen outside the product. If your controls require approval workflows, identity provider integration beyond GitHub, or FIPS builds, plan for Enterprise from the start, because those controls shape the architecture rather than being added later.
What to confirm with Teleport before you buy
The most important thing to settle before any purchase is the current Enterprise license terms, because the supplied facts describe the Community Edition limits but do not set out the commercial terms that apply once an organization outgrows them. Ask Teleport for written answers on how Enterprise is licensed, what counts as an active user and a protected resource under its pricing model, and whether the terms differ between a self-hosted deployment and a Teleport-hosted one. Ask for the support window for each release line you plan to run, since the facts do not state one. Keep the answers in the quote file so procurement can compare them with the scope agreed for the project.
Compliance-driven buyers need firmer answers on two points. FedRAMP controls are listed only for self-hosted Enterprise, but the supplied facts do not say which controls are covered, which authorization status applies, or whether the answer changes with the deployment model, so ask for the scope in writing. FIPS binaries are also limited to self-hosted Enterprise. Ask which FIPS validation certificates apply to the exact build you would deploy, which cryptographic modules are included, and whether any Device Trust or HSM features fall outside that validation. Do not assume an assessor will accept a feature matrix entry as evidence.
Confirm how the critical security patch exception in the Community Edition license applies to the version you run. The license permits use of designated critical security patch versions for organizations above the limit, but the facts do not define what qualifies as designated or how long that permission lasts. Check the Teleport changelog and feature matrix on the day you buy, record the versions you will deploy, and ask Teleport to confirm in writing which of those versions carry the exception. Repeat that check at each upgrade, because a feature listed as Enterprise-only today may move or change in a later release.
How DeployOpen scopes, delivers and supports Teleport deployments
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Teleport, that means working out which edition fits the organization's size, identity provider, compliance evidence needs and access paths before any licence or configuration decision is made.
How we scope
- Confirm the organization's employee count and annual revenue against the Community Edition license terms before any deployment begins.
- Map identity sources, required SSO providers and the resources to protect: SSH nodes, Kubernetes clusters, databases and Windows hosts.
- Agree the scope, deliverables and timeline in writing; most engagements are fixed-scope.
- Record which Enterprise features, such as access requests, Device Trust or FIPS builds, are in scope and which are not.
How we build
- Deploy Teleport in your own cloud account, data center or air-gapped network, as a Linux daemon or Helm deployment, according to the agreed scope.
- Configure the certificate authority, roles, SSO connector and session recording against your access policy.
- Test access paths for SSH, Kubernetes and database resources, including OpenSSH client compatibility where it matters to your teams.
- Confirm the licensing position for each deployed component and record it in the build documentation.
How we hand over
- Deliver configuration, role definitions and runbooks so your own staff can operate and audit the deployment.
- Document the edition decision, including which features depend on Enterprise licensing and what would change if the organization outgrew Community limits.
- Provide evidence collected during build that supports your internal control reviews, while noting that independent auditors issue any audit reports or certifications.
- Walk through upgrade steps, including how to check the current Teleport release line before patching.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover patch review, release upgrades and re-testing of access paths after identity or resource changes.
- Ask any provider to confirm in writing what response commitments, if any, are included in the retainer before you sign.
