JumpServer vs Apache Guacamole: when each one fits
Choose JumpServer when your team must control who reaches servers, databases and recorded sessions from one place, and you need an asset inventory and approval workflow to go with it. JumpServer describes itself as a privileged access management platform and bastion host covering SSH, RDP, Kubernetes, databases, websites, RemoteApp and VirtualApp access. Its Community edition is GPL-3.0 and free to self-host up to 5,000 assets in a standalone topology. Database access for Oracle and SQL Server, password rotation, ticket and just-in-time approvals, custom roles and LDAP high availability sit in the Enterprise tiers, so check those features against your requirements before you commit to Community. Guacamole is a different kind of tool: it is a clientless gateway that lets a user reach a desktop or shell from an HTML5 browser, with session recording available through an extension, and it does not manage an asset inventory or approval flow.
Choose Apache Guacamole when you need a lighter clientless gateway for RDP, VNC and SSH under Apache-2.0 and do not need a bastion's asset model. Guacamole's web application handles the interface and authentication, while the guacd daemon loads protocol plugins to reach the target. Its manual documents authentication backends on MariaDB or MySQL, PostgreSQL and SQL Server, plus extensions for Active Directory and LDAP, Duo and TOTP, CAS, OpenID Connect, SAML and smart card single sign-on. Guacamole is the better fit when your use case is a small set of remote desktops or shells and your identity provider already exists. Keep in mind that Guacamole's identity features are extensions you configure, so confirm each one against your provider, and that Guacamole has no built-in asset inventory to manage.
The decision turns on five questions: how many assets you must govern, how deep your audit trail must go, whether you need database access and approvals, what your licensing budget allows, and which identity provider you already run. Ask JumpServer for its current Enterprise quote if you need Oracle, SQL Server or approval workflows, since pricing is set by quote. For identity, JumpServer offers SSO and LDAP options in its Enterprise tiers, while Guacamole relies on its own extensions, so confirm how either connects to your directory or identity provider in a proof of concept. Document these answers in writing before you size the deployment.
Which JumpServer or Guacamole scenario matches your team
This table maps common team situations to the platform that fits better and explains why. Read each row against your asset count, audit obligations and approval requirements, because the answer shifts with scale and with the JumpServer edition you choose. The main takeaway is that Guacamole covers browser-based remote sessions well, while JumpServer fits teams that need asset inventory, approvals and database controls in one place.
| Scenario | Better fit | Reason and where the answer changes |
|---|---|---|
| Regulated audit of privileged sessions | JumpServer | JumpServer is a bastion host with session management across SSH, RDP and other protocols. Guacamole includes a session recording player extension, but you must confirm that its recording coverage, retention and review workflow meet your auditor's expectations. Session recording transcoding is listed as an Enterprise component, so confirm which recording features your edition includes. |
| Small team with a few Windows and Linux hosts | Apache Guacamole | Guacamole is a clientless gateway that runs in a browser and needs little beyond the web application and guacd. JumpServer Community covers up to 5,000 assets in a standalone topology, so a small estate fits either, but Guacamole asks for less platform to run. Choose JumpServer if you expect the host count to grow into asset management and approvals. |
| Database administrators needing controlled access | JumpServer | JumpServer provides database access through its Chen web database connector and, in Enterprise, Oracle and SQL Server access and a database protocol proxy. Guacamole's documented authentication backends are databases, not database administration targets. Confirm which database engines your edition supports before you commit. |
| Multi-team estate needing approvals | JumpServer | Ticket and just-in-time approval workflows, custom roles and multi-tenancy are listed as JumpServer Enterprise features. Guacamole has no approval workflow in its documented feature set. If approvals are required by policy, plan for an Enterprise tier and confirm current tier contents with JumpServer before you rely on them. |
| Teams that already run an identity provider | Apache Guacamole | Guacamole's extensions cover OpenID Connect, SAML, LDAP and Active Directory, so it can sit behind your existing identity provider. JumpServer lists SSO, RADIUS and LDAP HA as Enterprise features, so on Community you should confirm how your identity provider integrates before you deploy. |
| Browser-only access with no client software | Apache Guacamole | Guacamole is used from any HTML5 web browser, which suits contractors or occasional users on unmanaged machines. JumpServer also has a web interface, but its full feature set depends on the components and edition you deploy, so confirm the access path your users need. |
| Multi-site or high-availability requirement | Confirm with both vendors | JumpServer Standard and Pro tiers offer active-standby HA and Ultimate offers a full HA cluster. Guacamole's HA design depends on how you deploy the web application, guacd and database tier, which you must design and test yourself. Ask for the reference topology before you size either platform. |
| Custom protocol or unusual remote target | Confirm with both vendors | Guacamole adds protocols through plugins that translate to the Guacamole protocol. JumpServer covers SSH, RDP, Kubernetes, databases, websites and RemoteApp. Confirm that your specific target is supported natively or through a plugin before you choose. |
What each architecture means for day-to-day operations
JumpServer and Apache Guacamole both put a gateway between users and target systems, but they split the work differently. The cards below show which components run where, what each one means for upgrades and sizing, and which settings you must confirm before committing to either design.
JumpServer open-source components
JumpServer's community build is assembled from Lina (the web interface), Luna (the web terminal), KoKo (the protocol connector and proxy), Chen (the web database connector) and Kael (an AI component). Operationally, this means the web console, the terminal and the protocol proxy are all part of one platform you install, patch and back up together. Before you commit, confirm which of these components your protocols and database targets actually use in the Community edition, since some protocol paths are split across free and paid components.
JumpServer Enterprise protocol proxies
The Enterprise build adds private components: Panda for Linux application access, Razor for RDP, Magnus for database protocols, Nec for VNC and a session recording transcoding worker. These are not in the open-source source tree, so a Community-only design cannot assume them. If RDP through a proxy, Oracle or SQL Server access, or VNC is central to your plan, ask the vendor which components are included at the tier you quote and how they are upgraded alongside the core.
Guacamole web application and guacd
Guacamole splits into a Java web application that handles the browser interface and authentication, and the guacd daemon that loads protocol client plugins and connects to the target desktop. Operationally you run two tiers, and the web application speaks only the Guacamole protocol. Plan for the network path between the web tier and guacd, and check how many guacd instances your concurrent session load requires, because the manual does not give you a sizing figure to copy.
Guacamole database backends
Guacamole stores its users, connections and permissions in a relational database, documented for MariaDB or MySQL, PostgreSQL and SQL Server. This choice sets your backup, replication and upgrade routine, and it may already match a database standard your team runs. Confirm the schema upgrade steps for your chosen backend in the manual before each Guacamole release, and decide whether session recordings are stored in that database or on a file system you also need to back up.
Container deployment on both sides
JumpServer publishes container images on Docker Hub under the jumpserver organization and maintains an installer project for installation and management. Guacamole's manual covers both native and containerized Docker installation. Container packaging does not remove the operating work: you still own image pinning, volume persistence for recordings and databases, and the update path. Ask each vendor how container upgrades are tested against your protocol set before you adopt a rolling process.
Sizing baseline and what to confirm
JumpServer's quickstart asks for a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM, which is a floor for a trial, not a production sizing for your session count. The Guacamole manual does not give a comparable baseline in the supplied material, so confirm its hardware guidance in the manual and test with your own protocol mix, concurrent sessions and recording volume before comparing hosting costs.
JumpServer vs Apache Guacamole capability by capability
This table compares JumpServer and Apache Guacamole on the capabilities that usually decide a bastion purchase, from asset inventory to licensing. Where a capability is not confirmed for one platform, the cell says what to confirm with the vendor or project. The main takeaway: JumpServer bundles privileged operations into one product, while Guacamole is a lighter gateway that relies on its authentication extensions and your own processes for the rest.
| Capability | JumpServer | Apache Guacamole |
|---|---|---|
| Asset management | Central inventory for SSH, RDP, Kubernetes, databases and websites; Community covers up to 5,000 assets standalone. | No central asset inventory is documented; confirm how connections are organized with the Apache Guacamole project. |
| Session recording | Recording is part of the platform, but the session recording transcoding worker is an Enterprise component; confirm what Community records. | Includes a session recording player extension in the manual; confirm capture setup for your version. |
| Database access | Community includes the Chen web database connector; Oracle and SQL Server access and the Magnus database proxy are Enterprise features. | Databases are reached through RDP or SSH sessions to a host; confirm whether any direct database protocol is supported. |
| Approvals and password rotation | Ticket and just-in-time approval workflows and password rotation are listed as Enterprise features. | Not documented; confirm with the project or plan to build these controls in your own process. |
| Identity options | SSO, RADIUS and LDAP HA are Enterprise features; confirm which LDAP options Community supports. | Extensions cover Active Directory, LDAP, OpenID Connect, SAML, CAS and Duo or TOTP MFA, so a separate identity provider is optional. |
| Protocol coverage | SSH, RDP, Kubernetes, databases, websites, RemoteApp and VirtualApp; Razor (RDP) and Nec (VNC) proxies are Enterprise. | VNC, RDP and SSH through guacd plugins; a new protocol requires writing a plugin. |
| Containers and installation | Docker Hub images under the jumpserver organization plus an installer; the quickstart expects 4 CPU cores and 8 GB RAM on 64-bit Linux. | Native and Docker installation are documented; confirm container sizing and image support with the project. |
| Licensing | GPL-3.0 for Community; Enterprise tiers are sold by subscription and priced by quote. | Apache License 2.0; the guacamole-server repository is also Apache-2.0. |
Which one needs a separate identity provider and when
A small estate may not need a separate identity provider at all, because Guacamole ships extensions for Active Directory and LDAP, Duo and TOTP multi-factor authentication, CAS, OpenID Connect, SAML and smart card single sign-on. If your users are few, your directory is already Active Directory or LDAP, and your MFA requirement is covered by Duo or TOTP, the Guacamole extensions may be enough. Confirm which extension versions match your Guacamole release, since the extension set you enable is a per-deployment decision rather than something you inherit by default.
A larger estate usually wants a central broker. In that pattern, Keycloak sits in front of the gateway, brokers logins to external OpenID Connect or SAML identity providers, and federates users from LDAP or Active Directory, so Guacamole and JumpServer both trust one source of sign-in and one set of group mappings. The cost of this design is one more production service: Keycloak needs a relational database in production, and the decision belongs in your architecture review, not in the gateway project.
JumpServer lists SSO, RADIUS, LDAP HA, password rotation and approval workflows among its Enterprise features on its pricing page, so a Community deployment should not be assumed to have them. Before you choose, ask the vendor in writing which authentication methods Community supports, and test LDAP or AD login, MFA and group-to-role mapping in a staging environment. If SSO or LDAP high availability is a hard requirement, the Enterprise tier or an external broker becomes the deciding factor, and the quote should state both.
What the GPL-3.0 and Apache-2.0 licenses allow and what JumpServer sells
JumpServer is licensed under GPL-3.0, with copyright held by FIT2CLOUD for 2014 to 2026. The Community edition is the free, self-hosted build, and its pricing page lists it as free for up to 5,000 assets in a standalone topology. Running it in your own infrastructure does not require a subscription under the open-source license, but the feature set is the Community set, not the full product.
- Asset limit: Community is listed for up to 5,000 assets in a standalone topology, with no high availability tier.
- Core components: Lina, Luna, KoKo, Chen and Kael are open source, so the web interface, web terminal and protocol proxy are in the free build.
- Windows applications: The Tinker Windows application connector is free for Community Edition.
- Support: Community users rely on GitHub and the forum rather than a contracted response commitment.
- Enterprise-only features: Oracle and SQL Server access, password rotation, approval workflows, custom roles, multi-tenancy, SSO, RADIUS, LDAP HA and cloud asset sync are not part of Community.
Before you commit, confirm with JumpServer which features your use case needs, and check the current asset count against the 5,000 limit.
The Enterprise tiers are sold on JumpServer's pricing page as Basic (50 assets), Standard (500 assets, active-standby HA), Pro (5,000 assets, active-standby HA) and Ultimate (unlimited assets, full HA cluster). Prices are by quote, so the cost depends on the tier, the asset count and the support terms you agree. Enterprise also includes private components such as Panda, Razor, Magnus, Nec and a session recording transcoding worker, which are not open source.
- Basic: 50 assets, a fit for small estates that need Enterprise features without HA.
- Standard and Pro: Active-standby high availability, with Pro covering up to 5,000 assets.
- Ultimate: Unlimited assets and a full HA cluster, the tier for the largest estates.
- Added features: 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.
- Support: Email and ticket support with an SLA and an account manager, with the exact SLA terms set in the contract.
Ask for the tier, asset count, HA topology and SLA in writing, and confirm whether a separate commercial license applies to your use.
Apache Guacamole is released under the Apache License, Version 2.0, and version 1.6.0 was released on June 22, 2025. The Apache-2.0 license places no asset caps or edition gates on the gateway itself, and the guacamole-server repository, which holds guacd and the protocol plugins, is also Apache-2.0. Support comes from the Apache Software Foundation project and community channels rather than a vendor contract, so any paid support must come from a third party.
- License: Apache-2.0 for the web application and the guacamole-server repository, so the full gateway is available without an edition split.
- Asset limits: No product-enforced asset cap in the sources reviewed, so sizing is set by your hardware and deployment.
- Protocols: RDP, VNC and SSH through an HTML5 browser, with extensions for Duo, TOTP, OpenID Connect, SAML and other sign-in methods.
- Recording: A session recording player extension is documented in the manual.
- Support: Community channels and the project documentation; a commercial support contract is a separate question to confirm with a provider.
Confirm the license terms of any third-party extension or commercial support offer you add, since those are separate from the Apache-2.0 core.
What drives the running cost of each platform
The running cost of JumpServer and Apache Guacamole is driven less by the software licence than by the infrastructure you size around it, the people who operate it and any identity provider you must add. For JumpServer, the Community edition is free to self-host up to 5,000 assets in a standalone topology, according to its pricing page, so the recurring cost sits in the Linux host (the quickstart asks for at least 4 CPU cores and 8 GB of RAM as a starting point), in storage for session recordings, and in the engineer time to run upgrades and backups. Recording storage grows with the number of privileged sessions and how long you retain them, so ask the vendor or your own pilot to measure recording volume per session before you size disks. Enterprise tiers add a subscription that is priced by quote, and the tier you need follows from asset count and whether you require active-standby or full HA, which the pricing page ties to the Standard, Pro and Ultimate levels.
Apache Guacamole has no licence fee and no vendor subscription, so its recurring cost is almost entirely staff time and infrastructure. Its Java web application, the guacd daemon and the database backend (MariaDB or MySQL, PostgreSQL or SQL Server) each need patching and backing up, and the session recording player is an extension you must install, configure and maintain yourself. Support comes from the Apache community and your own staff or an implementation partner, which is effort-heavy if you need a fixed response commitment. Before you compare totals, confirm whether your identity provider is already in place. Guacamole can authenticate through Active Directory and LDAP, OpenID Connect or SAML extensions, but if you need a new directory, MFA service and SSO layer, that is a separate platform with its own licence model, such as Keycloak under Apache-2.0, and its own run cost.
When you request a quote, ask DeployOpen or any vendor to itemise one-time work (design, installation, integration with your identity provider, recording storage design, and migration of existing connections) separately from recurring work (subscription, upgrades, backup testing, patching, and retainer support). Ask which costs scale with asset count, concurrent sessions or retention period, and what the quote assumes about HA topology. For Guacamole, ask who carries the on-call and patch burden after handover. Scope in writing matters because a fixed-scope engagement sets deliverables and timelines before work starts, which makes the one-time cost predictable, while the recurring cost is whatever your team decides to keep in-house.
Moving between JumpServer and Guacamole: what transfers and in what order
This sequence takes a team from one gateway to the other without a gap in access, leaving a tested inventory, mapped roles, rebuilt connections and a documented retirement of the old system. It works in either direction, so the same steps apply whether you are moving to JumpServer or away from it.
Inventory assets, accounts and access paths
Export a complete list of the hosts, protocols, ports, database instances and web targets the current gateway reaches, along with the accounts used to reach them and who is allowed to use each one. Confirm which credentials are stored in the gateway and which are held by people or by another vault. The step is done when every target has an owner, a protocol and a named access path, and the list has been reviewed by the teams that run those systems. Ask each vendor's documentation or your own export tooling which fields can be extracted, because a full export of stored secrets is not something to assume.
Map roles, groups and approval rules
Translate existing access groups into the role model of the target platform. In JumpServer, roles and approval workflows are part of the platform's design, and some of these features sit in the Enterprise tiers, so confirm your required approval and custom role needs against the current pricing comparison before you design the mapping. In Guacamole, access is typically expressed through connection permissions and the identity source you choose, so approvals usually live in a process outside the gateway. The step is done when each existing group maps to a target role or a documented manual control, and the gaps are listed with an owner.
Connect the identity source and test sign-in
Decide which identity provider authenticates users on the target platform and confirm the integration path with the vendor before you build it. Guacamole relies on its documented extensions for Active Directory, LDAP, OpenID Connect, SAML and multi-factor methods, and it does not act as an identity provider itself. JumpServer's SSO, RADIUS and LDAP capabilities depend on edition, so confirm them in the pricing comparison. The step is done when a test group of users signs in with the expected factors and the group membership they receive matches the role map from the previous step.
Rebuild connection definitions and recording retention
Recreate each connection on the new platform using the inventory, and decide retention separately for session recordings and logs. Session recordings made on one platform are not expected to import into the other, so keep the old recordings in read-only storage under the retention period your policy requires and confirm the format and playback path with the vendor. Guacamole's session recording player is an extension, so verify that it is installed if you rely on it. The step is done when a sample of connections has been opened, a test session has been recorded and stored, and the retention plan has been signed off by the owner of your audit evidence.
Run both gateways in parallel
Keep the old gateway running while users move team by team, and direct new sessions to the new platform only after each group passes its checks. Monitor failed logins, blocked sessions and any target that does not connect, and keep a rollback path that routes a group back to the old gateway. The length of the cutover window is a decision for your change board, based on the number of targets and the risk of each one. The step is done when every group has run its normal work on the new platform for an agreed period and no open access defects remain.
Confirm vendor-specific items before retiring
Before the old gateway is shut down, check with each vendor on the items that do not transfer automatically, including stored credentials, audit log formats, custom roles, approval history and any licensed asset counts. For JumpServer, confirm asset limits and high-availability requirements against the edition you buy, since the pricing page ties tiers to asset counts and HA configurations. For Guacamole, confirm the database schema and any extension versions you rely on, using the project's manual and release notes. The step is done when written answers exist for each item and the open risks are accepted by the owner.
Retire the old gateway and archive evidence
Disable logins on the old gateway, revoke the service accounts it used to reach targets, and remove its network routes after the cutover is accepted. Archive configuration exports, the asset and role inventories, the recording store and the change records in a location your auditors can reach. Confirm with your compliance lead which evidence the retention rules require before deletion. The step is done when the old gateway no longer accepts connections, its credentials are rotated or revoked, and the archive has been checked for completeness by someone other than the person who built it.
Where implementation runs long on each platform
JumpServer projects usually run long in four places: asset import and cleanup, approval design, HA topology and identity integration. Asset import is where most of the early time goes. Hosts, accounts and their groupings often come from spreadsheets or stale inventories, so teams spend weeks deduplicating records before anyone can test a login. Approval design is slower still. Ticket and just-in-time workflows only help if the approvers, their fallback and the emergency path are agreed before go-live, and JumpServer's approval features are listed among the Enterprise capabilities, so confirm licensing before designing around them. Ask for the HA topology in writing early, since the choice between standalone and active-standby affects the asset tier you need. Identity integration, whether SSO, LDAP or RADIUS, should be tested against a copy of the real directory, not a test tenant.
Guacamole projects tend to run long in the configuration layer rather than the product itself. The web application delegates authentication to extensions for Active Directory and LDAP, Duo or TOTP, CAS, OpenID Connect, SAML, smart card or header-based login, and each one has its own settings, certificates and failure modes that must be tested together. Session recording review is often underestimated: the recording player extension makes sessions viewable, but someone must decide who reviews them, how often, and where they are retained. Protocol and certificate edge cases, such as RDP security settings, TLS on the web front end and SSH host keys, tend to surface only under real user load. Scaling guacd, the daemon that loads protocol plugins, requires sizing against expected concurrent sessions, which the team should measure in a pilot. DeployOpen scopes both kinds of work in a written, fixed-scope plan agreed before any work begins, so the risks above are assigned owners and deliverables from the start.
JumpServer vs Apache Guacamole: what buyers ask before hiring help
What drives the cost of running JumpServer or Guacamole in our environment?
The software licenses are not the main cost driver for either product. JumpServer's GPL-3.0 Community edition and Guacamole's Apache-2.0 license carry no license fee, so the spend comes from the people and infrastructure around them. Cost rises with the number of assets, the protocols you must cover, the number of approval workflows and recordings you need to keep, and the amount of integration work with your identity provider and ticketing system. JumpServer's Community edition covers up to 5,000 assets in a standalone topology, while its Enterprise tiers, priced by quote, add features such as Oracle and SQL Server access and approval workflows. Ask any implementation partner for a written quote that separates one-time setup, recurring support and upgrade work, and that states which edition or feature each line depends on.
How long does it take to deploy JumpServer or Guacamole?
The duration depends on scope, not on the product's install script alone. JumpServer's quickstart expects 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 its GitHub releases, so a basic lab install is a short exercise. A production rollout adds asset import, role design, recording storage, high availability, and testing of each protocol you need. Guacamole installs natively or in Docker, but its real effort sits in configuring authentication, connection definitions and recording. No supplied fact gives a timeline for either product. Ask for a fixed-scope plan with milestones and the assumptions behind each one, and confirm the required hardware sizing for your own asset count before agreeing dates.
What does our internal team need to provide during a deployment?
Either platform needs named owners on your side for decisions that the vendor cannot make for you. Expect to supply a target Linux host or container platform, network paths to the systems being accessed, a list of assets with their owners, and the access rules your security team wants enforced. You will also need someone who can approve the identity integration, the session recording retention policy and the change window for upgrades. Ask the implementation partner to write down which tasks are theirs, which are yours and which need a decision from your risk or compliance function before work starts.
Can one administrator run JumpServer or Guacamole alone?
One administrator can operate a small Community deployment, but the answer depends on the size of the estate and how many people need access. A single person can handle day-to-day user and connection changes in either product, yet upgrades, backups, recording storage and incident response all become single points of failure. JumpServer's Enterprise tiers add high availability options, which matter when no one is available out of hours. Guacamole has no comparable commercial tier, so resilience depends on how you build the surrounding infrastructure. Ask for a runbook and an on-call plan that does not rely on one named person before you rely on a solo operator.
Does JumpServer or Guacamole need a separate identity provider?
Both products can use external identity sources, but they differ in what they ship with. Guacamole's manual documents extensions for Active Directory and LDAP, Duo and TOTP multi-factor authentication, CAS, OpenID Connect, SAML and smart card single sign-on, so a Keycloak or Active Directory deployment is a common pairing when you choose it. JumpServer's pricing comparison lists SSO, RADIUS and LDAP high availability as Enterprise features, so confirm which of these your edition provides before you design the integration. In either case, the identity provider is a separate system that you must plan, run and back up. Ask your implementation partner to map each login path, including administrator and break-glass accounts, to the identity source you choose.
How should we size JumpServer or Guacamole for our asset count and session load?
Start with the number of assets, concurrent sessions, protocols and how long you must keep recordings. JumpServer's quickstart baseline is at least 4 CPU cores and 8 GB of RAM, and its Community edition supports up to 5,000 assets in a standalone topology. Above that, or where you need active-standby high availability, the pricing page points to Enterprise tiers, so confirm the topology with the vendor. Guacamole's architecture splits the Java web application from the guacd daemon, which loads protocol plugins, so concurrent sessions and the recording volume drive the sizing. No supplied fact gives a specific Guacamole hardware figure. Ask for a sizing note that uses your real session counts and recording retention, and test it with a pilot before you commit.
How hard is it to switch between JumpServer and Guacamole later?
Switching is most costly when you have built up asset inventories, access policies, recordings and audit history in one platform. JumpServer manages assets, roles, approval workflows and recordings as a full bastion, so its data model is wider than Guacamole's connection definitions, and moving the policy and audit logic takes more planning. Guacamole stores its connection and user data in a supported database such as MariaDB or MySQL, PostgreSQL or SQL Server, which makes exporting it simpler but still requires re-testing every connection. Because both licenses permit self-hosting, the exit cost is mainly labor and the risk of losing audit evidence during the move. Ask for an export and migration plan in the quote, and keep recordings in a format you can read after either platform is removed.
How DeployOpen helps you choose, implement or migrate
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including JumpServer and Apache Guacamole. We start by testing which access model fits your assets, protocols and identity setup before any build begins.
How we scope
- Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
- We confirm which protocols, asset types and session recording needs your team must cover.
- We map where your identity provider sits, whether it is an existing directory or a separate service.
How we build
- We install and configure the chosen platform in your cloud accounts, data centers or air-gapped networks.
- We integrate authentication with your identity provider and set up recording storage and access roles.
- We test access paths, session capture and failover behavior against the agreed scope before handover.
How we hand over
- We document the architecture, configuration, access policies and recovery steps for your own team.
- We deliver backup and upgrade procedures so your operators know how the platform is maintained.
- We prepare access controls and session evidence that your compliance assessors can review independently.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover version upgrades, configuration changes and periodic access review testing.
- Support scope and response expectations are written into the retainer, so you can confirm them before signing.

