Seven protocols share one access policy and audit trail
Warpgate accepts SSH, HTTPS, Kubernetes, MySQL, PostgreSQL, RDP, and VNC connections at the edge of a private network. Administrators map users to specific targets rather than granting access to the whole network behind a VPN. Native clients keep working, and browser clients cover SSH, RDP, and VNC. TOTP, OpenID Connect, brute-force protection, live sessions, and recordings sit in the same service. For a small infrastructure team, that is a useful amount of access control without a separate desktop agent.
It is a proxy, not a conventional jump shell. A user formats credentials so Warpgate can identify the requested target, then Warpgate opens the upstream connection and relays traffic. HTTPS users can choose among assigned targets and switch during a session. The administrator interface manages users, targets, assignments, session history, and recordings. This keeps the security boundary legible, but it also means one service holds credentials, identity state, network reach, and recorded activity.
A single binary still needs careful DMZ engineering
The distribution is a dependency-free Rust binary, and warpgate setup interactively writes configuration including port bindings. Docker instructions and release binaries provide faster routes than compiling source. Deployment still needs DNS, TLS certificates, firewall rules, durable database storage, recording storage, backups, monitoring, and a way to update without losing access. SQLite defaults under /var/lib/warpgate; PostgreSQL is available for deployments that need an external database.
The threat model deserves a written review. Warpgate reaches internal targets and can record what users type or see. Restrict its outbound routes to registered targets, keep the admin interface off public networks where possible, encrypt backup media, and set retention for recordings. Test the emergency path for disabling an account or bypassing a failed proxy. Session recordings are valuable evidence, but they can also contain commands, terminal output, or visible secrets that require stricter access than ordinary logs.
What happened when we ran it
Our sandbox cloned commit c4b19cb and installed 27 npm packages in 15 seconds. Those packages used 14 MB on disk. The source checkout held 791 files, about 104,867 lines, and occupied 5 MB. Npm audit found 0 known vulnerabilities: 0 critical, 0 high, 0 moderate, and 0 low. The repository had 14 CI workflow files and a tests directory, with no Dockerfile in the measured checkout.
There was no npm build script or target, so our harness skipped the build. There was also no npm test script or target, so it skipped tests. This does not contradict the repository's Rust CI or its documented source build. It means our Node 22 Debian procedure only installed the frontend package set and audited that dependency slice. We did not compile Cargo crates, launch Warpgate, connect a protocol, or inspect a recording.
The source instructions require Rust, Node.js, npm, and just. They install admin-interface dependencies, build the Svelte frontend, then compile the service with Cargo. Anyone building from source should run that complete chain and the project's Rust checks. Buyers using a release binary should verify its signature or provenance, pin the version, and exercise the exact artifact. Our 15-second npm result is not evidence that the security proxy itself builds or works.
Version 0.28.4 is a mandatory security baseline
Release v0.28.4 was published August 26, 2026 with a security fix for update_user_role. The notes say an administrator lacking AccessRolesAssign could re-enable an existing expired or revoked role assignment, restoring a user's former target access. The project recommends immediate updating for deployments with scoped administrators. The release also added SQLite CLI tooling to its Docker image and fixed several RDP and session-recording problems.
That advisory changes the adoption sequence. Install v0.28.4 or newer, create a scoped admin without role-assignment permission, and verify that expired and revoked access cannot be revived through either UI or API. Review audit entries for role changes. A bastion is judged by denied actions as much as successful logins, so negative authorization tests should accompany each release rather than waiting for a public advisory.
Live configuration and clustering need their own trials
Issue #2463 reports that changing one SSH target from password to public-key authentication on v0.28.0 persisted in the admin interface but did not affect new connections until a full restart. The reporter confirmed the old method in target-side logs and the new method immediately after restart. That is one upgrade history and version, not proof that all configuration reloads fail. It supports a practical check: after editing credentials, inspect the next upstream authentication and keep a controlled restart procedure.
High availability is less settled in the public material. Issue #2488 describes two v0.26.1 instances behind an AWS Network Load Balancer with shared PostgreSQL, keys, certificates, and recording storage. Some targets failed only when traffic reached the second node, leading the reporter to ask what additional node-local state needed synchronization. Teams with a hard active-active requirement should resolve that architecture and failure mode before choosing Warpgate, rather than assuming a shared database makes instances interchangeable.
Active maintenance supports a cautious shortlist
GitHub showed 7,726 stars, 212 open issues and pull requests, and a last push on August 26, 2026. Version 0.28.4 shipped the same day. The repository has 14 workflow files, public security reporting, a roadmap, and specific documentation for SSO, login protection, tickets, Docker, and source builds. Those are good signs for an access product, though our own harness did not reach the Rust build.
Warpgate is most attractive when a team wants several protocols, ordinary clients, narrow target assignments, and replayable sessions without buying a larger access platform. It is less convincing for an immediate multi-node rollout or an organization that cannot run protocol and authorization tests after upgrades. Start with a disposable network segment, restore its database and recordings from backup, validate every target type, and only then place the service on the real trust boundary.