Tinyauth

Open-source authentication middleware for self-hosted apps, honestly reviewed. No marketing fluff, just what you get when you bolt it in front of your services.

TL;DR

• What it is: A tiny OIDC authentication and authorization server designed to act as middleware in front of your self-hosted apps — think “one login screen for all your services” with almost no configuration required [README][2].
• Who it’s for: Home lab operators, indie hackers, and non-technical founders running a handful of Docker services who want SSO without the complexity of Authelia or the overhead of Keycloak [2].
• Cost savings: Commercial SSO solutions like Okta start at $2/user/month; Auth0’s paid tier at $23/month for 1,000 MAU. Tinyauth is free software that runs on a VPS you already have, consuming under 10 MB of RAM [2][README].
• Key strength: Genuinely stateless. No database, no Redis, no config files — just environment variables and a Docker container [2]. The XDA Developers reviewer who switched from Authelia called the setup “an absolute breeze” [2].
• Key weakness: GPL-3.0 licensed (not MIT or Apache) — limits commercial embedding without legal review. Actively in development with breaking config changes between major versions (v4→v5 required a full config migration) [docs][README]. Not the right tool if you need fine-grained enterprise user management.

---

What is Tinyauth

Tinyauth is an authentication middleware and OIDC provider for self-hosted applications. The pitch is disarmingly simple: put Tinyauth in front of any app running behind a reverse proxy, and users see a login screen before they can access it. One set of credentials protects everything. The project’s own GitHub README calls it “the tiniest authentication and authorization server you have ever seen,” and that claim isn’t marketing — it ships as a single statically linked binary with no external dependencies [README].

The project supports OAuth (GitHub, Google, and any OAuth2 provider), LDAP for enterprise directory integration, TOTP for two-factor authentication, and access controls for per-service or per-user rules. It works natively with the three reverse proxies that cover roughly 95% of home lab setups: Traefik, Nginx, and Caddy [README][website].

What actually makes Tinyauth different from the standard alternatives is the stateless design. Authelia, the go-to authentication server for home labs, requires a database backend (SQLite at minimum, MariaDB or PostgreSQL in production), Redis for session caching in HA setups, and a detailed YAML configuration file. Tinyauth skips all of that. User credentials live in environment variables, OAuth tokens are handled externally, and there is no persistent storage to set up, back up, or migrate [2]. For someone running five services on a Raspberry Pi or a $6 VPS, that matters.

The project is built by a solo developer (steveiliop56), has 7,138 GitHub stars as of this review, and an active Discord community. It just shipped v5, a major release that overhauled the entire configuration format — environment variables now follow TINYAUTH_<SECTION>_<KEY>=<VALUE> instead of the previous ad-hoc scheme. The project provides a configuration migrator tool to ease the transition, but the breaking change is real [docs].

---

Why People Choose It Over Authelia

The XDA Developers review [2] is the most detailed third-party write-up available, and it lands on four concrete reasons a home lab operator would switch from Authelia to Tinyauth:

Setup time. The reviewer describes Authelia as requiring “a detailed YAML configuration file to define users, control rules, storage backends, authentication models, etc.” Tinyauth’s default docs cover setup in under a page, and first-time Docker deployment takes “a few minutes” rather than an afternoon [2]. If you’ve ever stared at Authelia’s configuration.yml wondering why the session cookie isn’t working across subdomains, this comparison lands.

Resource footprint. Tinyauth uses under 10 MB of RAM in normal operation. Authelia matches that in minimal mode, but as soon as you add Redis for session caching or MariaDB for user storage the memory usage jumps to hundreds of megabytes [2]. On a Raspberry Pi 4 with 4 GB shared between eight services, that delta is meaningful.

No database. Authelia requires a storage backend — even with SQLite you have to configure it, back it up, and handle schema migrations during updates. Tinyauth has no storage layer at all. Credentials go in environment variables; sessions are handled via signed tokens; OAuth state is managed externally [2]. This is a deliberate design choice with an obvious trade-off: a home lab with two or three users is fine, but if you need per-user audit logs, password history, or account recovery flows, the stateless design becomes a limitation.

