JumpServer: a self-hosted PAM bastion host for SSH, RDP, Kubernetes and databases

The problem JumpServer solves: shared credentials and unlogged sessions

The usual failure mode in a small infrastructure team is that an SSH key or a database password gets copied into a chat message, and from that point nobody can say who used it or when. JumpServer approaches this as a Privileged Access Management problem rather than a networking problem. The README describes it as an open-source PAM platform that gives DevOps and IT teams on-demand, secure access to SSH, RDP, Kubernetes, Database and RemoteApp endpoints through a web browser. The audience is therefore the team that already has servers, switches or databases, and wants a single place where access is granted, recorded and revoked, without asking every engineer to install a client. The browser is the delivery mechanism, not a side feature: it is what makes the platform usable from a locked-down workstation where you cannot install PuTTY or an RDP client. If your access model is already built around short-lived cloud IAM credentials and you never touch long-lived passwords, the value proposition is weaker.

How the connector architecture works: Lina, Luna, KoKo, Lion and Chen

JumpServer is not one process. The README lists its components as separate projects, and the split explains both the capability and the deployment cost. Lina is the web UI, Luna is the web terminal, KoKo is the character protocol connector, Lion is the graphical protocol connector, and Chen handles web database access. Tinker is the Remote Application Connector for Windows, and Panda, Razor, Magnus, Nec and Facelive are marked EE, meaning they belong to the enterprise line rather than the community repositories listed alongside them. So the data flow is: a user authenticates against the web UI, the platform decides which asset they may reach, and a protocol connector opens the session and streams it to the browser terminal. That design is why one platform can cover SSH and RDP and Kubernetes at once, and it is also why a broken connector produces a narrow symptom (one protocol fails, the UI still loads) rather than a total outage. The repository layout supports this reading: apps/, config_example.yml, entrypoint.sh and a Dockerfile that builds against jumpserver/core-base. The pyproject.toml pins django==5.2.15, paramiko==3.5.1, cryptography==46.0.7 and ansible==9.13.0, and requires-python is >=3.14, so the server side is a modern Python stack with a large dependency surface. Expect to track those pins.

Installing JumpServer with the quickstart script

The README gives a single installation path. It asks for a clean 64-bit Linux server with at least 4 cores and 8 GB of memory, then pipes a release script into bash. The script is fetched from the latest release asset named quick_start.sh, so it is versioned by whatever the latest release is at the time you run it.

curl -sSL https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh | bash

After that, the README says to open http://your-jumpserver-ip/ in a browser and log in with the username admin and the password ChangeMe. Those two values are the documented defaults, and the README does not describe a forced password change on first login, so treat the change as your own first action. The README also does not document a rollback or uninstall procedure for the quickstart, and it does not give an upgrade path from one release to the next; for those you have to go to the project documentation rather than the README. If you prefer containers, the repository ships a Dockerfile and a Dockerfile-base, and the README links a Docker image, but the quickstart above is the only install sequence the README itself spells out. There is no documented Windows or macOS server installation, which matches the fact that the quickstart targets a Linux host.

The connector split is also the main limitation

The component table is the honest description of the product boundary. Character protocols (SSH, telnet-style sessions) go through KoKo. Graphical protocols go through Lion. Database access through the web goes through Chen. Remote application access on Windows goes through Tinker. The connectors named Panda, Razor, Magnus, Nec and Facelive are listed as EE, so the community edition does not cover every protocol the marketing description implies. If your estate is mostly RDP to Windows servers plus a few databases, check which connector each path needs before you plan the rollout, because the answer determines whether you are deploying the community repositories or talking to the vendor. The second limitation is operational: a platform that brokers every session is a single point of failure for access. If the JumpServer host is down, nobody reaches anything through it, and the README does not describe a high-availability topology or a failover mode. The third is the dependency weight. The Dockerfile installs libldap2-dev, libx11-dev, cron, postgresql-client, openssh-client, sshpass, bubblewrap and docker-cli, and the Python dependency list is long and tightly pinned. That is a lot of surface to patch, and it is the price of supporting this many protocols in one place.

JumpServer compared with Teleport and Guacamole

The two comparisons people search for most are Teleport and Guacamole, and they differ from JumpServer in ways that matter more than feature checklists. Guacamole is a clientless remote desktop gateway: it is built around the browser-side rendering of RDP, VNC and SSH, and it is the natural choice if all you want is a gateway in front of graphical sessions. JumpServer wraps that same browser access in an access-control and audit layer with assets, users and permissions as first-class objects, which is a larger commitment and a larger install. Teleport comes at the problem from the identity side: it is designed around short-lived certificates issued by an identity provider, and its deployment model is closer to a set of Go binaries than to a Django application with a connector fleet. If your organisation already runs an identity provider and wants certificate-based access with no shared secrets at all, Teleport's model will feel more native. If your constraint is that operators need a browser and you want one place to define who may reach which host, JumpServer's asset model is the more direct fit. CyberArk, the third common comparison, is a commercial PAM suite; the difference there is procurement and support rather than architecture, and JumpServer's own homepage is the place to check what the enterprise edition adds.

Licence and the cost of staying current

JumpServer is licensed under GPL-3.0, and the README carries the copyright line for FIT2CLOUD covering 2014 to 2026. For internal use this is usually unremarkable: you can run it, modify it and deploy it inside your own organisation. The obligation that catches people is distribution. If you ship a product that includes JumpServer code, or a modified version of it, GPL-3.0 requires that the corresponding source be made available under the same licence. That is a product decision, not a legal footnote, and it is worth raising with whoever owns your licensing before you embed anything. This is not legal advice; read the licence text at the URL the README links. On maintenance, the repository is not archived and the most recent push recorded for it is 2026-08-24, with releases v3.10.23-lts and v4.10.19-lts dated 2026-08-24 and 2026-08-20. Two LTS lines are being maintained in parallel, which is good for stability but means you must decide early which line you are on and read the release notes for that line. The upgrade cost is not zero: the Python version floor in pyproject.toml is 3.14, the Django pin moves, and the connector components are separate repositories with their own release cadence, so a JumpServer upgrade can require matching connector versions.

A first session after install

Once the quickstart has finished and you have logged in as admin, the work is asset onboarding, and the README does not walk through it. What the repository does tell you is where the configuration lives: config_example.yml at the top level is the template for config.yml, which the Dockerfile explicitly empties during the image build before the application reads it. That ordering is worth understanding before you edit anything, because it means configuration is supplied at runtime rather than baked into the image. The entrypoint.sh script at the repository root is the process that starts the application inside the container. For a first real use, the sequence the documentation implies is: log in, change the admin password from ChangeMe, register the target host as an asset, grant your user permission to it, then open a session from the web terminal and confirm it lands on the target. Verify the audit trail for that session before you onboard the second host, because session recording is the reason most teams adopt a bastion at all, and a connector that opens sessions but does not record them is worse than no bastion.

Editorial conclusion

Adopt JumpServer if you need a self-hosted bastion that covers SSH, RDP, Kubernetes, databases and RemoteApp through one browser entry point, and you are willing to run the connector set yourself. Do not adopt it if you want a single static binary or a hosted service, or if GPL-3.0 obligations conflict with how you ship your own product. Before committing, verify the quickstart on a throwaway 4c8g Linux host, change the default admin password from ChangeMe, and check whether the connector you need for your protocol is in the community repository or only in the EE list.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes