unsubbed.co

Warpgate

For remote access & desktop, Warpgate is a self-hosted solution that provides smart SSH and HTTPS bastion that works with any SSH client.

Self-hosted secure access, honestly reviewed. No marketing fluff, just what you get when you put Warpgate between your servers and the internet.

TL;DR

  • What it is: A bastion host and PAM (Privileged Access Management) system — think Teleport, but Apache-2.0, free forever, and ships as a single binary you can run in 10 minutes [README][website].
  • Who it’s for: Solo founders, small engineering teams, and sysadmins who need audited, 2FA-protected access to internal SSH servers, databases, and Kubernetes clusters — without paying enterprise software prices or installing client apps on every machine [website].
  • Cost savings: Teleport Cloud’s commercial tiers run into the hundreds of dollars per month for teams. Warpgate is $0 for the software, plus whatever a VPS costs you. No per-user fees, no tier limitations, no sales calls [website][README].
  • Key strength: Fully transparent proxying — your users connect with standard SSH, HTTPS, MySQL, Postgres, or kubectl clients. No wrapper, no agent, no custom tooling. Sessions are recorded and replayable through a built-in web UI [website][README].
  • Key weakness: Smaller community than Teleport and fewer third-party integrations. At 6,666 GitHub stars, it’s a real project with real users, but it’s not a category leader yet. Independent reviews are scarce — most of what’s available is primary documentation [README][5].

What is Warpgate

Warpgate is a bastion host — the server you put between the internet and your internal infrastructure. When an engineer wants to SSH into a production server, connect a database client to a production Postgres instance, or run kubectl against a cluster, they go through Warpgate first. Warpgate authenticates them (password, SSH keys, TOTP, or SSO via OpenID Connect), checks what they’re allowed to reach, logs everything, records the session, and then passes the connection straight through to the target — transparently, without the client knowing there’s a middleman [website][README].

The project describes itself on the homepage as “The last bastion” and on GitHub as “Fully transparent SSH, HTTPS, Kubernetes, MySQL and Postgres bastion/PAM that doesn’t need additional client-side software” [README]. That last clause is load-bearing. Most PAM tools in this category either require you to install a custom SSH wrapper, configure jump host settings on every developer machine, or use a proprietary client. Warpgate uses the native protocol natively. Your SSH client connects to Warpgate using a specially-formatted username (c.wilde:[email protected]) and Warpgate routes it to the right target [website]. That’s it.

Written in 100% safe Rust. Ships as a single static binary with no dependencies. Runs natively, in Docker, or on Kubernetes via Helm. Financed through support contracts and custom feature development rather than VC money or SaaS pricing — the website explicitly calls out “the otherwise inevitable cycle of stagnation or VC enshittification” as what they’re trying to avoid [website].

Apache-2.0 licensed. 6,666 GitHub stars. Backed by FLOSS/fund [README].


Why People Choose It Over the Alternatives

The honest answer is that there are almost no independent third-party reviews of Warpgate the bastion host specifically — the tool occupies a niche where the people who need it tend to figure it out themselves rather than blog about it. What’s available is the comparison the project makes itself (detailed in the README and on the homepage) and its appearance as a named alternative in the self-hosted access management space [5].

The comparison that matters is Warpgate vs. Teleport, and the README makes it directly [README]:

No custom client. Teleport requires a custom client (tsh) for many operations. Non-interactive connections need a client wrapper or a tunnel. Warpgate uses standard tools — ssh, mysql, psql, kubectl — that your team already has [README].

SSO is free. Teleport charges for SSO (OpenID Connect). Warpgate includes SSO in the free open-source version with no plan gating [README].

Fully self-hosted. Teleport operates primarily as a SaaS product with a self-hosted option. Warpgate is self-hosted by design — there is no Warpgate Cloud to accidentally end up on [website].

No per-user pricing. This is the one that usually drives the decision for small teams. Teleport’s commercial tiers are priced per user at scale. Warpgate is a fixed cost: whatever your VPS costs you [website].

The comparison against a jump host is where Warpgate’s value becomes clearest. A traditional SSH jump host gives every authorized user broad network access behind it. Warpgate does precise 1:1 assignment — user A can reach server B and database C, and nothing else, enforced at the proxy layer with a full audit trail [README]. Jump hosts also can’t cleanly record sessions or provide command-level audit when the target grants root access. Warpgate records everything through the proxy before it reaches the target, so the recording is secure regardless of what permissions the user has on the destination [README].

Against VPNs: a VPN gives network access, not application access. You get a tunnel, not audit, not session recording, not per-target access control. Warpgate gives you all three for less operational complexity [README].

The AlternativeTo listing for Engity’s Bifröst (a competing SSH-focused bastion) lists Warpgate as one of the primary alternatives — suggesting that the community treats these tools as direct substitutes in the self-hosted access management space [5].


Features

Based on the README and website documentation:

Protocol support:

  • SSH — inbound and outbound, session recording, command-level audit [README]
  • HTTPS — use as a reverse proxy for internal web services with auth in front [README]
  • MySQL and PostgreSQL — set Warpgate as your DATABASE_URL directly [website]
  • Kubernetes — connect clusters through Warpgate without separate port forwarding [website][README]
  • gRPC support mentioned on the website [website]
  • Git proxy support [website]

Authentication:

  • Password, SSH public keys, TOTP (2FA), OpenID Connect SSO [README][website]
  • LDAP integration documented [docs]
  • Access tickets (one-time passwords for temporary access) [docs]
  • Role-based access control — user/target assignments [docs]

Session management:

  • Live session viewing through admin web UI [README]
  • Full session replay [README]
  • Command-level audit for SSH [README]
  • Log forwarding [docs]

Deployment options:

  • Single binary, no external dependencies [README]
  • Docker [docs]
  • Helm (Kubernetes) [docs]
  • systemd service [docs]
  • Reverse proxy support (run behind nginx or Caddy) [docs]
  • Can chain multiple Warpgate instances [docs]

Admin interface:

  • Built-in web UI for managing users, targets, roles, and reviewing sessions [README]
  • Interactive setup via warpgate setup CLI command [README]

Pricing: The Only Math That Matters

Warpgate has no paid plan and has stated explicitly that it never will. The business model is support contracts and sponsored feature development — which means the open-source tool doesn’t have features held back behind a paywall to force upgrades [website].

Warpgate (self-hosted):

  • Software: $0, Apache-2.0 [README]
  • VPS to run it: $5–15/month on Hetzner, Contabo, or DigitalOcean for a small instance
  • Optional: support contract (pricing not publicly listed — contact the project)

Teleport (for comparison):

  • Teleport Cloud has a free tier for small teams; paid plans scale by connected resources and users. Commercial tiers with SSO, session recording at scale, and compliance features cost substantially more — exact current pricing was not available at the time of this review, so specific numbers aren’t quoted here. The key structural difference is that SSO on Teleport is commercial-only; on Warpgate it’s free [README].

Real savings math for a typical use case:

A 5-person startup with 3 production servers, 2 databases, and a Kubernetes cluster needs audited access management. On a commercial PAM platform priced per user per resource, the annual cost can run $500–$2,000+/year depending on the tier and negotiated pricing. On Warpgate: $6–12/month VPS + $0 software = $72–$144/year, plus your initial setup time.

Over three years, that’s the difference between $3,000–$6,000+ spent on access management software and $216–$432 spent on compute. The savings compound as your team and infrastructure grow, because Warpgate has no per-user or per-resource fees.


Deployment Reality Check

The README’s setup path is warpgate setup — an interactive CLI wizard that generates a config file including port bindings. Docker and Helm options exist for containerized environments [README][docs].

What you actually need:

  • A Linux host (VPS or bare metal) in your DMZ or network edge
  • Ports accessible from the internet for the protocols you want to expose (typically 2222 for SSH, 8888 for HTTPS, etc.)
  • A domain name if you want TLS for the web UI and HTTPS targets
  • Docker or a Rust binary environment (the binary is fully static — no runtime dependencies) [README]

What the docs cover:

  • Native install and Docker paths [docs]
  • Running behind a reverse proxy [docs]
  • Systemd service setup [docs]
  • LDAP integration [docs]
  • Log forwarding [docs]
  • TLS SNI for multiple HTTPS targets [docs]
  • Chaining multiple Warpgate instances [docs]

What can go sideways:

The target-username format (user:target@warpgate-host) is a convention you’ll need to communicate to your team. It works with every standard SSH client without configuration, but it looks unusual and will confuse people the first time [website].

For database connections (MySQL/Postgres), you’re configuring a non-standard port on the Warpgate host as your database endpoint. This works but requires updating DATABASE_URL values across your applications — a one-time change, not ongoing friction.

Kubernetes support follows the same transparent proxy model. Whether your specific kubectl use cases (exec, port-forward, log streaming) all work seamlessly over the proxy is worth testing before rolling it out to your team.

The documentation is organized but sparse in places — you get a clear list of topics, but some advanced scenarios require reading the linked docs pages rather than finding a centralized “here’s everything” guide [docs].

Realistic time estimate: 30–60 minutes from a clean VPS to a working Warpgate instance with one SSH target configured. Adding databases and Kubernetes targets adds time per target.


Pros and Cons

Pros

  • Zero licensing cost, permanently. No paid plan, no commercial edition, no feature gating. Apache-2.0 means you can fork, embed, or deploy without restriction [website][README].
  • No custom client required. Standard ssh, mysql, psql, kubectl work unchanged. This is the real differentiator over most PAM tools [website][README].
  • SSO included free. OpenID Connect SSO is not gated behind a commercial tier — it’s in the base product [README].
  • Multi-protocol. SSH, HTTPS, MySQL, Postgres, Kubernetes from one tool. Most alternatives focus on SSH only [README].
  • Full session recording out of the box. Live viewing and replay in the admin UI, captured securely at the proxy before it reaches the target [README].
  • Single binary. No dependency hell. Deploy it, configure it, done [README].
  • Written in Rust. Memory safety matters for a security-critical piece of infrastructure [README].
  • Anti-VC model. Financed through support contracts specifically to avoid the SaaS pricing escalation cycle [website]. The project is funded by FLOSS/fund.
  • LDAP support for organizations with existing directory infrastructure [docs].

Cons

  • Limited independent reviews. Unlike Teleport or even smaller tools, there’s almost no third-party coverage of Warpgate the bastion host. You’re mostly relying on primary documentation and your own testing [5].
  • Smaller community than Teleport. 6,666 GitHub stars is real traction, but it’s not a category leader. Forum answers, Stack Overflow posts, and community-contributed playbooks are sparser [README].
  • Sparse documentation in places. The docs index is comprehensive in breadth but some topics are thin on practical examples [docs].
  • No cloud-managed option. If you want someone else to run the bastion infrastructure, there’s no Warpgate Cloud. You operate it yourself or pay for a support contract [website].
  • Username format convention. The user:target@host SSH username pattern works but requires team training and can confuse people expecting standard SSH behavior [website].
  • Maturity unclear for edge cases. Protocol support is listed as broad (MySQL, Postgres, Kubernetes, gRPC), but real-world coverage of edge cases (connection poolers, specific kubectl operations, prepared statements) isn’t documented in detail [README][docs].

Who Should Use This / Who Shouldn’t

Use Warpgate if:

  • You’re a small engineering team or solo founder who needs audited SSH/DB/K8s access without paying for enterprise PAM software.
  • You’ve looked at Teleport and the pricing conversation went poorly.
  • You need SSO (OpenID Connect) without it being behind a paywall.
  • You want session recording and command-level audit for compliance or internal policy, not because a vendor told you to buy it.
  • You’re comfortable deploying a binary to a VPS or know someone who can.
  • You want an Apache-2.0 licensed tool you can embed in your own product or private infrastructure without a licensing conversation.

Skip it (look at Teleport) if:

  • You need enterprise support SLAs, a named account manager, or certified compliance documentation.
  • Your team is large enough that you need commercial-grade RBAC, compliance reporting, and a vendor to call when things break.
  • You want a managed cloud option where you don’t run the bastion infrastructure yourself.

Skip it (use a VPN) if:

  • You don’t need per-target access control — you trust everyone on the VPN to reach everything behind it.
  • You want network-level access, not application-level proxying, and you don’t need session recording.

Skip it (consider Boundary or Smallstep) if:

  • You’re deep in a HashiCorp or cloud-native infrastructure stack and want tooling that integrates with Vault, Consul, or your existing identity platform.

Alternatives Worth Considering

  • Teleport — the category benchmark. More integrations, stronger enterprise compliance story, larger community, managed cloud option. SSO is paid, requires custom client for many operations, commercial tiers are expensive. Use if you need a vendor relationship. [README comparison table]
  • Engity’s Bifröst — Apache-2.0, Go-based, focused on SSH with OpenID Connect. No custom client needed either. Much smaller (78 GitHub stars). Listed as an alternative to Warpgate in the self-hosted access space [5].
  • OpenSSH with jump hosts — works, free, widely understood. No session recording, no per-target access control, no SSO without additional PAM plugins. Fine for very small teams with trusted users and no compliance requirements [README].
  • WireGuard + firewall rules — if your actual need is “only certain people can reach certain servers,” a well-configured VPN with firewall rules is simpler and has zero proxy risk. No session recording, no audit trail [README].
  • Boundary (HashiCorp) — open-core, deeper integration with Vault for dynamic credentials, more complex to deploy. Better for teams already on the HashiCorp stack.
  • Bastillion — web-based SSH bastion, simpler feature set, less active development than Warpgate.

Bottom Line

Warpgate earns its place in the shortlist for any small team that needs real access control — not “everyone shares the root SSH key” — without paying enterprise PAM pricing. The transparent proxying model is genuinely clever: your team uses the tools they already know, and Warpgate sits in the middle recording, enforcing, and auditing without making itself visible. The Apache-2.0 license, the no-paid-plan commitment, and the Rust implementation are all signals that the project is being built by someone who’s frustrated with how this category usually works. The trade-offs are real — limited community, sparse third-party coverage, an unusual SSH username convention — but none of them are blockers for a technically capable team. If you’re currently relying on a jump host, a VPN with overly broad access, or shared credentials for production server access, Warpgate is worth a serious evaluation. The cost of getting it wrong in the access management category (a breach, an insider incident, a failed audit) is orders of magnitude higher than the weekend it takes to deploy and configure this properly.

If deploying and maintaining it yourself is the blocker, that’s exactly what upready.dev handles for clients — one-time setup, documented, you own the infrastructure from day one.


Sources

  1. Warpgate Official Website“The last bastion.” — Secure access / PAM for internal SSH, HTTPS, MySQL, Postgres and Kubernetes servers. https://warpgate.null.page
  2. Warpgate GitHub READMEwarp-tech/warpgate — Fully transparent SSH, HTTPS, Kubernetes, MySQL and Postgres bastion/PAM that doesn’t need additional client-side software (6,666 stars, Apache-2.0). https://github.com/warp-tech/warpgate
  3. Warpgate DocumentationDocs Home: Getting started, targets, access control, authentication, ops, advanced topics. https://warpgate.null.page/docs/
  4. AlternativeTo — Engity’s BifröstLists Warpgate as a popular alternative in the self-hosted SSH bastion space. https://alternativeto.net/software/engity-s-bifrost/about/

Features

Authentication & Access

  • Single Sign-On (SSO)
  • Two-Factor Authentication

Integrations & APIs

  • Plugin / Extension System
  • REST API