The right scope for the use case. The reviewer puts it plainly: “A home lab setup probably only requires you or a few other members of your family to authenticate. For such situations, Tinyauth makes a lot of sense” [2]. This is the honest calibration that’s missing from most reviews — Tinyauth isn’t trying to be Keycloak. It’s trying to be the smallest thing that does the job for a small number of trusted users.

---

Features

Based on the README, the official documentation, and the website:

Authentication methods:

• Username/password via environment variable–stored credentials [README]
• OAuth2 with GitHub, Google, and any compatible provider [docs]
• LDAP integration for centralized directory authentication [README][docs]
• TOTP (time-based one-time passwords) for two-factor authentication [docs]

Proxy integrations:

• Traefik middleware (native forward-auth support) [README]
• Nginx (via auth_request) [docs]
• Caddy (via caddy-security or forward_auth directive) [docs][community]
• Nginx Proxy Manager [docs]

Deployment:

• Single binary, statically linked, no runtime dependencies [README][website]
• Docker and Docker Compose [README]
• Runtipi app store support [docs]
• Kubernetes (community-contributed guide) [community]
• No database required — stateless by design [2][README]

Access controls:

• Per-service access rules: restrict specific services to specific users or groups [docs]
• Label-based configuration for Docker deployments [docs reference]

OIDC server mode:

• Acts as a full OpenID Connect provider, not just an auth middleware [website]
• Allows downstream apps to use Tinyauth as their OAuth2 identity provider [website]

What’s not there:

• No built-in user management web UI — users are managed via environment variables or external OAuth/LDAP [2]
• No self-service password reset (stateless design means no email flows) [README]
• No admin dashboard for managing sessions, reviewing login history, or auditing access — data not available in project docs

---

Pricing: SaaS vs Self-Hosted Math

Tinyauth is free software (GPL-3.0). There is no cloud tier, no paid plan, no per-user charge. The entire cost is infrastructure.

Tinyauth self-hosted:

• Software: $0
• Infrastructure: whatever you’re already paying for a VPS or home server
• RAM overhead: under 10 MB [2]
• Database: none required

Competing commercial SSO options:

• Okta Workforce Identity: $2/user/month — $20/month for a 10-person team, $200/month for 100 users
• Auth0: Free tier up to 7,500 MAU; paid from $23/month
• Clerk: Free up to 10,000 MAU; $25/month for production features

Competing open-source alternatives (infrastructure cost only):

• Authelia: Free software, but requires database + optional Redis. On Hetzner: ~$5–10/month for a VPS that can run Authelia + its dependencies alongside your services
• Keycloak: Free software, but Java-based and memory-hungry — realistically needs 512 MB–1 GB RAM reserved just for Keycloak, which pushes you to a larger VPS tier
• Tinyauth: Runs comfortably on the same $4–6 VPS you’re already using for everything else

The math for the target audience is almost too simple: if you’re already self-hosting and paying $6/month for a VPS, Tinyauth adds near-zero marginal cost. The comparison to Okta or Auth0 is only relevant if you were considering them — most home lab operators weren’t. The realistic choice is Tinyauth vs. Authelia vs. “no auth middleware at all,” and Tinyauth wins on setup simplicity by a wide margin [2].

---

Deployment Reality Check

Tinyauth’s deployment story is one of its strongest selling points. The XDA reviewer describes it as “an absolute breeze” and notes it runs in minutes [2]. That tracks with what the documentation shows: the getting-started guide fits on a single page, and the Docker Compose example in the repository demonstrates Traefik + Whoami + Tinyauth as a working three-service stack.

What you actually need:

• A Linux server (VPS, home server, Raspberry Pi) with Docker installed
• A reverse proxy — Traefik, Nginx, or Caddy
• A domain name with DNS pointing to your server if you want external access
• Environment variables for user credentials and OAuth app credentials if you use OAuth

