Jauth

No passwords, no user database, no container stack — just a reverse proxy that gates your self-hosted apps behind keys you already have.

TL;DR

• What it is: A single-binary SSL/TLS reverse proxy that requires SSH key or Telegram login before passing traffic to a self-hosted backend — no passwords, no registration, no dependencies [README].
• Who it’s for: Solo self-hosters and small teams who want to put an auth wall in front of homelab apps (Paperless, Grist, Jellyfin) without running a full identity provider. Best fit if you already use SSH keys daily or Telegram actively [README].
• Cost: $0 (GPL-3.0). Runs on whatever VPS hosts your apps already. No SaaS tier, no usage-based pricing [README].
• Key strength: Genuinely minimal setup — one binary, one TOML file, Let’s Encrypt built in. If you’ve tried Authelia and found it sized for an enterprise rather than a one-person homelab, Jauth is the other extreme [README][4].
• Key weakness: 188 GitHub stars, single developer, no third-party security audit. Auth methods limited to SSH and Telegram — no OAuth2, no OIDC, no email/password, no Google login [README].

---

What is Jauth

Jauth is a reverse proxy that sits in front of your self-hosted applications and demands authentication before passing traffic to the backend. The GitHub description is plain: “Lightweight SSL/TLS reverse proxy with authorization (via Telegram and SSH) for self-hosted apps.” Built by a developer named jipok, it has no company behind it, no website, and no SaaS tier — it’s a focused tool that does one thing [README].

The model is simple. You point your domain at Jauth instead of directly at your app. Jauth terminates HTTPS (self-signed cert auto-generated, or Let’s Encrypt), presents a login page, and once authenticated, forwards requests to the configured backend with a Remote-User HTTP header [README]. The backend app never sees the auth layer.

What distinguishes Jauth from the rest of the self-hosted auth space is the authentication mechanism. There are no passwords. No user database. No registration. Instead:

SSH keys — Jauth runs an SSH server on port 2222. If your public key is in ~/.ssh/authorized_keys, you’re in. The format is identical to what your system SSH server uses; you can literally point it at the same file [README].

Telegram — Jauth uses Telegram’s login widget (not the bot API, which means no server-side polling and no bot token making API calls). You register a bot with BotFather, configure it per domain, and users authenticate via Telegram’s own signed callback. Jauth validates the HMAC signature server-side [README].

Optional SSO ties the two together: authenticate once, access all protected subdomains. The session token list is persisted to ./jauth-tokens.txt across restarts [README].

As of this review: 188 GitHub stars, GPL-3.0 license, no third-party reviews published. Everything below draws from the README and comparison with tools in the same category.

---

Why people choose it

The self-hosted auth space has a gap between “too simple” (Caddy’s basicauth, just passwords in a file) and “too complex” (Authelia with LDAP, Authentik with five containers). That gap is real and documented — a recent r/buildinpublic thread about a similar tool describes the problem as “sitting between the complexity of Keycloak and the lock-in of Auth0/Clerk” [1]. Jauth lives squarely in that gap.

The FusionAuth blog [3] frames the self-hosting decision well: when you bring auth in-house, you trade operational burden for data ownership and independence from vendor outages. Auth0’s 2021 outage rendered hundreds of sites unusable because their auth stack lived on someone else’s servers. For a homelab, that kind of dependency is obviously wrong — but the alternative shouldn’t require you to run your own Keycloak cluster [3].

Jauth’s answer is to not be an identity provider at all. It’s a proxy. Auth happens through systems you already maintain: your SSH key pair (which you presumably already have for server access) or your Telegram account (which you presumably already use for communication). There’s no new credential type, no password resets, no account lockouts based on failed attempts. If you lose your SSH key or Telegram access, that’s a familiar problem — it’s not a new class of failure introduced by Jauth [README].

The Remote-User header pattern is standard in reverse-proxy auth. Caddy, Traefik, and nginx all support consuming it. Any backend that reads HTTP headers can see who’s authenticated without being coupled to the auth mechanism [README][5]. For apps like Paperless-ngx that support this header natively, you get per-user experience for free.

For small teams using Telegram as an internal channel, the Telegram widget approach is practical: whitelist user IDs or handles, and those people log in to internal tools using an account they already have. No password to share over Slack, no new account to provision [README].

---

Features

Based on the README:

Core proxy:

• Single binary executable, zero external dependencies [README]
• HTTP → HTTPS redirect (ports 80 and 443) out of the box [README]
• SSL/TLS: auto-generated self-signed certificate (one-year validity) or Let’s Encrypt autocert [README]
• Configurable default backend; per-domain backend overrides [README]
• FilterSpam option to drop http: TLS handshake error log noise from crawlers [README]

Authentication:

