Teleport vs JumpServer: which to choose

Teleport vs JumpServer: when each platform is the right choice

Choose Teleport when your main job is certificate-based access to SSH, Kubernetes, databases and Windows hosts, and when you want short-lived certificates in place of shared keys and tokens. Teleport states it is fully compatible with OpenSSH servers and clients, so existing SSH workflows can often stay in place. Choose JumpServer when your team wants one web workspace covering SSH, RDP, Kubernetes, databases, websites, RemoteApp and VirtualApp, with bastion-style session control. JumpServer's free Community edition covers up to 5,000 assets in a standalone topology, which suits a mid-sized estate that does not yet need high availability.

The decision turns on five questions. First, how many users and protected resources you will carry, since Teleport prices on active users and protected resources and JumpServer tiers on asset counts. Second, whether Teleport's Community license fits your organization: its distributed builds are limited to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, so confirm this with your legal team before you deploy. Third, which protocols matter most to your admins, especially Oracle, SQL Server and RDP. Fourth, whether you need approval workflows, password rotation or HA, which JumpServer lists as Enterprise features or tiers. Fifth, whether you prefer to run a single Go binary or a multi-container installer that you must maintain.

Before you shortlist either platform, run a short proof of concept against your own protocols and identity provider. Confirm which SSO options your edition supports, because Teleport's Community edition limits single sign-on to GitHub, and confirm the approval and recording features your auditors expect. Ask each vendor for a written quote that states the asset or user count, the edition and the HA topology, since neither publishes a fixed price for Enterprise. A precise quote makes the comparison fair and shows which platform's costs will rise as your estate grows.

Which platform fits which scenario

This table matches five common team situations to the platform that fits better, and states the condition under which the other platform would be the stronger choice. Read each row against your own protocols, headcount and compliance obligations, since the better fit often turns on a single requirement. Teleport leads where short-lived certificates and Kubernetes access matter most, while JumpServer leads where a web workspace and Windows reach are central.

Scenario	Better fit and reason	Choose the other platform when
DevOps team managing SSH and Kubernetes	Teleport. Certificate-based access with automatic expiry replaces shared keys and Kubernetes tokens, and it is fully compatible with OpenSSH clients and servers.	Your engineers mostly need RDP or web consoles through a browser, in which case JumpServer's web workspace fits better.
Team that mostly reaches Windows RDP and web-based consoles	JumpServer. Its web workspace covers SSH, RDP, Kubernetes, databases, websites and RemoteApp in one interface, and the Tinker Windows connector is free in Community Edition.	Your estate is mainly infrastructure access with CLI workflows and Kubernetes, where Teleport's certificate model is the stronger match.
Regulated environment needing approvals and recording	Depends on edition. Session recording with playback is in both Teleport editions, but moderated sessions and dual authorization are Enterprise features. JumpServer's ticket and just-in-time approval workflows are listed as Enterprise features too, so confirm the paid tier you need.	Your assessors require approvals and recording on the Community build, which neither platform's free tier fully covers. Ask each vendor to confirm the exact edition for your controls.
Small company under the Teleport Community license limits	JumpServer Community may fit better if you want no employee or revenue threshold on its GPL-3.0 code, and it supports up to 5,000 assets in a standalone topology.	You fall under the Teleport Community limit of fewer than 100 employees and less than $10,000,000 in annual revenue, and you accept GitHub-only SSO and CLI-only role requests.
Larger company that needs high availability	Confirm the edition first. JumpServer lists active-standby HA from the Standard tier and a full HA cluster in Ultimate, while Teleport HA depends on its deployment model, so ask both vendors for a written HA design.	Your requirement is a multi-node HA deployment inside the Community license, where HA capability and edition limits must be verified against each vendor's current documentation.

How Teleport and JumpServer are built and deployed

Teleport and JumpServer both sit in front of servers, clusters and databases, but they get there differently. One is a single identity-aware binary with its own certificate authority, the other is a bastion host built from several cooperating components. The cards below cover what each design means for installation, upgrades, patching and high availability.

Teleport as a single binary

Teleport ships as a single Go binary that bundles the identity-aware access proxy, a certificate authority issuing short-lived certificates, access control and a tunneling system for resources behind the firewall. It can run as a Linux daemon or as a Kubernetes Helm deployment. For your team, the question is whether one binary and one configuration surface fits your operating model, and whether your patch process can roll that binary across every proxy node without a maintenance gap.

JumpServer as a bastion host

JumpServer is a bastion host built from separate open-source components: Lina for the web interface, Luna for the web terminal, KoKo as the protocol connector and proxy, and Chen for web database access. The quickstart installs from a quick_start.sh script on a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM. Expect more moving parts to monitor and back up than a single binary, and confirm the sizing against your expected session load.

Upgrades and patch cadence

Teleport and JumpServer both publish frequent releases, so the operating cost lies in how often you take them. Teleport's changelog shows several 18.11 point releases in a short window, and JumpServer shipped v5.0.0 and v5.1.0 within weeks of each other. Ask each vendor how long older lines stay supported, which upgrades need a database migration, and whether a rolling upgrade keeps sessions alive during the change window.

Private components in JumpServer Enterprise

JumpServer lists several components as private Enterprise features: Panda for Linux application connection, Razor for RDP, Magnus for database protocols and Nec for VNC, plus a session recording transcoding worker. If your estate depends on Oracle, SQL Server or RDP proxying, these components are part of the decision, not an add-on. Confirm which protocols each edition actually routes through the open-source components, because the Community Edition does not include these private proxies.

High availability is a topology decision

JumpServer's pricing page ties active-standby HA to the Standard and Pro tiers and a full HA cluster to Ultimate, while the Community edition is listed for a standalone topology. Teleport's HA design depends on how you deploy its auth and proxy services and backing storage in your own environment. Before committing, draw the failure domains for your data centers or cloud zones, then confirm with each vendor which components can be made redundant and how failover is tested.

Protocols, recording, approvals and HA side by side

This table sets Teleport's protocol and governance features against JumpServer's, with edition notes where the supplied facts give them. Where availability is not confirmed, the cell tells you what to ask each vendor before you commit, so check those rows against your own requirements.

Capability	Teleport	JumpServer
Protocols and targets	SSH, Kubernetes, PostgreSQL, MongoDB, CockroachDB, MySQL, MCP servers, internal web apps and Windows hosts	SSH, RDP, Kubernetes, databases, websites, RemoteApp and VirtualApp. Oracle and SQL Server access is listed as Enterprise.
Session recording and playback	Recording with playback in both Community and Enterprise editions	Recording exists, but the transcoding worker is an Enterprise component. Confirm recording and playback scope in Community.
Moderated sessions and dual authorization	Enterprise only	Not covered in the supplied facts. Confirm availability and edition with JumpServer before planning reviewer workflows.
Approval workflows	Community requests roles through the CLI only. Enterprise adds just-in-time access requests and reviews under Identity Governance.	Ticket and just-in-time approval workflows are listed as Enterprise features.
Single sign-on by edition	Community supports GitHub only. Enterprise adds Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML.	SSO is listed as an Enterprise feature. Confirm which identity protocols the Community build supports.
High availability	Not covered in the supplied facts. Confirm the supported HA topology and any edition limits with Teleport.	Community runs standalone. Standard and Pro add active-standby HA, and Ultimate adds a full HA cluster.
FIPS and FedRAMP	FIPS binaries and FedRAMP controls are available only in self-hosted Enterprise	Not covered in the supplied facts. Ask JumpServer for any FIPS or FedRAMP-related builds or documentation.
Community edition scale limit	Community builds are limited to organizations under 100 employees and under $10,000,000 annual revenue	Free self-hosted Community edition covers up to 5,000 assets in a standalone topology, per JumpServer's pricing page.

