Warpgate: a smart proxy that records the SSH session from the middle
Fully transparent SSH, HTTPS, Kubernetes, database and RDP/VNC bastion/PAM that doesn't need additional client-side software
At a glance
- What is it?
- One Rust binary that accepts SSH, HTTPS, Kubernetes, MySQL, PostgreSQL, RDP and VNC, authenticates the user itself, then splices the two connections together and records what happens.
- Who is it for?
- Warpgate makes most sense when the audit requirement is the hard part rather than the network access. A jump host can give someone a shell on a machine, but recording what they did inside that shell means installing an agent on the target, which is exactly what the host owner will refuse.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 7, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The word in the name that is doing the work
A jump host gives someone a shell on a machine in your network, and from there they can reach whatever that machine can reach. That is the problem Warpgate is built around, and it names itself explicitly: not a jump host. The README's bullet says it is not a jump host, it forwards the connection straight to the target in a way that is fully transparent to the client.
Concretely, that means you give Warpgate the user's ordinary SSH credentials with the target encoded in them, it authenticates the user against its own local user list, opens a connection to the target itself, and joins the two sockets. The client sees a normal SSH connection and the target sees a normal SSH connection. Neither end is modified.
The reason this matters for recording is straightforward. To record an SSH session by putting an agent on the target, you need root on the target, which is precisely the machine whose owner may not grant it. Warpgate is in the path, so it sees the cleartext traffic itself. The README's comparison table makes the argument in one row: command-level audit and full session recording for Warpgate and Teleport, versus connection-level audit on the jump host with no secure audit on the target if root access is given.
The project is Apache-2.0, written in what the README calls 100% safe Rust, with 7944 stars, 381 forks, 229 open issues, and releases on 2026-09-15, 2026-09-16 and 2026-09-18 with the repository last pushed on 2026-09-21.
Seven protocols, one credential format
The protocol list is the feature. Warpgate accepts SSH, HTTPS, Kubernetes, MySQL, PostgreSQL, RDP and VNC, and the repository tree has a dedicated crate for each: `warpgate-protocol-ssh`, `warpgate-protocol-rdp`, `warpgate-protocol-vnc`, `warpgate-protocol-kubernetes`, `warpgate-protocol-mysql`, `warpgate-protocol-postgres`, and `warpgate-protocol-http`.
The credential convention is what lets one service handle all of them. The README says it receives connections with specifically formatted credentials, authenticates the user locally, connects to the target itself, and then connects both parties together while optionally recording the session. For SSH that means the user and host travel in the username. For the others the same trick has to be spelled differently, which is why the docs rather than the README are the reference.
HTTPS is the odd one out and the most interesting. There, Warpgate presents a selection of available targets and proxies all traffic in a session to the one you pick, and you can switch between targets at any time without reconnecting. That turns the browser into the client for anything behind the bastion, which is also how browser-based SSH, RDP and VNC access is built in while native clients keep working unchanged.
You manage targets and users and assign them to each other in the admin UI, and session history goes into an SQLite database, by default at `/var/lib/warpgate`. The admin interface also gives you a live session list, session recordings, and logs.
The comparison table is the README's real argument
Rather than a feature list, the README puts a four-column table against SSH jump host, VPN and Teleport, and the rows are the reasons to choose one over another.
Precise 1:1 assignment between users and services: Warpgate and Teleport do this, while a jump host or VPN usually grants full access to the network behind it. No custom client needed: Warpgate and VPN, whereas a jump host needs config and Teleport requires a custom client. TwoFA out of the box for Warpgate and Teleport, possible on a jump host only with additional PAM plugins. Command-level audit and full session recording for Warpgate and Teleport, with the jump host and VPN rows both noting there is no secure audit on the target if root access is given. Built-in brute-force protection for Warpgate and Teleport, requiring fail2ban setup on a jump host.
The Teleport column is the honest one to read closely. Two of its cells say Paid, in the SSO row and in the self-hosted row. So the honest summary is that Warpgate and Teleport are close on the technical features, and the differentiators are the client requirement and the commercial terms, not the protocol coverage.
The non-interactive connections row is where Warpgate's design pays off for infrastructure tooling. A VPN gives you non-interactive connections, and a jump host gives them only if the client supports jump hosts natively, whereas Teleport needs an SSH client wrapper or a tunnel. Since `ssh`, `kubectl`, `psql` and `mysql` all understand the Warpgate credential format natively, automation does not need a wrapper.
A Cargo workspace of twenty-five crates
The repository is a Cargo workspace, and `Cargo.toml` lists twenty-five members. Beyond the protocol crates there are `warpgate-core`, `warpgate-common`, `warpgate-common-http`, `warpgate-tls`, `warpgate-ca`, `warpgate-sso`, `warpgate-ldap`, `warpgate-aws`, and the data layer split into `warpgate-db-entities`, `warpgate-db-migrations` and `warpgate-database-protocols`.
The frontend is separated out as `warpgate-web`, `warpgate-web-ssh`, `warpgate-web-desktop` and `warpgate-web-clients-common`, with `warpgate-desktop-ui` and `warpgate-desktop-auth` alongside. That the browser clients live in their own crates is the clearest evidence that browser-based terminal and remote desktop access is a first-class part of the product rather than a wrapper.
There is a `vendor/` directory with seven vendored third-party forks, and the reason is documented in the workspace manifest in unusual detail. The comment explains that IronRDP's NLA/CredSSP stack pins RustCrypto crates to release candidates that russh resolves via caret requirements, which Cargo cannot satisfy at once, so picky and sspi are forked to drop those pins and let both stacks share one crypto generation. Each vendored crate carries a `PATCHES.md` and a `warpgate.patch`.
That is worth knowing because it is a real constraint of running SSH and RDP stacks in one binary. Reading a project's vendored-fork rationale tells you more about its maintenance burden than the star count does.
Security posture, disclosure, and where the docs take over
Warpgate advertises the security features directly: native 2FA and SSO support with TOTP and OpenID Connect, built-in brute-force protection with IP blocking and user lockout, and a single binary with no dependencies. Security issues go through GitHub's vulnerability reporting system rather than a public issue or an email address, which is the responsible default for a network-facing service.
There is also an AI transparency disclosure in the README. It says that in late 2025 the project started accepting AI-assisted contributions, that contributors are required to disclose AI use, and that the standard applied is the same to all pull requests whether AI-assisted or not. That is unusual to see stated plainly in a README, and it is the kind of project policy a security auditor will want to know about rather than discover later.
Project status is described in one line: actively used in enterprise settings, with planned work tracked on a public roadmap board. Documentation lives at warpgate.null.page, and the README links out for getting started, getting started on Docker, login protection, SSO, and tickets for temporary access credentials.
For the developer side, `justfile` is the entry point. Running the server locally is `RUST_BACKTRACE=1 cargo run --all-features -- --config config.yaml`, there is a separate release variant, and `cargo test --all-features -p $p` loops over a curated project list rather than the whole workspace. Clippy runs through `cargo cranky --workspace --all-features`, snapshots are blessed with `cargo bless`, and the frontend has its own npm passthrough targets including `svelte-check` and a family of OpenAPI schema and client generation targets.
Editorial conclusion
Warpgate makes most sense when the audit requirement is the hard part rather than the network access. A jump host can give someone a shell on a machine, but recording what they did inside that shell means installing an agent on the target, which is exactly what the host owner will refuse. Warpgate sits in the middle of the connection, so it sees plaintext without cooperating with the target, and it does that for RDP and VNC and for MySQL and PostgreSQL as well as SSH, which is a range most bastions do not cover. The cost is that it is a proxy that terminates and re-establishes every session, it stores your session history in a local SQLite file, and its own docs, not its README, are where the configuration details live. Download a release binary or use a nightly build, run `warpgate setup`, then read the getting-started page before putting it in a DMZ.
Frequently asked questions
Do I need to install a client or modify my SSH config to use Warpgate?
No client software and no SSH wrapper. The README describes Warpgate as a bastion that doesn't require a client app or an SSH wrapper, and states that native clients continue to work alongside the browser-based access. What it does require is that you pass the target in a specifically formatted credential, which for SSH means encoding the user and host together.
How does Warpgate record an SSH session if it does not run on the target?
It sits in the middle of the connection. Warpgate authenticates the user against its own local list, connects to the target itself, then joins the two connections while optionally recording. Because the recording happens at the proxy rather than on the target, it does not need root on the machine being monitored, which is the limitation the README's comparison table attributes to jump hosts and VPNs.
How is Warpgate different from Teleport?
The README's comparison table gives both precise user-to-target assignment, command-level audit, full session recording, out-of-the-box 2FA and built-in brute-force protection. They diverge on the client: Teleport requires a custom client, while Warpgate works with unmodified native clients. The table also marks Teleport's SSO and self-hosting rows as Paid. Neither is a substitute for the other without checking those rows against your licence situation.
Where does Warpgate keep its session history?
In an SQLite database, by default in `/var/lib/warpgate`. The admin web interface is where you view the live session list, replay recordings and read logs, and it is also where you manage targets and users and assign them to each other.
Does Warpgate support single sign-on and two-factor authentication?
Yes, and the README lists both as native rather than add-on. Two-factor is TOTP, single sign-on is OpenID Connect, and both have dedicated documentation pages. There is also a login protection page for brute-force protection and a tickets feature for issuing temporary access credentials.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/warp-tech-warpgate)