# Tinyauth: a small OpenID Certified auth server for self-hosted apps behind Traefik, Nginx or Caddy

> Tinyauth is a Go authentication and authorization server that sits in front of your self-hosted apps as proxy middleware or as a standalone OIDC provider. The trade-off is a small feature surface and a configuration file that the README warns may change between releases.

**tinyauthapp/tinyauth** — The tiniest OpenID Certified™ authorization and authentication server you have ever seen.

- Repository: https://github.com/tinyauthapp/tinyauth
- Website: https://tinyauth.app
- Stars: 8,303 · Forks: 274
- Language: Go
- License: AGPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/tinyauthapp-tinyauth

## What problem Tinyauth solves, and for whom

A homelab or small internal deployment tends to accumulate web apps that each ship their own login, or none at all. Putting a single authentication step in front of them usually means either a full identity provider with its own database, admin UI and upgrade cadence, or a proxy-level basic-auth file that has no session handling, no second factor and no group rules.

Tinyauth occupies the space between those two. The README describes it as "the simplest and tiniest authentication and authorization server you have ever seen", designed to work both as authentication middleware for your apps and as a standalone authentication server. The audience is the person running a handful of services behind a reverse proxy who wants one login page, optional TOTP, and access rules expressed near the proxy configuration rather than inside each application.

It is a poor fit for anything that needs delegated administration, per-tenant isolation, or an extensive connector catalogue. The project's own scope statement is about being small, and everything below follows from that.

## How Tinyauth fits between your proxy and your apps

The repository layout shows the shape of the thing. There is a Go backend under cmd/ and internal/, a TypeScript frontend under frontend/ that is compiled by Vite and copied into internal/assets/dist during the Docker build, and a sql/ directory alongside sqlc.yml, which indicates the database queries are generated from SQL rather than hand-written in Go. Migrations come from golang-migrate in the dependency list.

The proxy integration is the core mechanism. Tinyauth supports Traefik, Nginx and Caddy according to the README, and it exposes access-control behaviour through a label provider. The .env.example documents TINYAUTH_LABELPROVIDER with valid values auto, docker, kubernetes or none, and describes it as the label provider used for ACLs. In the auto setting the server detects its environment. That means your authorization rules can live as labels on the containers or workloads you are already deploying, instead of in a separate rules file that drifts out of sync.

Authentication itself can come from several places. The dependency list includes go-ldap for directory lookups and golang.org/x/oauth2 for OAuth flows, and the configuration exposes a comma-separated TINYAUTH_AUTH_USERS list in username:hashed_password form for the simplest case. TOTP support is present through pquerna/otp, and there is a QR terminal dependency that suggests enrollment codes can be printed to a terminal. On the OIDC side, the README states that as of 2026-06-25, Tinyauth v5.1.0 is OpenID Certified for Basic OP, with the certification listed on the OpenID Foundation site.

Persistence is configurable. TINYAUTH_DATABASE_DRIVER accepts sqlite, postgres or memory, with TINYAUTH_DATABASE_PATH pointing at a SQLite file by default or holding a connection URL when the driver is postgres. The memory option is notable: it implies state that does not survive a restart, which is fine for a demo and wrong for anything holding sessions you care about.

## Installing Tinyauth and getting a first login working

The README does not give inline install commands. It points to the getting-started guide at tinyauth.app/docs/getting-started and to a docker-compose.example.yml in the repository that wires Traefik, Whoami and Tinyauth together as a demonstration. The README also warns that this compose file lives on the development branch and may contain updates that are not yet released, so read it as an illustration rather than a pinned artifact.

The container image is built from the Dockerfile in the repository. The runner stage is Alpine, the working directory is /tinyauth, the process listens on port 3000, and the data directory /data is declared as a volume with subdirectories for resources, OIDC and Tailscale data. The image sets RUNTIME_ENV=docker and defines a healthcheck that runs tinyauth healthcheck.

The only configuration values the repository files spell out are the environment variables in .env.example. The relevant ones for a first run are the base URL, the listening port and the user list:

```bash
TINYAUTH_APPURL=
TINYAUTH_SERVER_PORT=3000
TINYAUTH_AUTH_USERS=
```

TINYAUTH_APPURL is described as the base URL where the app is hosted, TINYAUTH_SERVER_PORT as the port on which the server listens, and TINYAUTH_AUTH_USERS as a comma-separated list of users in username:hashed_password form. The password must already be hashed; the README does not show the hashing command inline, so check the documentation site for how the project expects you to generate that value before you paste anything in.

For a configuration file instead of environment variables, set TINYAUTH_CONFIGFILE to a path. The .env.example is generated by gen/gen_env.go, so it is a faithful list of what the binary reads. The database keys are the ones worth setting explicitly:

```bash
TINYAUTH_DATABASE_DRIVER="sqlite"
TINYAUTH_DATABASE_PATH="./tinyauth.db"
```

After the container starts, the healthcheck command should report success, and the login page is served on port 3000. If you are putting it behind Traefik, Nginx or Caddy, the proxy configuration is what decides which routes are protected; Tinyauth itself does not know about your upstream services beyond what the label provider tells it.

## Development branch, nightly builds and configuration churn

The README carries a warning block that is easy to skim past: Tinyauth is in active development and configuration may change often, and users are told to read the release notes carefully before updating. The release list backs that up. Alongside v5.2.0 and its release candidate, there is a nightly channel published on 2026-09-21. Nightly is not a stable target.