Licensing, editions and paid features for each platform

Teleport's licensing has three layers. The API module is Apache 2.0, the rest of the source code is AGPL-3.0, and the Community Edition builds that Teleport distributes use a modified Apache 2.0 license. The last layer decides eligibility, so read it first. The Community Edition license makes the distributed builds available only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue.

Community eligibility: Organizations above either threshold need a commercial agreement with Teleport for the distributed builds. Measure your headcount and revenue against the license text, not against a rough estimate.
Critical security patch exception: The Community license carves out designated critical security patch versions. Confirm which versions qualify in the Community license file before you depend on it.
Enterprise single sign-on: Community limits SSO to GitHub. Enterprise adds Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML.
Identity governance: Just-in-time access requests and reviews, access lists, access reviews, locks and SCIM provisioning are Enterprise features.
Session and hardware controls: Moderated sessions, dual authorization, Device Trust and HSM support are Enterprise only. FIPS binaries and FedRAMP controls apply to self-hosted Enterprise.

Confirm the threshold wording and the AGPL-3.0 boundary against the current license files with your legal or procurement team, because they determine whether the Community build is available to you at all.

How Teleport and JumpServer handle SSO and identity integration

Teleport Community Edition limits single sign-on to GitHub, and that single fact often decides the identity design before any other comparison matters. Teleport Enterprise adds Google Workspace, Microsoft Entra ID, Okta, SailPoint, and generic OIDC and SAML connectors. If your workforce identity lives in Entra ID or Okta, a Community deployment means either running a GitHub-based login for administrators or accepting that Teleport will not sit inside your main IdP's sign-in and lifecycle controls. Confirm which connector your directory needs against the Teleport feature matrix before you commit to an edition, because the feature matrix is the source that defines what each edition supports.

JumpServer needs a directory or identity source too, but the edition boundary sits in a different place. JumpServer's pricing comparison lists SSO, RADIUS, LDAP high availability and cloud asset sync as Enterprise features, so do not assume Community includes them. Ask the vendor to confirm, in writing for the version you plan to run, whether Community supports the login methods your staff use, whether RADIUS or LDAP can be used for authentication, and how LDAP failover behaves. An LDAP outage that locks out every administrator is an operational risk to plan for, not a detail to discover in production.

Teleport's certificates are short-lived and expire automatically, so users re-authenticate on a schedule instead of holding long-lived SSH keys or Kubernetes tokens. That lowers the risk of stale access but moves work into the login and renewal path, so test session expiry, SSO outages and certificate renewal with your SSO provider before rollout. Role requests add a further constraint: in Community Edition, roles can only be requested through the CLI, so there is no built-in approval queue. If your change process requires a documented approver for every elevated role, that is an Enterprise requirement to price in. JumpServer's approval workflows and just-in-time approvals are Enterprise features, so confirm that approvals fit your process on either platform before you assume they are available.

What drives the running cost of each platform

Neither Teleport nor JumpServer publishes a single running-cost figure for a deployment like yours. The cards below separate the license or subscription from the infrastructure, people, support, upgrades and growth costs that surround it, and list what to request in writing before you compare totals.

License and subscription fees

JumpServer Community is free to self-host up to 5,000 assets in a standalone topology, while its Enterprise tiers (Basic, Standard, Pro and Ultimate) are priced by quote. Teleport states that customers pay for active users and protected resources, and it does not publish prices. Ask each vendor for the price basis in writing: the unit it counts, the renewal term and what happens when your count rises. Confirm whether the Teleport Community license fits your organization size, since its limits are set by employee count and revenue.

Infrastructure sizing and HA nodes

JumpServer's quickstart calls for a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM for a single node. Its Standard and Pro tiers add active-standby HA, and Ultimate adds a full HA cluster, which means extra nodes, load balancing and database capacity you run yourself. Teleport can run as a Linux daemon or a Kubernetes Helm deployment, so its footprint depends on your cluster and backend choices. Ask both vendors for their recommended node counts for your session volume and high availability target.