• SSH server on port 2222; reads ~/.ssh/authorized_keys by default [README]
• Telegram login widget per domain; validates signature locally, no Telegram API calls [README]
• No passwords, no registration [README]
• Session tokens persisted across restarts in ./jauth-tokens.txt [README]
• Authenticated username forwarded to backend via Remote-User HTTP header [README]

Access control:

• Whitelist-based per-domain ACL; by default every user accesses every domain [README]
• UserSuffix per domain (for apps expecting [email protected] format) [README]
• Multiple independent domain configuration blocks in one TOML file [README]

SSO:

• Optional single sign-on across protected domains [README]

Utilities:

• github-key-import.sh for pulling SSH keys from GitHub profiles (requires fzf and jq) [README]

What is not here: no web UI for user management, no OAuth2/OIDC server, no SAML, no MFA beyond possession of your SSH key or Telegram account, no structured audit logs, no user provisioning API.

---

Pricing: SaaS vs self-hosted math

Jauth has no SaaS offering. GPL-3.0 software, self-hosted, cost is $0 [README]. The relevant comparison is against the services it replaces:

Cloudflare Access (Zero Trust):

• Free for up to 50 users
• $7/user/month beyond that
• Routes all traffic through Cloudflare’s network — not suitable for fully private infrastructure or users uncomfortable with that dependency [3]

Authelia / Authentik (self-hosted, free):

• Software: $0
• But operational cost is real: Authentik ships as a multi-container stack, Authelia requires LDAP or a local user file plus config YAML that easily spans 100+ lines. Neither is a single binary [4]

Auth0 / Clerk:

• Developer-focused identity providers for building auth into apps — not directly comparable (they’re SDKs, not proxies)
• Free tiers exist, but you’re putting your auth layer on someone else’s servers [3]

Jauth:

• Software: $0 (GPL-3.0)
• VPS: $0 incremental — it’s a static binary running alongside your existing stack
• Setup time: 20–30 minutes for a technical user

If you’re paying for Cloudflare Access, running a multi-container Authelia setup and finding it maintenance-heavy, or exposing self-hosted apps directly to the internet with no auth layer: Jauth has a coherent value case. This isn’t dollar savings against a SaaS; it’s operational simplicity savings against heavier self-hosted alternatives.

---

Deployment reality check

The README install path is three commands: wget the binary, chmod +x, run it. That is genuinely unusual simplicity [README].

What works with zero config:

• Self-signed certificate generated automatically on first run
• HTTP → HTTPS redirect active immediately
• SSH auth using your existing ~/.ssh/authorized_keys
• Traffic proxied to 127.0.0.1:8080 by default

What you actually need to configure for real use:

• A domain pointed at your server
• A TOML config file with domain blocks, Let’s Encrypt enabled, and backend targets
• For Telegram: a bot registered with BotFather, /setdomain configured, token in the config

What can go sideways:

The README itself contains this warning about Let’s Encrypt: “there may be no information about the process in the logs. You can just wait a little (30 seconds) and try to open the page in the browser.” That’s not great for debugging certificate provisioning failures [README].

One Telegram bot equals one domain. Protecting five subdomains means registering and managing five bots with BotFather [README]. This is annoying enough to be a real drawback at any scale beyond three or four domains.

The DropPrivileges option runs Jauth as a non-root process but explicitly notes it “will not be able to save state (tokens) between restarts” [README]. Choosing between process isolation and persistent sessions is a genuine trade-off, and the right answer for a security-conscious deployment is non-obvious.

The project has 188 stars and one visible developer. There is no published security audit, no CVE tracking, no disclosed incident response process. For a proxy handling all auth for your self-hosted infrastructure, that’s worth sitting with.

Realistic setup time:

• Someone who has deployed a reverse proxy before: 20–30 minutes
• First-time self-hoster following the README carefully: 1–2 hours
• No Linux experience: not recommended without an external guide

---

Pros and cons

Pros

• Single binary, zero dependencies. No container stack, no supporting services, nothing to upgrade alongside it [README]. Genuinely rare.
• No passwords. The credential-stuffing and brute-force attack surface is zero — there are no passwords to steal [README].
• SSH key auth is frictionless for technical users. If you already manage SSH keys for server access, enrollment in Jauth is instant [README].
• Telegram auth is practical for non-technical users with Telegram — no new account, no new password, Telegram’s login widget is mature and trusted [README].
• Let’s Encrypt built in. No separate Certbot process, no nginx plugin, no cron job [README].
• SSO across subdomains. One login covers all protected domains [README].
• Clean config. A realistic multi-domain setup fits in ~20 lines of TOML [README].
• Remote-User header. Standard integration point that backends supporting header-based auth consume directly [README][5].

Cons

