When JumpServer Community is enough and when Enterprise is needed
Choose JumpServer Community if you need a bastion host for SSH, RDP, Kubernetes, databases and websites in one standalone deployment of up to 5,000 assets, and your own engineers can run it. The Community edition is free to self-host and licensed under GPL-3.0, so you can read the code, audit it and change it under terms your legal team already knows. Its Windows application connector, Tinker, is also free in Community, which matters if your privileged users open RemoteApp or VirtualApp sessions. Stay on Community when your asset count fits under the cap, your access patterns are mostly SSH and RDP to Linux and Windows hosts, and an internal team can absorb upgrades and incident response through GitHub and the forum.
Move to Enterprise when a specific requirement cannot be met by Community, not because the platform looks more mature. The pricing page lists the Enterprise features that most often trigger the move: Oracle and SQL Server access, password rotation, ticket and just-in-time approval workflows, custom roles, multi-tenancy, SSO, RADIUS and LDAP HA. The tiers also differ on scale and resilience. Basic covers 50 assets, Standard 500 with active-standby HA, Pro 5,000 with active-standby HA and Ultimate an unlimited asset count with a full HA cluster. Before you sign, confirm with JumpServer which tier matches your asset count and HA design, and ask for the written support scope, since Enterprise adds email and ticket support with an SLA and an account manager. Pricing is by quote only, so request it against a stated asset count and topology.
Plan for the cost of running Community in-house, which is paid through your own staff time rather than a license. Someone must own patching, backups, the high-availability design you build yourself, and access reviews. If you expect a regulator or auditor to ask for approval evidence or rotated credentials, check early whether those controls are available in your target edition, because adding them later means an edition change and a new deployment review. Ask JumpServer to confirm which features your environment needs in writing, and test the Enterprise components you depend on in a non-production copy before you commit.
Which capabilities sit in Community and which in Enterprise
This table maps the capabilities named on JumpServer's pricing page and README against the free Community edition and the paid Enterprise tiers. Read each row as a question to confirm with FIT2CLOUD before you commit, because the pricing page lists the features but does not show how each one is configured or tested in your environment.
| Capability | Community edition | Enterprise tiers |
|---|---|---|
| Oracle and SQL Server access | Not listed as a Community feature on the pricing page | Listed as an Enterprise feature on the pricing page |
| Password rotation | Not listed as a Community feature on the pricing page | Listed as an Enterprise feature on the pricing page |
| Ticket and just-in-time approval workflows | Not listed as a Community feature on the pricing page | Listed as an Enterprise feature on the pricing page |
| Custom roles and multi-tenancy | Not listed as a Community feature on the pricing page | Listed as Enterprise features on the pricing page |
| SSO, RADIUS and LDAP HA | Not listed as a Community feature on the pricing page | Listed as Enterprise features on the pricing page |
| Cloud asset sync | Not listed as a Community feature on the pricing page | Listed as an Enterprise feature on the pricing page |
| Enterprise-only protocol proxies (Panda, Razor, Magnus, Nec) | Not included; the README lists these as private Enterprise components | Included as private Enterprise components per the README |
| Tinker Windows application connector | Free for Community Edition per the README | Available with the Enterprise edition |
| Asset limit and topology | Up to 5,000 assets, standalone topology | Basic (50 assets), Standard (500, active-standby HA), Pro (5,000, active-standby HA), Ultimate (unlimited, full HA cluster) |
How licensing and support differ between the two editions
The Community and Enterprise editions share a GPL-3.0 open-source core, but they differ in who supports the platform and what the contract promises. The cards below separate what the license grants from what the vendor sells, so you know what to confirm before choosing a tier.
The GPL-3.0 open-source core
JumpServer is licensed under GPL-3.0, with copyright held by FIT2CLOUD for 2014 to 2026. The license lets your team run, modify and redistribute the open-source components without a subscription. Check with your legal team what the copyleft terms mean if you plan to modify the code or ship a changed build to a third party, since those obligations apply regardless of edition.
Community support through GitHub and forum
Community Edition support runs through GitHub and the community forum, not a contracted service. Issues are answered on the maintainers' schedule, and no response time is promised. If your team depends on a fixed fix window, plan internal capacity to triage issues and test patches yourself, because the community channel does not commit to one.
Enterprise email and ticket support
Enterprise adds email and ticket support with an SLA and a named account manager. Before signing, ask the vendor for the written response and resolution targets, the severity definitions, the support hours, and whether the SLA covers the Enterprise components such as the Oracle and SQL Server connectors. An account manager is only useful if the contract names escalation paths.
Updates under each edition
Community users take releases from the public GitHub releases page, such as the v5.1.0 release published on October 15, 2026, and apply them on their own schedule. Enterprise customers should confirm in writing which versions receive patches, how long older lines are maintained, and whether upgrade assistance is included. Without that written commitment, a Community-style upgrade plan carries the same risk.
Enterprise components and proprietary parts
JumpServer's Enterprise components, including Panda, Razor, Magnus and Nec, are private and not part of the GPL-3.0 open-source code. Your contract should state exactly what rights you hold to these components, whether they can run after a subscription lapses, and what happens to your configuration if you move back to Community.
Contract terms to confirm
Ask the vendor to confirm in writing the term length, renewal rules, the asset count the tier covers, and the price drivers for growth, since the pricing page lists tiers by quote only. Confirm whether HA support, password rotation and approval workflows are included in the tier you buy, and what it costs to change tiers mid-term.
What the free edition is missing for typical enterprise needs
The free Community edition is missing four things that enterprise teams often ask for: Oracle and SQL Server session access, password rotation, approval workflows and HA with vendor support. Each gap matters under different conditions, so map them to your own requirements before deciding. JumpServer's pricing comparison lists Oracle and SQL Server access as an Enterprise feature. If your database administrators work mainly on PostgreSQL or MySQL and the Community edition covers those, this gap may not affect you. If DBAs need named sessions against Oracle or SQL Server, the Community edition does not meet that need, and you should confirm which database protocols each edition supports in the JumpServer documentation before you test.
Auditors who ask for rotated credentials are asking about password rotation, which the pricing page also lists as an Enterprise feature. Rotation matters most when shared or privileged accounts are used across many assets and an auditor expects the vaulted password to change on a schedule. If your accounts are personal, or your access model relies on a separate secrets manager, you may not need rotation inside the bastion. Change control teams that require approvals before a session starts should check the ticket and just-in-time approval workflows, also listed as Enterprise features. Confirm with JumpServer whether approvals in the Community edition meet your change policy, and test one approval path end to end with a named reviewer.
Operations teams need HA and vendor support when the bastion is a single point of failure for production access. The pricing page ties active-standby HA to the Standard and Pro tiers and a full HA cluster to Ultimate, and it describes Enterprise support as email and ticket support with an SLA and an account manager, while Community support runs through GitHub and the forum. If a bastion outage would block incident response, plan for the Enterprise tier or a documented failover design, and ask JumpServer for written support hours and response targets. Edition prices are by quote only, so ask for the asset count, HA topology and support terms in writing before you compare costs.
Which edition fits which team
A small internal IT team running one JumpServer instance on a single Linux server usually fits the Community edition. The free tier covers up to 5,000 assets in a standalone topology, and the team carries the operating work itself, with support coming through GitHub and the community forum rather than a contracted SLA. The main cost is staff time for installation, patching and backups, which recurs with every upgrade cycle.
- Asset ceiling: Community is priced at zero for up to 5,000 assets in the standalone topology, so a team well under that count pays no license fee.
- Protocol coverage: Oracle and SQL Server access, password rotation and approval workflows are listed as Enterprise features, so a team that only needs SSH, RDP and basic recording may not need them.
- Support model: Community support runs through GitHub and the forum, so the team should be comfortable diagnosing issues from logs and public discussions.
- Single point of failure: Standalone means one node, so an outage stops privileged access until the server is restored.
- Upgrade ownership: The team plans and tests each release, such as the v5.0.0 and v5.1.0 releases on the GitHub releases page.
This answer changes if the team needs database access on Oracle or SQL Server, if auditors ask for approvals before sessions open, or if the asset count approaches the Community limit. Confirm the current asset and feature limits on the pricing page before deciding.
A regulated organization that must show approvals, credential rotation and vendor-backed support usually fits the Enterprise edition, most often the Standard or Pro tier depending on asset count. The compliance case rests on controls the Community edition does not list: password rotation, ticket and just-in-time approval workflows, custom roles and SSO. The cost is a quote-based subscription that recurs, plus the internal effort to design approval paths that match the organization's change process.
- Approval workflows: Ticket and just-in-time approvals are listed as Enterprise features, which lets access requests be tied to a change record before a session starts.
- Password rotation: Rotation of managed privileged credentials is an Enterprise feature, which reduces standing credentials on target systems.
- Support obligations: Enterprise adds email and ticket support with an SLA and an account manager, which matters when an examiner or internal audit asks for a documented support path.
- Identity integration: SSO and LDAP HA are Enterprise features, so the team should confirm they connect to its existing directory.
- Access control model: Custom roles and multi-tenancy help separate duties between administrators and application owners.
This answer changes if the organization's controls are already met by an external ticketing and secrets process, or if it only needs session logging for a small number of hosts. Ask JumpServer for the exact feature list per tier, and ask DeployOpen to scope how the controls map to the evidence your assessor will request.
A large multi-site operation that needs continuous access during a node failure usually fits the Ultimate tier, which is the only tier that lists a full HA cluster. Pro offers active-standby HA up to 5,000 assets, while Ultimate removes the asset cap and provides a full cluster. The cost is a quote-based license plus the infrastructure and operating effort for several nodes, shared databases and regional placement.
- Availability model: Pro provides active-standby HA, while Ultimate provides a full HA cluster, so the choice depends on whether a standby node is enough.
- Scale: Ultimate lists unlimited assets, which suits operations whose asset count is expected to grow beyond 5,000.
- Site topology: Multi-site designs must account for network latency between sites, placement of the database and session proxies, and how users reach the nearest node.
- Directory and SSO at scale: LDAP HA and cloud asset sync are Enterprise features, which matter when identities and assets are spread across several environments.
- Operating ownership: Someone must own cluster upgrades, failover tests and capacity planning, and that work recurs with each release.
This answer changes if the operation can accept a short outage on a single node with fast restore, in which case Pro or a well-tested standby may be enough. Ask for the HA architecture in writing and confirm recovery objectives with JumpServer before committing.
What drives the cost of each edition
This table breaks down what you pay for in JumpServer Community and Enterprise, who gets paid for each part, and what changes the total. Read it as a checklist: the software price is only one line, and the server, staff time and tier choice usually decide the real cost.
| Cost component | Who is paid | One-time or recurring, and what drives it |
|---|---|---|
| Community software | Nobody for the licence (GPL-3.0, free self-hosted up to 5,000 assets, standalone) | No licence fee. Cost depends on the server and staff time around it. |
| Server hosting | Your cloud provider or data center | Recurring. The quickstart calls for a clean 64-bit Linux server with at least 4 CPU cores and 8 GB RAM, and asset count, session volume and recording retention push sizing up. |
| Installation and operation | Your staff, or DeployOpen under a written, fixed scope | One-time setup, then recurring upkeep such as upgrades, backups and access reviews. Drivers are topology, integrations and how many people administer it. |
| Enterprise subscription by tier | JumpServer (FIT2CLOUD), by quote only | Recurring. Tiers are Basic (50 assets), Standard (500, active-standby HA), Pro (5,000, active-standby HA) and Ultimate (unlimited, full HA cluster). Asset count and topology set the tier. |
| Enterprise support | JumpServer, included with the subscription | Recurring. Community relies on GitHub and the forum, while Enterprise adds email and ticket support with an SLA and an account manager. Confirm the exact level per tier. |
| Enterprise-only modules | Included in the quoted subscription | Recurring. Oracle and SQL Server access, password rotation, approval workflows, SSO, LDAP HA and cloud asset sync. Ask which modules are in your tier and which need add-ons. |
Moving from Community to Enterprise, and back
This sequence shows how a team moves a JumpServer deployment from the free Community edition to a paid Enterprise tier, and what to re-check when moving in the other direction. The goal is a cutover that keeps existing assets, sessions and access policies intact.
Confirm asset count against the target tier
Start by counting the assets in the current Community instance and comparing that number with the limits on JumpServer's pricing page: Enterprise Basic covers 50 assets, Standard 500, Pro 5,000 and Ultimate is unlimited. Your platform owner or IT lead does this, usually with an export from the asset inventory, and the list should include growth expected over the contract term. The step is done when you have a signed-off asset count and a chosen tier, with the quote requested against that number.
Plan the topology change
The Community edition runs standalone, while Standard adds active-standby HA, Pro adds active-standby HA at a larger asset count, and Ultimate adds a full HA cluster. Decide which topology you need, then document the target hosts, load balancing, database and storage placement, and the network paths for the proxies. Ask the vendor to confirm which HA model applies to each tier before you design it. The step closes with an approved architecture diagram and a rollback plan.
Validate the Enterprise components and their prerequisites
Enterprise adds protocol components such as Oracle and SQL Server access, password rotation, approval workflows, custom roles, multi-tenancy, SSO, RADIUS and LDAP HA. Map each feature to a real use case, then confirm with JumpServer which private components (for example, the Razor RDP proxy or Magnus database proxy) your licence activates and how they are installed on your hosts. Your platform engineers and the vendor own this check. You know it is complete when every required feature has a named owner and a tested prerequisite.
Inventory existing data, identities and integrations
Before any change, record what must survive the move: asset records, user accounts, access permissions, recorded sessions, audit logs, custom roles and integrations with identity providers or directories. Confirm the backup and restore procedure for the current database and file storage, and check which items your chosen Enterprise version will import, convert or require you to recreate. The security or IT operations lead signs the inventory. The step is complete when each data class has a documented migration or retention decision.
Rehearse the upgrade in a staging copy
Build a staging environment that mirrors production topology as closely as your budget and infrastructure allow, restore a recent backup into it, and run the Enterprise install and migration there. Test login through each protocol you use, a sample of privileged sessions, password rotation against a test account, and any approval workflow you rely on. Record every error and the fix. The step is done when a full test pass completes with no open high-severity issues and the timings have been noted for the production window.
Cut over to production with a verified rollback
Schedule the production change, freeze administrative changes during the window, take a fresh backup and run the migration steps that passed in staging. Repeat the core checks: administrator login, one session per protocol, asset reachability, audit log continuity and SSO sign-in. Keep the Community instance available as a rollback target until the checks pass and the owner signs off. The step closes when the production checks are recorded and the change ticket is closed with the final version and topology noted.
Plan and test the return to Community
Moving back to Community changes the feature set and asset ceiling: Community is standalone and limited to 5,000 assets, and Enterprise-only features stop working. Before downgrading, identify which features you use that Community does not provide, export the configuration and audit data, and decide how password rotation, approval records and Oracle or SQL Server access will be handled. Re-test authentication, asset access, session recording and backups on the Community instance, since those are the paths you must re-validate after a downgrade. The step closes when a documented reverse test passes in staging.
Questions buyers ask before choosing a JumpServer edition
Is JumpServer Community truly free to run in production?
Yes, the Community edition is free to self-host, according to JumpServer's pricing page, which lists it up to 5,000 assets in a standalone topology. It is licensed under GPL-3.0, so you can run it without a license fee. The costs that remain are your own infrastructure, the staff who operate it, and any outside help you buy. Confirm with JumpServer whether any Community feature you need sits in the Enterprise tier, because the Enterprise features list includes Oracle and SQL Server access and password rotation.
How much does a JumpServer Enterprise quote depend on asset count?
Asset count is the main tier boundary. JumpServer's pricing page lists Enterprise Basic at 50 assets, Standard at 500 with active-standby HA, Pro at 5,000 with active-standby HA, and Ultimate at unlimited assets with a full HA cluster. Prices are by quote only, so the figure depends on the tier, the number of assets you will manage now and in the next budget cycle, and whether you need HA. Ask the vendor to state the asset count, HA topology, support level and term in writing so the quote can be compared line by line.
How long does a standalone JumpServer install take to stand up?
The duration depends on your own environment rather than on a fixed figure. JumpServer's quickstart asks for a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM and installs with a quick_start.sh script from the GitHub releases. The main drivers are the readiness of that host, network and DNS, the number of assets and protocols to onboard, integration with your identity provider, and how many session recording and access policies you need to define. Ask your implementer for a written plan with milestones before the work starts.
What does our team have to own after JumpServer goes live?
Your team owns the platform after go-live. That includes applying upgrades, such as the v5.0.0 and v5.1.0 releases, monitoring the host, managing backups, rotating the credentials you store, reviewing session recordings, and onboarding or removing assets and users. You also own the identity integration and the access policies. Because Community support runs through GitHub and the forum, plan internal on-call coverage and a documented upgrade procedure. Confirm which of these tasks a vendor will take over under a retainer.
Can an internal team run JumpServer Community without outside help?
Yes, if the team has Linux administration skills, experience with reverse proxies, certificate management, and privileged access policy. The installer and the container images on Docker Hub make a first deployment practical for a single engineer. The harder part is the ongoing discipline: patching, testing upgrades, reviewing audit logs, and keeping the asset inventory accurate. Community support is community-based, so the team must be able to diagnose faults itself. Ask whether the staff who would run the platform have done a production upgrade before.
When does an outside implementation partner add value to a JumpServer project?
A partner adds value when the work exceeds what your team can staff reliably. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, usually under a fixed scope agreed in writing before work starts. Typical triggers include a need for SSO and HA design, a compliance evidence package, or a migration from another bastion. Ongoing support, upgrades and testing are available as retainers. A quote follows from the written scope, and DeployOpen does not publish prices.
Which Enterprise features should we verify before buying?
Verify the features that drive your architecture rather than assuming them. JumpServer's pricing comparison lists Oracle and SQL Server access, password rotation, ticket and just-in-time approval workflows, custom roles, multi-tenancy, SSO, RADIUS, LDAP HA and cloud asset sync as Enterprise features. Check each against your protocols, identity provider, and approval process, and confirm the current behavior with JumpServer in writing. Also confirm whether the Enterprise components, such as the Oracle and SQL Server connectors, are delivered as private packages that your deployment method must support.
A decision checklist before you request a quote
Start with scope, because it decides which JumpServer tier you are quoting. Before you ask for a price, list every protocol and database your bastion must broker. The Enterprise pricing comparison lists Oracle and SQL Server access as Enterprise features, and the Enterprise components include Razor for RDP, Magnus for database protocols and Nec for VNC, so a Community deployment that only needs SSH, RDP and Kubernetes access may not need any of them. Write down each Oracle and SQL Server instance by name, and confirm on the JumpServer pricing page which tier and component covers it. Then count assets and sites. Community is listed as free up to 5,000 assets in a standalone topology, while the paid tiers carry asset caps of 50, 500, 5,000 and unlimited, so a multi-site estate may push you into a different topology before asset count alone does.
Next, write down the approval and rotation rules your auditors will test. JumpServer's pricing comparison lists password rotation and ticket or just-in-time approval workflows as Enterprise features, so these are the controls most likely to decide the edition. Ask your assessor which evidence they expect for privileged access approvals and for credential rotation, then confirm with JumpServer that the feature set you need is included in the tier you quote. Do the same for SSO and LDAP high availability if your identity provider is central to access. HA is the second gate: the pricing page ties active-standby HA to Standard and Pro and a full HA cluster to Ultimate, so state your availability target in writing and ask which topology it requires.
Last, match support to your on-call model. Community support runs through GitHub and the forum, while Enterprise adds email and ticket support with an SLA and an account manager. If an outage must reach a named engineer within a fixed window, the free tier does not meet that need, and you should ask for the SLA terms in the quote rather than assume them. Put every item into the written scope you send to vendors and to DeployOpen, so the quote reflects the features, assets, sites, HA design and support level you actually run.
How DeployOpen scopes and delivers JumpServer
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For JumpServer, we start by settling which edition and topology the work actually needs, then deliver against a written, fixed scope.
How we scope
- Confirm the asset count and whether a standalone topology or an HA design fits the environment.
- Map which protocols, databases and Oracle or SQL Server targets must be reached.
- Write down deliverables, timelines and any Enterprise features in the agreed scope before work starts.
How we build
- Install JumpServer in your cloud account, data center or air-gapped network on the hardware you specify.
- Integrate your identity provider, LDAP or RADIUS source and asset inventory with the chosen edition.
- Test session recording, access policies and failover behavior against the scope before sign-off.
How we hand over
- Document the architecture, configuration, edition limits and upgrade steps in your own environment.
- Provide backup and restore procedures and the evidence your compliance assessors may request.
- Train your administrators on daily operations so your team can run JumpServer without us.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Plan upgrades between JumpServer release lines, with testing in a staging environment first.
- Ask us to confirm which support channels, including vendor SLA terms, apply to your chosen edition.
