Warpgate vs JumpServer: Zero Trust Access Without an Enterprise Budget

“Zero trust” is mostly a marketing budget. Strip the vendor language away and what a small operation actually needs for sensitive hosts — the PCI-scoped box, the client’s production servers, the machine with the payroll data — is a short list:

• Nobody connects directly to the target; access is brokered through one controlled point
• The broker enforces MFA, even for protocols that never heard of it (looking at you, RDP)
• Grants are per person, per target — not “whoever is on the VPN”
• Sessions are recorded, so “who did what, when” has an answer
• All of it produces evidence you can hand to an assessor without a two-day export project

You can buy this as a SaaS platform priced per seat for companies with a security team. Or you can self-host it. In the open-source space, two tools keep coming up for this job, and they could not be more different in philosophy: Warpgate and JumpServer. I’ve evaluated both for exactly this small-business, PCI-adjacent context. Here’s the comparison I wish had existed when I started.

One framing note before the profiles: no tool ships PCI-compliant. Compliance is the deployment plus the process plus the evidence. What differs between tools is which controls they can evidence — keep that lens on for everything below.

Warpgate: the single-binary broker

Warpgate is a smart bastion written in Rust: one binary, SQLite by default, Apache-2.0 licensed. It sits in front of your targets and speaks SSH, HTTPS, RDP, VNC, Kubernetes, MySQL and PostgreSQL. Native clients keep working — users point their normal SSH client or RDP client at Warpgate — and there’s a browser fallback for SSH, RDP and VNC.

The design has a property I like a lot: there is no shell on the bastion. Users don’t SSH into a jump host and hop onward; Warpgate authenticates them and opens a fresh connection to the target. A user connects as user:target:

ssh gabi:client-prod@gate.example.eu

with their Warpgate credentials — they never hold the target’s. Access is granted per user, per target, through roles. MFA is TOTP or OIDC SSO — and that OIDC hook is more important than it looks, because it’s the door to a proper self-hosted identity provider in front of the broker; hold that thought. The RDP handling is genuinely clever: since RDP has no MFA concept, Warpgate presents a holding screen inside the RDP session to collect the second factor before connecting upstream. Time-boxed access tickets cover the contractor and the emergency cases.

Auditing: full terminal recording with live view and replay for SSH, video replay for RDP/VNC, query logs for databases. One honesty point the project itself makes and you should repeat to your assessor: typed-command extraction from SSH sessions is a heuristic audit aid, not a security boundary — a user with an unrestricted shell can obscure input. The recording is the evidence; the command log is a convenience.

Operationally it’s about as light as this category gets: a systemd unit, a YAML file, SQLite. It clusters if you ever need it (shared database, recordings to S3-compatible object storage — the same locked-bucket pattern from the backup articles applies beautifully to session recordings, by the way).

Where Warpgate stops. It holds standing credentials — the key or password that opens each target lives in Warpgate’s database. There is no credential vaulting, no automated rotation, no approval workflow for just-in-time elevation. That has two consequences. First, the Warpgate host becomes crown jewels: encrypt its disk, firewall it tightly, back it up with the same discipline as a database, and treat it as fully in-scope for any assessment. Second, if an assessor asks “show me how privileged credentials are rotated,” Warpgate alone has no answer. Also worth stating plainly: it’s a small maintainer team. Apache-2.0 means you can never be locked out, but budget your own upgrade testing.

JumpServer: the PAM platform

JumpServer is a different animal: a full privileged-access-management suite, GPLv3, built by FIT2CLOUD. Where Warpgate is a lean proxy, JumpServer is a platform — credential vault, asset discovery, automated password rotation, command filtering, approval workflows, multi-tenant organizations, and session recording across SSH, RDP, Kubernetes and databases, all through a web console.

The architecture reflects that ambition. It is not one binary; it’s an assembly of named components — web UI, web terminal, separate connectors for character protocols, graphical protocols and database clients — sitting on top of a relational database, Redis and a reverse proxy. The project’s own quickstart asks for 4 cores and 8 GB of RAM as a floor. For a one-person shop maintaining this across several clients, that sentence is half the decision already.