Skills to operate each platform

Teleport's main operating skill is running its certificate authority, short-lived certificate issuance and role design, and it remains compatible with OpenSSH clients and servers. JumpServer's skill set centers on its installer project, container images and the proxy components (KoKo, Luna, Lina) that handle protocols and the web workspace. Staff time is usually the largest recurring cost in self-hosting. Ask for a named training or handover scope in any quote, and ask who maintains the installer and certificate rotation runbooks after handover.

Support tiers and response commitments

JumpServer Community is supported through GitHub and the forum, which means no contracted response time. Its Enterprise tiers add email and ticket support with an SLA and an account manager, and the SLA terms belong in the order form. Teleport's support tiers are not described in the supplied facts, so you should request its support levels, response targets and escalation path in writing. Compare these commitments against how quickly your team needs a fix during an access incident.

Upgrade effort and release cadence

JumpServer v5.1.0 was published on October 15, 2026, after v5.0.0 on September 17, 2026, and maintenance releases v4.10.19 and v3.10.23 shipped in August 2026, so you may need to plan upgrades across several release lines. Teleport 18.11.4 was released on October 14, 2026, following 18.11.3 on October 2, 2026. Estimate the upgrade effort per platform by counting your environments, custom roles, recording storage and integrations. Ask each vendor which versions receive security fixes and how long each line is supported.

Cost of growth in assets and users

Growth costs follow the unit each vendor counts. JumpServer's cost rises as you cross tier boundaries, from 50 assets in Basic to 5,000 in Pro and unlimited assets in Ultimate, and a move from Community to a paid tier is a licensing change rather than a rebuild. Teleport's cost follows active users and protected resources, so onboarding more engineers or databases raises the bill. Model your asset and user growth for the next three years, then ask each vendor for the price at each step.

Moving between Teleport and JumpServer later

This sequence shows how a team moves access from one platform to the other without a gap in coverage, and what evidence it leaves behind. The effort depends heavily on which protocols are in use and how approvals work today, so confirm each rebuilt item in your own environment before cutover.

Inventory users, assets, protocols and retention
Start by listing every user group, every protected asset (SSH hosts, Kubernetes clusters, databases, Windows hosts, web apps) and the protocol each one is reached through. Record where session recordings are stored, how long they are kept and who can replay them. Confirm which protocols each platform covers in its current edition, since Teleport and JumpServer differ in database and Windows coverage by tier. The step is done when the inventory is signed off by the security owner and the platform owner, and every asset has a named access path.
Map identities, roles and audit requirements
Identity mappings usually transfer most cleanly when the user directory is the same source of truth on both sides, so check which single sign-on method each platform uses in your edition before mapping groups. Translate roles into the target model by hand, since the two platforms define permissions differently. Write down the audit obligations that must still be met after cutover, such as retention periods set by your own policy or a compliance framework. The output is a mapping table that a reviewer can check line by line.
Rebuild policies, certificates and approval workflows
Access policies, session timeouts, certificate lifetimes and approval workflows generally do not move as data. Teleport issues short-lived certificates, while JumpServer relies on its own bastion sessions, so plan each target-side configuration separately. Rebuild approval paths against the approval model in use: Teleport's request and review workflow is part of Enterprise Identity Governance, and JumpServer's ticket and just-in-time approval workflows are listed as Enterprise features. Confirm each rebuilt approval in a test environment with a named reviewer. The step closes when every approval path has been exercised once.
Rewire bastion connection paths
Update client configurations, SSH config files, Kubernetes contexts and database connection strings so users reach assets through the new platform. Keep a list of every client and automation job that currently connects through the old bastion, because scripts and CI pipelines are the most common gaps. Where Teleport is the target, confirm OpenSSH client compatibility for the protocols in use before changing scripts. The output is a tested connection path for each asset class, with a rollback path recorded.
Run both platforms in parallel during cutover
Keep the existing platform active while a pilot group of users and a limited set of assets move to the new one. Compare session logs and recordings from both sides to confirm that the same activity is captured and that access denials match the intended policy. Expand the group in stages, and only retire a path once it has run cleanly through a full operating cycle chosen by your change board. The step is complete when the pilot group has no open access issues and every asset class has been moved.
Decommission and retain evidence
Revoke remaining access on the old platform, disable its accounts and stop its services only after the cutover sign-off. Export session recordings and audit logs in a format your retention policy and any applicable compliance framework accept, and store them where authorized reviewers can still reach them. Confirm with your auditors or compliance lead which records they will require and for how long. The step is done when an evidence package exists, access to the old system is removed, and the decommission record is approved.

What implementing each platform involves and where projects run long

Teleport implementation starts with installing its single Go binary as a Linux daemon or as a Kubernetes Helm deployment, then standing up the certificate authority that issues short-lived certificates to users and hosts. Most of the remaining work is policy: defining roles that map identities to SSH logins, Kubernetes groups and database users, and deciding who can request each role. Identity connectors come next. Community Edition limits single sign-on to GitHub, so teams that need Okta, Microsoft Entra ID or Google Workspace should confirm the edition in the Teleport feature matrix before design starts. Each SSH node, cluster and database then needs a Teleport agent joined to the cluster. Because Teleport is compatible with OpenSSH clients and servers, existing authorized_keys entries can stay in place during migration, but someone must own the decision of when they are removed.

JumpServer is installed on a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM, using the quick_start.sh script from its GitHub releases, and its installer project handles later management. Once the platform runs, the work moves into its data model: registering assets, creating system accounts, granting users and user groups access to assets through permissions, and deciding whether account secrets are stored and rotated centrally. Approval workflows, password rotation, custom roles and cloud asset sync are listed as Enterprise features on the JumpServer pricing page, so confirm the edition before designing those controls. Session recording storage also needs a decision. Confirm retention location, capacity and backup approach with the vendor and test them in your own environment before go-live.

Projects usually run long in four places. The first is onboarding: every host, cluster and database must be enrolled in Teleport, or every asset registered in JumpServer with the correct accounts, and both slow down when inventories are incomplete. The second is mapping existing shared keys and bastion paths, where old jump-host habits and shared credentials must be traced before they can be retired. The third is approval and recording policy: deciding which sessions need moderation or approval, who reviews them, and how long recordings are kept. The fourth is high availability and disaster recovery testing. JumpServer's Standard and Pro tiers offer active-standby HA and Ultimate offers a full HA cluster, while the Community edition is standalone and listed up to 5,000 assets. Test failover against the edition you intend to buy, and confirm Teleport's HA and recovery design the same way. Scope, deliverables and timelines are agreed in writing before any fixed-scope work starts. DeployOpen does not publish a price list, and a quote follows from that written scope.

Questions buyers ask before choosing Teleport or JumpServer

What drives the cost of running Teleport or JumpServer?

Software licensing is only part of the cost. For Teleport, the published pricing model charges for active users and protected resources, and deployment can be on premises, in the cloud or hybrid, but Teleport does not publish prices, so the quote is the source of truth. For JumpServer, the Community edition is free for self-hosted use up to 5,000 assets in a standalone topology, while Enterprise tiers are priced by quote. In both cases, the recurring costs are the infrastructure you run, the staff time to operate it, and any subscription or support plan. Ask each vendor to state in writing which metric (users, assets or resources) they bill on and how growth is counted.

How long does a Teleport or JumpServer rollout usually take?

No duration is fixed by the researched facts, so treat any single number as unverified until it is scoped. The duration depends on the number of protected resources, the protocols you need (SSH, Kubernetes, databases, RDP or web access), how many identity sources must be connected, and whether you run a high availability topology. JumpServer's quickstart describes a single 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM as the starting point, while high availability on JumpServer is tied to Enterprise tiers. Ask for a written scope that lists each resource type, integration and environment, and agree the timeline against those deliverables.

What does our team need to provide for a privileged access deployment?

Plan for four inputs: identity, network, change control and staff time. On identity, you need an existing directory or SSO source and a decision on who gets which roles, because Teleport Community Edition limits single sign-on to GitHub, while Enterprise adds Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML. On the network, both platforms need a reachable host that users and protected systems can route to, and you need firewall rules agreed in advance. Change control must cover the bastion or proxy as a critical system. Staff time should include at least one owner for upgrades and access reviews. Confirm each item with your own security and network teams before work begins.

Can our internal team deploy this without outside help?

Yes, if your team has Linux operations skills, experience with certificates or SSH access policy, and capacity to own the platform after go-live. JumpServer publishes container images on Docker Hub and an installer project, and Teleport runs as a single Go binary or a Kubernetes Helm deployment, so the install itself is not the hard part. The harder work is access policy design, identity integration, session recording retention, and testing failover if you need high availability. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in the client's own infrastructure, typically under a fixed-scope written agreement. Compare the internal effort against that scope before deciding.

Is the Community Edition enough for our organization?

It depends on your size, your identity provider and the features you need. The Teleport Community Edition license applies 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, so check that limit against your current headcount and revenue before relying on it. JumpServer Community edition is free for self-hosted standalone use up to 5,000 assets, but Enterprise features such as multi-tenancy, SSO, RADIUS, LDAP high availability and ticket or just-in-time approval workflows are not included. If you need approvals, moderated sessions or SSO beyond GitHub, price the Enterprise option before you commit.

How hard is it to switch between Teleport and JumpServer later?

Switching is mostly a re-policy exercise, not a data migration, because the two platforms use different access models. Teleport issues short-lived certificates and is fully compatible with OpenSSH clients and servers, so moving SSH access usually means changing how users authenticate and retiring shared keys. JumpServer manages access through its own bastion workspace and asset inventory, so you would re-create assets, accounts and permissions in the new system. Session recordings and audit logs do not transfer as a working set, so decide how long you must keep the old records. Ask any implementer to list the assets, roles, recording archives and identity mappings that would move.

What should a written quote include for either platform?

A usable quote lists the scope before the price: each protected resource type (SSH nodes, Kubernetes clusters, databases, Windows hosts, web apps or RDP systems), the number of users or assets, the identity sources to integrate, and the target environment. It should separate one-time work such as installation, integration, hardening and documentation from recurring work such as upgrades, backups, support and continuous testing. For Enterprise licensing, ask which edition, tier and support terms apply, and whether support includes an SLA. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides ongoing support and upgrades as retainers. Ask for the acceptance criteria and the exit terms as well.

How DeployOpen helps you choose and implement a privileged access platform

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Teleport vs JumpServer decision can be tested against your real access paths before anything is deployed. The work starts with a written scope and moves through build, testing and handover, with ongoing support available afterward.

How we scope

We map which SSH, Kubernetes, database, RDP and web targets need privileged access and who reaches them.
We confirm edition requirements against your user count, asset count and identity provider before choosing a platform.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.

How we build

We deploy the chosen platform in your cloud account, data center or air-gapped network, with your own hosting choices.
We configure SSO, roles, approval workflows and session recording to match the access policies you already document.
We test access paths, recording playback and high availability settings, then document results for your reviewers.

How we hand over

You receive configuration documentation, runbooks for onboarding and offboarding users and targets, and backup procedures.
We walk your administrators through daily operations, upgrades and the evidence needed for internal or external assessments.
We prepare controls and evidence for compliance assessments, while independent auditors or certification bodies issue any formal conclusions.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover version upgrades for the platform you run, including reviews of release notes before each change.
Ask for a quote built from the written scope, since DeployOpen does not publish a price list.

Teleport vs JumpServer