The practical consequence is that an upgrade is not a routine image pull. If a configuration key is renamed or a default changes, the container can start and then behave differently rather than fail loudly, because most of these settings are optional with defaults. The .env.example is generated, which means the authoritative list of keys moves with the code, and a config file copied from an older tutorial may silently omit a key that now matters.

The README also notes that the repository's default branch is the main development branch, and directs readers to the documentation or the latest stable tag for the stable release. If you clone from main or build from the Dockerfile on main, you are not running what the certification and release notes describe.

A second limitation is scope. OpenID Certification here is for Basic OP, which is the entry-level OP profile, not a statement that every OIDC feature is implemented. If your relying parties expect anything beyond the basic profile, verify against the certification listing before you plan around it.

## Tinyauth compared with Authelia and Pocket ID

The comparison people ask about most is Authelia. Both sit in front of a reverse proxy and both can require a second factor, but the design emphasis differs. Authelia is a larger project with its own configuration model and a broader set of authentication backends and policy rules. Tinyauth's pitch is that it is the tiniest server of its kind, and the repository reflects that: one Go binary, an embedded frontend, and a configuration surface small enough to read in a single generated .env.example. The trade is that where Authelia has a documented answer for a policy edge case, Tinyauth may simply not have the feature.

Pocket ID comes up in the same searches and is a different kind of tool. Pocket ID is an identity provider built around passkeys; Tinyauth is primarily proxy middleware that can also act as a standalone authentication server and is certified for Basic OP. If your goal is passkey-first login for a set of OIDC clients, that is a different centre of gravity than guarding routes behind Traefik, Nginx or Caddy with TOTP and LDAP.

Against Keycloak, Authentik or Zitadel the difference is not really a feature comparison, it is an operational one. Those are identity platforms with admin consoles, realms or tenants, and their own upgrade stories. Tinyauth deliberately has none of that. Choosing Tinyauth means accepting that some identity problems will be solved by adding a second tool rather than by configuring Tinyauth further.

## Licence and the cost of running a modified Tinyauth

Tinyauth is licensed under AGPL-3.0. The README's own summary of the licence states that you may copy, distribute and modify the software as long as you track changes and dates in source files, that modifications or software including AGPL-licensed code must also be made available under the AGPL along with build and install instructions, and that if you run a modified version over a network you must also make the source available to the users of that service.

For a homelab user running the published image unmodified, that clause has little practical effect. For anyone patching Tinyauth and exposing it to users outside their own household, it does. This is a real constraint, not a formality, and it is worth deciding before you fork rather than after. The README points to the LICENSE file for the full text; treat the paragraph above as a pointer, not as legal advice.

Upgrade cost is the other recurring expense. Because the README states configuration may change often, budget time for reading release notes on every version bump, and avoid pinning to nightly if you are not prepared to debug the development branch.

## Conclusion

Adopt Tinyauth if you run a handful of self-hosted services behind Traefik, Nginx or Caddy and want a single login page plus TOTP without operating a full identity platform. Do not adopt it if you need a mature enterprise IdP with a large feature surface, or if you cannot tolerate configuration changes between releases: the README states configuration may change often and tells you to read the release notes before updating. Before deploying, verify the current configuration keys against the documentation at tinyauth.app rather than against the development branch, confirm which storage driver you will use (sqlite, postgres or memory), and decide whether the AGPL-3.0 network source-disclosure obligation fits how you plan to modify and host it.

## FAQ

### What is Tinyauth?

Tinyauth is an authentication and authorization server written in Go. The README describes it as the tiniest OpenID Certified authorization and authentication server, designed to work as authentication middleware for your apps and as a standalone authentication server, with support for Traefik, Nginx and Caddy.

### How do I use Tinyauth?

The README directs you to the getting-started guide at tinyauth.app/docs/getting-started and to the docker-compose.example.yml in the repository, which demonstrates Tinyauth together with Traefik and Whoami. Configuration is read from environment variables or a file pointed at by TINYAUTH_CONFIGFILE.

### Is Tinyauth secure?

Tinyauth v5.1.0 is OpenID Certified for Basic OP as of 2026-06-25, according to the README, and the repository lists OpenSSF Scorecard and Best Practices badges. The README does not make broader security claims, and it warns that configuration may change often, so review the release notes before each update.

### What are the key differences between Tinyauth and Authelia?

Both act in front of a reverse proxy, but Tinyauth's stated goal is to be the tiniest server of its kind, with a small configuration surface generated into .env.example. Authelia is a larger project with a broader policy and backend feature set. The README does not compare the two directly.

### What are the differences between Pocket ID and Tinyauth?

Pocket ID is an identity provider built around passkeys, while Tinyauth is primarily authentication and authorization middleware for proxies that can also run as a standalone authentication server. The README does not document a direct comparison between the two.

## Sources

- [License: AGPL-3.0](https://github.com/tinyauthapp/tinyauth/blob/main/LICENSE)
- [Project website](https://tinyauth.app)
- [README](https://github.com/tinyauthapp/tinyauth/blob/main/README.md)
- [Releases](https://github.com/tinyauthapp/tinyauth/releases)
- [tinyauthapp/tinyauth on GitHub](https://github.com/tinyauthapp/tinyauth)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tinyauthapp-tinyauth