Read the community/enterprise split carefully. Several connectors are enterprise-only, and they’re not obscure ones: at the time of my evaluation, native RDP client proxying and native database client proxying sat on the enterprise side, along with the VNC proxy connector. Browser-based access covers a lot in the community edition, but if your workflow depends on users keeping their native RDP or database clients, verify exactly which connector that requires before you commit — this split is where community-edition evaluations most often end in surprise.

Two more considerations that belong in an honest comparison. Operational weight: upgrades touch many components, and backup/restore means database plus recordings plus configuration — a restore drill you must actually rehearse, same rule as always. Governance: the upstream vendor is Chinese. Self-hosted means no data leaves your infrastructure, so the GDPR question is about your deployment, not their servers — but for EU clients doing supplier due diligence, it’s a conversation you should expect, and some clients will simply decline. Know that before you propose it. English documentation has improved but still trails the originals, and the project’s CVE history is worth a read as part of your evaluation — as it should be for any tool you place in front of your most sensitive hosts.

Where JumpServer wins. If the requirement is credential lifecycle as an evidenced control — vaulted secrets, automated rotation you can prove, command filtering, an approval step before elevation — JumpServer answers questions Warpgate cannot. That’s not a niche requirement; it’s exactly what a stricter assessment or a client’s security questionnaire eventually asks.

The actual decision

Strip it to one question: do you need credential lifecycle management as an evidenced control, or do you need brokered, recorded, MFA-protected access?

For a handful of Linux hosts and a couple of Windows boxes — the typical small-business estate — JumpServer is over-engineered: you’d run 8 GB of PAM platform to broker twenty targets. Warpgate covers brokering, MFA and recording with a fraction of the surface area, and surface area is itself a security property.

The middle path, and the one I keep coming back to: Warpgate for access brokering and session audit, paired with a separate secrets manager for credential lifecycle. Conceptually two tools instead of one, but each stays small, auditable and replaceable — no single platform to be locked into, and each piece can be swapped without rebuilding your access story. If you’ve read anything else on this blog, you know that’s not an accident; it’s the whole philosophy.

There’s a third piece that completes this picture: identity. Warpgate’s OIDC support means the broker doesn’t have to be your user database — it can trust a self-hosted identity provider, and my pick for that role is Zitadel: open source (AGPL-3.0), a single Go binary on top of PostgreSQL, speaking OIDC out of the box with MFA and passkeys. Put it in front and the stack becomes: Zitadel decides who you are, Warpgate decides what you may reach, the secrets manager owns what opens the target — three small, single-purpose, replaceable pieces adding up to what the enterprise platforms sell as one monolith. And because Zitadel’s state lives in PostgreSQL, it drops straight into the Barman-plus-immutable-copy backup pattern from earlier in this series; your identity provider is exactly the database you cannot afford to lose. Wiring this up properly — Zitadel deployment, the OIDC handshake with Warpgate, MFA policy, break-glass accounts — deserves its own article, and it’s coming.

Honorable mentions, and why they’re not the headline

Apache Guacamole — mature, boring in the best way, clientless RDP/SSH/VNC with MFA extensions and recording. But it’s a gateway, not a policy engine; identity-to-target policy is where it thins out. Teleport — technically excellent (short-lived certificates instead of standing keys, which directly fixes Warpgate’s weakest point), but the distributed Community Edition binaries carry usage restrictions tied to company size, so it becomes a per-client legal check rather than a simple default. HashiCorp Boundary — BUSL-licensed, so not open source by the definition this blog uses. All three are defensible picks in the right situation; none of them changes the Warpgate-vs-JumpServer decision logic above.

Whichever you pick: plan for the day it’s down

A broker is a chokepoint by design. Everything routes through it, which means its unavailability locks you out during exactly the kind of incident when you most need access. Keep a documented break-glass path — direct SSH permitted from one specific admin IP, key held offline — and test it on the same monthly cadence as your restore drills. An access control you can’t bypass in a controlled, audited emergency isn’t security; it’s a future outage.