What can go sideways:

The v4→v5 migration is the main current risk. Tinyauth v5 completely changed the configuration format — all environment variables and CLI flags were renamed to the TINYAUTH_<SECTION>_<KEY> scheme. The project provides a configuration migrator tool, and the migration guide notes that “dynamic configuration is not supported by this migrator” so some manual editing is required [docs]. If you’re running v4 in production, plan for a deliberate migration window.

The README itself includes a prominent warning: “Tinyauth is in active development and configuration may change often. Please make sure to carefully read the release notes before updating.” That’s an honest flag from the developer. This is not Authelia’s relative stability — you’re betting on a solo developer’s project with a stated policy of breaking changes between majors [README].

Kubernetes deployment is community-contributed, not officially supported [community docs]. If you’re running k8s, that’s relevant.

Realistic setup time for someone comfortable with Docker Compose: 15–30 minutes to a working auth layer behind Traefik. For someone new to reverse proxies and auth middleware: 2–4 hours including reading the proxy configuration docs.

---

Pros and Cons

Pros

• Genuinely zero-dependency setup. No database, no Redis, no separate config file required. Environment variables only [2][README]. This is not how most auth servers work and it’s a real advantage for simple setups.
• Resource footprint that fits anywhere. Under 10 MB RAM [2]. Runs comfortably on a Raspberry Pi Zero 2, a shared VPS, or inside a Docker stack with 12 other services.
• Multi-proxy support. Traefik, Nginx, Caddy, and Nginx Proxy Manager all have documented integration guides [docs]. You don’t have to change your proxy to use it.
• OAuth + LDAP + TOTP. For a project this small, the authentication method coverage is surprisingly complete [README][docs].
• Active development. 7,138 GitHub stars, an active Discord, multiple sponsors listed in the README, and a recent major release (v5) — the project is not abandoned [README].
• Live demo. The developer runs a public demo at demo.tinyauth.app so you can try it before installing. Most competing projects don’t bother [README].

Cons

• GPL-3.0 license. If you want to embed Tinyauth in a commercial product or resell it, the GPL requires you to open-source your own code under the same terms [README]. This is a meaningful restriction compared to MIT-licensed alternatives like OAuth2 Proxy or BSD-licensed Pocket ID [7].
• Active breaking changes. The developer explicitly warns that “configuration may change often” and v5 just proved it with a full config rename [README][docs]. If you hate reading migration guides, this is a real tax.
• No user management UI. Users are environment variables. Adding or removing a user means editing your Docker Compose file and redeploying. There’s no admin panel, no self-service account creation, no password reset flow [2][README]. Fine for two people; painful for ten.
• Solo developer project. No company, no commercial backing, no paid support tier. The project could stall, pivot, or disappear. The README’s list of GitHub sponsors is encouraging but doesn’t change the structural risk [README].
• Not for enterprise user management. If you need SSO for a team of 20+ with audit logs, user provisioning, SAML, or fine-grained RBAC, Tinyauth is the wrong tool. It solves a specific, smaller problem [2].
• Limited third-party reviews. Outside of the XDA article, there’s almost no independent review coverage. That’s partly a function of the project’s age and niche — it’s not necessarily a red flag, but it means you’re making a more information-limited decision than with Authelia or Keycloak.

---

Who Should Use This / Who Shouldn’t

Use Tinyauth if:

• You’re running 3–10 self-hosted services and want a login screen in front of all of them without learning Authelia’s YAML schema.
• Your users are you, maybe your partner, maybe one or two family members — not a real organization.
• You’re on a Raspberry Pi, an entry-level VPS, or any hardware where RAM is genuinely constrained.
• You’re comfortable with Docker Compose and reading release notes before upgrading.
• You want OIDC/OAuth/LDAP support without standing up Keycloak or authentik.

Skip it (use Authelia) if:

• You need a proven, stable auth solution with a longer community track record.
• Your setup has more than 5–10 users and you want a proper user management interface.
• You need detailed audit logging, account lockout policies, or security event tracking.
• You’re running in a production environment where a breaking config change in a minor update isn’t acceptable.

Skip it (use Keycloak or authentik) if:

• You’re managing identities for a real team or organization.
• You need SAML, multi-tenant support, user self-registration with email verification, or a full admin dashboard.
• Enterprise compliance (SOC 2, HIPAA) is a requirement.

Skip it (use Pocket ID or OAuth2 Proxy) if:

• The GPL-3.0 license is a blocker for your use case.
• You want something with MIT or Apache licensing and similar simplicity.

---

Alternatives Worth Considering

From the AlternativeTo alternatives page [7] and the project’s positioning:

• Authelia — The most direct comparison. Battle-tested, Apache-2.0 licensed, much richer feature set (full user database, brute force protection, detailed audit logs), but requires a database backend and significantly more configuration effort [2][7]. Choose Authelia if you outgrow Tinyauth or need production-grade stability.
• Pocket ID — BSD-2-Clause licensed OIDC provider with similar simplicity goals. Worth comparing if GPL-3.0 is a concern [7].
• OAuth2 Proxy — MIT-licensed forward auth proxy. More of a single-purpose tool than a full auth server, but extremely stable and widely deployed [7].
• authentik — Full-featured identity provider (freemium, open source). Much heavier than Tinyauth but includes a proper admin UI, flows engine, and enterprise features. The step up from Tinyauth when you hit its limits [7].
• ZITADEL — AGPL-3.0, SaaS + self-hostable, enterprise-grade. Similar license friction to Tinyauth but far more capable [7].
• Keycloak — The enterprise standard, Apache-2.0, runs on Java. Enormous feature set, enormous resource requirements. Only relevant if you’re building something organizational rather than personal [7].
• VoidAuth — Newer AGPL-3.0 project with passkey support, user invitations, and self-registration. Worth watching as an emerging alternative [1][7].

For a solo founder or home lab operator, the realistic shortlist is Tinyauth vs. Authelia vs. Pocket ID. Tinyauth wins on setup speed and resource footprint; Authelia wins on maturity and features; Pocket ID wins if the license matters.

---

Bottom Line

Tinyauth does exactly what it says: it’s the smallest thing that puts a login screen in front of your self-hosted apps. No database, no complex YAML, no 500 MB Java process — just a Docker container, a few environment variables, and working authentication in under 30 minutes. For a solo operator or small household running a collection of self-hosted services, that’s a genuinely useful trade-off. The limitations are real — no user management UI, breaking changes between versions, GPL-3.0 instead of a permissive license, a solo developer dependency — and they’re honest enough that the README flags them directly. If your self-hosting stack has outgrown environment-variable user management or you need enterprise features, Authelia or authentik are the next step up. But if you just want a login screen without the overhead, Tinyauth earns its 7,138 stars.

---

Sources

1. AlternativeTo — VoidAuth page (referenced for alternatives comparison). https://alternativeto.net/software/voidauth/about/
2. Sumukh Rao, XDA Developers — “I replaced Authelia with this simpler alternative for my home lab: Here’s why” (Aug 2, 2025). https://www.xda-developers.com/reasons-use-tinyauth-instead-of-authelia-for-home-lab/
3. AlternativeTo — Tinyauth Alternatives (alternatives list, last updated Feb 18, 2026). https://alternativeto.net/software/tinyauth/

Primary sources:

• GitHub repository and README: https://github.com/steveiliop56/tinyauth (7,138 stars, GPL-3.0 license)
• Official website: https://tinyauth.app
• Documentation and migration guide (v4→v5): https://tinyauth.app/docs/breaking-updates/4-to-5/
• Getting started guide: https://tinyauth.app/docs/getting-started
• Live demo: https://demo.tinyauth.app