• 188 stars, no security audit. One-developer project with no published audit. Acceptable risk for hobby homelabs, not for anything sensitive [README].
• One Telegram bot per domain. Multiple domains means multiple BotFather registrations [README]. Gets tedious quickly.
• No OAuth2/OIDC. Apps that want to do their own OAuth login flow (Nextcloud, Gitea, Grafana) won’t integrate cleanly — Jauth adds a proxy layer on top, it doesn’t replace the app’s own auth [README].
• No audit logs. Session tokens exist in a text file, but there’s no structured access log or event stream [README].
• GPL-3.0. Cannot be incorporated into a proprietary product or managed service without triggering copyleft obligations [README].
• DropPrivileges breaks session persistence. A real trade-off with no obviously correct default [README].
• Let’s Encrypt provisioning is opaque. “Wait 30 seconds” is the debugging guidance [README].
• No user management API. Configuration is entirely file-based; there’s no endpoint to add or remove users programmatically [README].

---

Who should use this / who shouldn’t

Use Jauth if:

• You’re running a personal homelab with a handful of apps and want an auth gate with zero user management overhead.
• You and anyone you’re giving access to already have SSH keys or Telegram accounts — enrollment is instant.
• You’ve looked at Authelia or Authentik and found them sized for an organization, not a person [4].
• You want HTTPS termination and auth handled by a single process, not a stack.

Skip it if:

• You’re protecting anything beyond personal or small-team tools. The trust profile at 188 stars and no audit isn’t appropriate for production business data.
• Your self-hosted apps require OAuth2/OIDC integration — Jauth doesn’t speak those protocols.
• You need audit trails, user provisioning, or access control beyond a per-domain whitelist.
• Your users don’t have Telegram and don’t have SSH key pairs set up — the two auth methods are the entire offering [README].
• GPL-3.0 is a licensing problem for your use case.
• You need more than a handful of domains — the one-bot-per-domain Telegram constraint becomes genuinely tedious at scale [README].

---

Alternatives worth considering

• Authelia — the standard homelab choice for serious deployments. Full 2FA (TOTP, WebAuthn), LDAP support, OIDC provider, file-based or LDAP user management. More moving parts, much more widely deployed and audited.
• Authentik — full identity provider: OAuth2, SAML, LDAP. Ships as a multi-container stack. Right for organizations that need proper SSO across apps that want OIDC. Overkill for a single person [4].
• TinyAuth — similar lightweight philosophy, different implementation [4]. Worth evaluating directly if Jauth’s SSH/Telegram model doesn’t fit.
• Caddy with basicauth — if you already use Caddy and just need simple password auth, one directive in your Caddyfile covers it with zero new services. You’re back to password management, but the operational overhead is minimal.
• Cloudflare Access — free up to 50 users, no infrastructure to run. The obvious choice if you don’t want to operate anything and trust Cloudflare [3]. Not an option if you need traffic to stay fully private.
• traefik-forward-auth — plugs into Traefik specifically, supports Google OAuth. Good if you’re already running Traefik.

For a solo self-hoster whose team already lives in Telegram or uses SSH keys: Jauth is simpler than all of the above. For anything with more than a handful of users, varied auth requirements, or real security stakes: Authelia.

---

Bottom line

Jauth solves exactly one problem — putting an auth gate in front of self-hosted apps — with the minimum viable moving parts. The no-password design removes an entire class of credential-based attacks. The SSH key path means technical users are enrolled without doing anything new. The Telegram widget is clever for small teams already on Telegram. And the single-binary deployment with built-in Let’s Encrypt is genuinely the simplest install in this category.

The honest limit is trust and scale. At 188 stars with one developer and no published audit, Jauth is not infrastructure you bet a business on. It’s infrastructure you deploy for your homelab after reading the source and accepting that you’re early on a small project. If that’s your situation, it’s hard to argue with the simplicity. If it’s not — if you need compliance, audit trails, more than two auth methods, or OAuth2/OIDC for app integration — Authelia or Authentik are the right calls.

---

Sources

1. North-Celebration-54, r/buildinpublic — “I built an open-source self-hosted auth server that doesn’t require a PhD to configure — v1.0”. https://www.reddit.com/r/buildinpublic/comments/1ryd8gl/i_built_an_opensource_selfhosted_auth_server_that/
2. Ahmed Narmer, Medium — “CTF Day(39). picoCTF Web Exploitation: JAuth” (Jul 21, 2025). https://medium.com/@ahmednarmer1/ctf-day-39-a7da094645ce
3. FusionAuth — “When to Self-Host Your Authentication System”. https://fusionauth.io/blog/when-to-self-host
4. ctrlaltnod.com — “TinyAuth: Lightweight Authentication Service Review” (Updated Mar 6, 2026). https://www.ctrlaltnod.com/opensource/tinyauth-lightweight-authentication-service-review/
5. Zuplo — “Top 7 API Authentication Methods Compared (2026 Guide)”. https://zuplo.com/learning-center/top-7-api-authentication-methods-compared/

Primary sources:

• GitHub repository and README: https://github.com/jipok/jauth (188 stars, GPL-3.0)