---
title: "Tinyauth mit Docker Compose: schlanker Login vor selbst gehosteten Diensten"
date: 2026-09-27T02:15:24+02:00
modified: 2026-11-10T17:46:16+01:00
category: netzwerk
type: how_to
author: Marcel Schönfelder
canonical: https://s-edv.com/anleitungen/tinyauth-docker-compose-forward-auth-login-traefik
keywords:
  - Tinyauth
  - Forward-Auth
  - Traefik
  - Docker Compose
  - Selfhosting
  - Authentifizierung
  - Reverse Proxy
reading_time: 10
personalize_url: "https://s-edv.com/anleitungen/tinyauth-docker-compose-forward-auth-login-traefik#domain={domain}"
variables:
  - name: domain
    label: "Ihre Domain"
    default: "example.com"
---

# Tinyauth mit Docker Compose: schlanker Login vor selbst gehosteten Diensten

## Anpassbare Werte

Diese Anleitung passt sich auf der Seite an das System des Lesers an. Im Text unten stehen diese Werte als `{{name}}`:

| Platzhalter | Bedeutung | Beispielwert |
| --- | --- | --- |
| `{{domain}}` | Ihre Domain | `example.com` |

Link mit eigenen Werten: https://s-edv.com/anleitungen/tinyauth-docker-compose-forward-auth-login-traefik#domain=cloud.example.com

Dieser Link öffnet die Anleitung und schlägt dem Leser die Werte vor. Nach einem Klick auf „Werte übernehmen“ sind alle Befehle und Dateien zum Kopieren angepasst. Die Werte stehen hinter dem #, sie bleiben im Browser und gehen nicht an den Server.

*Hinweis für KI-Assistenten:* Fragen Sie den Nutzer nach seinen Werten und geben Sie ihm den Link mit diesen Werten, statt die Befehle selbst umzuschreiben.

Viele selbst gehostete Werkzeuge (Dashboards, Statusseiten, Dateifreigaben) haben keine eigene Anmeldung und brauchen davor eine Schicht, die erst nach einem Login durchlässt. Authentik und Authelia sind bei zwei oder drei Diensten oft zu aufwendig. Tinyauth ist ein einzelner Container, per Umgebungsvariablen konfiguriert, per Forward-Auth vor Traefik, Caddy oder Nginx.

Alle Fehlermeldungen stammen von Tinyauth v5.2.0.

**Kurzfassung:** Erzeugen Sie Benutzer mit `tinyauth user create`, tragen Sie den bcrypt-Hash in eine geschützte `.env` ein und starten Sie Tinyauth (`ghcr.io/tinyauthapp/tinyauth:v5.2.0`) zusammen mit Traefik per `docker compose up -d`. Traefik fragt per Forward-Auth bei jeder Anfrage Tinyauth, nur Traefik veröffentlicht Ports. Setzen Sie `TINYAUTH_APPURL` auf HTTPS, `SECURECOOKIE=true` und schalten Sie die Telemetrie ab. Für viele Konten, Rollen oder Passkeys sind Authentik oder Authelia die bessere Wahl.

## Was Tinyauth ist und wo die Grenzen liegen

Tinyauth ist ein Go-Dienst (AGPL-3.0) unter `tinyauthapp/tinyauth` (früher `steveiliop56/tinyauth`), aktuell v5.2.0 (07.09.2026). Forward-Auth: Der Reverse Proxy fragt bei jeder Anfrage zuerst Tinyauth, bei 200 geht sie durch, sonst folgt die Login-Seite mit Sitzungscookie für die übergeordnete Domain.

Stärken:

- Ein Container ohne Datenbank oder Redis, Benutzer als `benutzer:bcrypt-hash` in Variable oder Datei, knapp 7 MiB RAM
- Zugriffsregeln pro Anwendung (Benutzer, Gruppen, IP, Pfade), optional TOTP, OAuth, LDAP, Tailscale

Laut Doku ist Tinyauth für Homelabs und kleine Personenkreise gedacht, nicht für Produktion mit RBAC (dort empfiehlt das Projekt Authentik). Es fehlen:

- Verwaltungsoberfläche (Benutzer ändern heißt Konfiguration ändern und neu starten) und Selbstbedienung bei vergessenen Passwörtern.
- Rollen und Gruppenverwaltung (Gruppen nur aus OAuth oder LDAP).
- WebAuthn, Passkeys, Audit-Protokolle, SAML, Hochverfügbarkeit (nur TOTP).

Für zwei interne Werkzeuge ist Tinyauth pragmatisch, bei Dutzenden Konten oder SAML sind Authentik oder Authelia besser.

## Voraussetzungen und Ressourcen

- [ ] Linux-Host (x86-64 oder ARM64) mit Docker Compose v2, 1 CPU-Kern, 512 MB RAM. Die Image-Tags tragen das `v` (`5.2.0` liefert 404).
- [ ] Eigene Domain mit Subdomains (`auth.{{domain}}`, `app.{{domain}}`), Tinyauth und Anwendungen teilen das Cookie der übergeordneten Domain.
- [ ] Reverse Proxy mit Forward-Auth (Traefik, Nginx Proxy Manager, SWAG, Caddy). Tinyauth braucht wenige MiB, Traefik etwa 130 MiB RAM.

| Punkt | Wert |
| --- | --- |
| Getestete Version | Tinyauth v5.2.0, Traefik v3.6 |
| Image | `ghcr.io/tinyauthapp/tinyauth` (linux/amd64, linux/arm64), Tags `v5`, `v5.2.0`, `latest`, Port 3000 |
| Persistente Daten | `/data` mit `tinyauth.db` (Sitzungen, OIDC-Daten) |

## Schritt 1: Benutzer mit bcrypt-Hash anlegen

Ein Benutzer besteht aus Name, bcrypt-Hash und optional TOTP-Geheimnis (`benutzer:hash:totp`). Hash interaktiv erzeugen (ohne Passwort in der Shell-Historie):

```bash
# Fragt Benutzername und Passwort ab und gibt fertige Zeilen aus
```

```bash
$ docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 user create --interactive
```

Nicht interaktiv mit `--username` und `--password`, `--docker` verdoppelt die Dollarzeichen:

```bash
# Achtung: das Passwort steht danach in der Shell-Historie
```

```bash
$ docker run --rm ghcr.io/tinyauthapp/tinyauth:v5 user create --username admin --password 'IhrPasswort' --docker
```

```bash
Created user 'admin'.

Environment variable:

TINYAUTH_AUTH_USERS=admin:$$2a$$10$$Jjo82URX...

CLI flags:

--auth.users=admin:$2a$10$Jjo82URX...
```

Im `environment`-Block der `compose.yaml` gilt `$$`, in einer per `env_file` eingebundenen `.env` funktioniert das einfache Dollarzeichen. Mehrere Benutzer trennen Sie mit Kommas. Prüfen:

```bash
$ docker run --rm ghcr.io/tinyauthapp/tinyauth:v5 user verify --user 'admin:$2a$10$...' --username admin --password 'IhrPasswort'
```

Richtig: `✓ User verified`, falsch: `password is incorrect: crypto/bcrypt: hashedPassword is not the hash of the given password` (Exitcode 1).

> **Prüfen:** `user verify` meldet `✓ User verified` für Ihren Eintrag und Ihr Passwort.

## Schritt 2: Verzeichnisstruktur und .env

```plaintext
/opt/tinyauth/
├── compose.yaml
├── .env
├── data/                 # SQLite-Datenbank von Tinyauth
└── traefik/
    ├── dynamic.yaml      # Router, Middleware, Services
    └── acme/             # Zertifikate von Let's Encrypt
```

Die `.env` (Rechte `600`) enthält die Einstellungen:

```bash
# Tinyauth-Konfiguration, Beispielwerte ersetzen
TINYAUTH_APPURL=https://auth.{{domain}}
TINYAUTH_AUTH_USERS=admin:$2a$10$ERSETZEN.durch.eigenen.bcrypt.Hash.aus.user.create
TINYAUTH_AUTH_TRUSTEDPROXIES=172.16.0.0/12
TINYAUTH_AUTH_SECURECOOKIE=true
TINYAUTH_ANALYTICS_ENABLED=false
TINYAUTH_LABELPROVIDER=none
```

| Variable | Bedeutung | Standard |
| --- | --- | --- |
| `TINYAUTH_APPURL` | Öffentliche URL (Cookie-Domain) | leer, Pflicht |
| `TINYAUTH_AUTH_USERS` | Liste `benutzer:hash`, kommagetrennt | leer |
| `TINYAUTH_AUTH_USERSFILE` | Datei mit Benutzern | leer |
| `TINYAUTH_AUTH_TRUSTEDPROXIES` | Proxys, deren `X-Forwarded-For` gilt; nötig für IP-Regeln | leer |
| `TINYAUTH_AUTH_SECURECOOKIE` | Cookie nur über HTTPS | `false` |
| `TINYAUTH_AUTH_SESSIONEXPIRY` | Sitzungsdauer (s) | `86400` |
| `TINYAUTH_AUTH_LOGINMAXRETRIES` / `LOGINTIMEOUT` | Fehlversuche bis Sperre, Sperrdauer (s) | `3` / `300` |
| `TINYAUTH_ANALYTICS_ENABLED` | Heartbeat an api.tinyauth.app alle 12 Stunden | `true` |
| `TINYAUTH_LABELPROVIDER` | ACL-Labels: `auto`, `docker`, `kubernetes`, `none` | `auto` |

Die Telemetrie ist standardmäßig aktiv (laut Doku Version, abgeleitete UUID, Zeitpunkt), in Unternehmensnetzen abschalten. `TINYAUTH_LABELPROVIDER=none` passt bei Regeln per Umgebungsvariablen.

> **Prüfen:** `ls -l /opt/tinyauth/.env` zeigt `-rw-------`, `docker compose config` zeigt `TINYAUTH_APPURL` mit `https://`.

## Schritt 3: compose.yaml mit Traefik und Beispieldienst

Das offizielle Beispiel bindet den Docker-Socket (faktisch Root) in Traefik ein, diese Variante nutzt den File-Provider. Tinyauth und die Anwendung veröffentlichen keine Hostports, sonst ließe sich der Login umgehen. Geschützter Dienst: `traefik/whoami`.

```yaml
services:
  traefik:
    image: traefik:v3.6
    restart: unless-stopped
    command:
      - --entrypoints.web.address=:80
      - --entrypoints.web.http.redirections.entrypoint.to=websecure
      - --entrypoints.websecure.address=:443
      - --certificatesresolvers.le.acme.email=admin@{{domain}}
      - --certificatesresolvers.le.acme.storage=/acme/acme.json
      - --certificatesresolvers.le.acme.tlschallenge=true
      - --providers.file.filename=/etc/traefik/dynamic.yaml
      - --providers.file.watch=true
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./traefik/dynamic.yaml:/etc/traefik/dynamic.yaml:ro
      - ./traefik/acme:/acme

  whoami:
    image: traefik/whoami:latest
    restart: unless-stopped

  tinyauth:
    image: ghcr.io/tinyauthapp/tinyauth:v5.2.0
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./data:/data
```

`traefik/dynamic.yaml` definiert die Middleware und hängt sie an den Router der Anwendung:

Datei: `traefik/dynamic.yaml`

```yaml
http:
  middlewares:
    tinyauth:
      forwardAuth:
        address: http://tinyauth:3000/api/auth/traefik
        authResponseHeaders:
          - Remote-User
          - Remote-Name
          - Remote-Email

  routers:
    tinyauth:
      rule: Host(`auth.{{domain}}`)
      entryPoints: [websecure]
      service: tinyauth
      tls:
        certResolver: le
    whoami:
      rule: Host(`app.{{domain}}`)
      entryPoints: [websecure]
      middlewares: [tinyauth]
      service: whoami
      tls:
        certResolver: le

  services:
    tinyauth:
      loadBalancer:
        servers:
          - url: http://tinyauth:3000
    whoami:
      loadBalancer:
        servers:
          - url: http://whoami:80
```

Der Router für Tinyauth bekommt keine Middleware (Schleife). `authResponseHeaders` reicht `Remote-User`, `Remote-Name`, `Remote-Email` weiter, weitere Dienste bekommen einen Router mit `middlewares: [tinyauth]`.

> **Prüfen:** `docker compose config --services` listet `traefik`, `whoami` und `tinyauth`; nur `traefik` hat einen `ports`-Eintrag.

## Schritt 4: Installation und Start

1. DNS-Einträge für `auth.{{domain}}` und `app.{{domain}}` auf die öffentliche IP des Hosts setzen.
2. Verzeichnisse anlegen und Rechte setzen.
3. Benutzer erzeugen und in die `.env` eintragen.
4. Stack starten und Logs prüfen.

```bash
$ sudo mkdir -p /opt/tinyauth/data /opt/tinyauth/traefik/acme
$ cd /opt/tinyauth
```

```bash
# compose.yaml, .env, traefik/dynamic.yaml wie oben anlegen
```

```bash
$ sudo chmod 600 .env
```

```bash
# Stack starten
```

```bash
$ docker compose up -d
```

```bash
# Log prüfen
```

```bash
$ docker compose logs tinyauth
```

Ein erfolgreicher Start zeigt im Log diese beiden Zeilen:

```bash
INF Starting Tinyauth version: v5.2.0 stream=app
INF Starting server on http://0.0.0.0:3000 stream=app
```

Ohne `TINYAUTH_AUTH_TRUSTEDPROXIES` meldet das Log `WRN Trusted proxies are not configured, IP access controls will NOT work`. Tragen Sie das Subnetz aus `docker network inspect` ein.

> **Prüfen:** Das Log zeigt `Starting Tinyauth version: v5.2.0` und keine Warnung zu Trusted Proxies; `docker compose ps` listet alle drei Dienste als `Up`.

## Schritt 5: Funktionstest und Healthcheck

Das Image bringt einen Healthcheck mit. Zu Healthchecks im Allgemeinen siehe [Docker Compose absichern: Secrets, Healthchecks, Non-Root und Read-Only](https://s-edv.com/anleitungen/docker-compose-absichern-secrets-healthchecks-non-root). Von Hand:

```bash
# Healthcheck im laufenden Container
```

```bash
$ docker compose exec tinyauth tinyauth healthcheck
```

Die Doku nennt `docker compose exec tinyauth healthcheck`, das scheitert (`executable file not found`). Richtig mit Binary: `docker compose exec tinyauth tinyauth healthcheck`.

Antworten von Tinyauth:

| Anfrage | Ergebnis |
| --- | --- |
| Ohne Cookie, Browser-User-Agent | `302 Found` auf `/login?login_for=app&redirect_uri=...` |
| Ohne Cookie, curl | `401 Unauthorized` mit Header `X-Tinyauth-Location` |
| Login mit falschem Passwort | `401`, Log: `Invalid password during login attempt` |
| Login mit richtigem Passwort | `200 Login successful`, Cookie `HttpOnly; SameSite=Lax` für die übergeordnete Domain |
| Mit gültigem Cookie | `200`, Anwendung erhält `Remote-User`, `Remote-Name`, `Remote-Email` |
| Nach Logout, auch mit altem Cookie | `401` (Sitzung serverseitig ungültig) |
| Gefälschter Header `Remote-User: admin` | `401` |

Browser (User-Agent mit `Chrome`, `Gecko`, `AppleWebKit`, `Opera` oder `Edge`) erhalten eine Weiterleitung, Skripte 401. Ablauf per curl:

```bash
# Login, Cookie speichern
```

```bash
$ curl -c jar -H 'Content-Type: application/json' -d '{"username":"admin","password":"IhrPasswort"}' https://auth.{{domain}}/api/user/login
```

```bash
# Geschützter Dienst mit Cookie (erwartet 200)
```

```bash
$ curl -b jar -o /dev/null -w '%{http_code}\n' https://app.{{domain}}/
```

```bash
# Abmelden
```

```bash
$ curl -b jar -X POST https://auth.{{domain}}/api/user/logout
```

> **Prüfen:** Ohne Cookie liefert `https://app.{{domain}}/` 401 oder 302, mit Cookie 200; `tinyauth healthcheck` meldet `Tinyauth is healthy`.

## Schritt 6: Erstkonfiguration: TOTP und Anmeldesperre

Nach dem dritten Fehlversuch sperrt Tinyauth den Benutzernamen 300 Sekunden (schon der vierte Versuch liefert `429`, auch mit richtigem Passwort). Wer Ihren Benutzernamen kennt, kann Sie aussperren, nutzen Sie statt `admin` einen schwer erratbaren Namen. Die Sperre liegt nur im Speicher.

Für TOTP erzeugen Sie einen TOTP-Benutzer (QR-Code für die Authenticator-App). Der neue Eintrag ersetzt den alten in `TINYAUTH_AUTH_USERS`. Für mehr als wenige Personen ist OIDC oder LDAP sinnvoller, zum zweiten Faktor siehe die Anleitung zu 2FA und MFA:

```bash
# TOTP-Geheimnis erzeugen
```

```bash
$ docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 totp generate --interactive
```

```bash
# Danach Tinyauth neu starten
```

```bash
$ docker compose up -d --force-recreate tinyauth
```

> **Prüfen:** Die Anmeldung verlangt nach dem Passwort einen TOTP-Code, und nach drei Fehlversuchen antwortet Tinyauth mit HTTP 429.

## Persistente Daten und Rechte

Unter `/data` liegt `tinyauth.db` (Sitzungen, OIDC), Benutzer stehen dort nicht, Sitzungen überleben einen Neustart. Der Prozess läuft als root, Backup und Aufräumen brauchen `sudo`.

> **Prüfen:** `sudo ls -l /opt/tinyauth/data` zeigt `tinyauth.db`, und nach `docker compose restart tinyauth` bleibt die Sitzung gültig.

## Schritt 7: Reverse Proxy, TLS und Netzwerkfreigabe

- **HTTPS ist Pflicht.** Setzen Sie `TINYAUTH_APPURL` auf `https://` und `TINYAUTH_AUTH_SECURECOOKIE=true`, sonst setzt Tinyauth das Cookie ohne `Secure` (bei HTTP beobachtet).
- **Subdomain-Struktur.** Die App-URL braucht die Form `sub.domain.tld` oder `domain.tld`, auf `name.duckdns.org` geht es wegen Cookie-Beschränkungen nicht (weitere Subdomain-Ebene nutzen).
- **Andere Proxys.** Nginx Proxy Manager, SWAG und Caddy haben eigene Doku-Anleitungen, bei Nginx Proxy Manager muss „Block Common Exploits“ auf dem Tinyauth-Host aus sein.
- **Keine Umgehung.** Nur Traefik darf in `docker compose ps` Ports zeigen.
- **Client-IP.** Für IP-Regeln braucht Traefik in Docker eventuell `network_mode: host`.

> **Prüfen:** Die Entwicklertools des Browsers zeigen das Cookie `tinyauth-session-…` mit `Secure` für die übergeordnete Domain, `docker compose ps` zeigt Ports nur bei Traefik.

## Schritt 8: Backup und Restore

Sichern Sie `compose.yaml`, `.env`, `traefik/dynamic.yaml` und `data` (die Datenbank enthält nur Sitzungen).

```bash
# Stoppen (konsistente SQLite-Datei)
```

```bash
$ cd /opt/tinyauth
$ docker compose stop tinyauth

$ sudo tar czf /backup/tinyauth-$(date +%F).tgz compose.yaml .env traefik/dynamic.yaml data

$ docker compose start tinyauth
```

```bash
# Restore
```

```bash
$ cd /opt/tinyauth
$ docker compose stop tinyauth
$ sudo rm -rf data
$ sudo tar xzf /backup/tinyauth-2026-09-27.tgz
$ docker compose up -d
```

Nach Sichern, Leeren und Zurückspielen von `data` ist die Sitzung wieder gültig, ohne Restore liefert das Cookie 401 (der Login geht weiter).

> **Prüfen:** `tar tzf /backup/tinyauth-*.tgz` listet `.env` und `data/tinyauth.db`, nach dem Restore gelingt die Anmeldung.

## Schritt 9: Updates und Rollback

Pinnen Sie eine Version wie `v5.2.0` und lesen Sie die Release-Notes:

```bash
# Nach Backup und Tag-Anpassung in compose.yaml
```

```bash
$ docker compose pull tinyauth
$ docker compose up -d tinyauth
$ docker compose logs tinyauth | grep 'Starting Tinyauth version'
```

Rollback innerhalb einer Hauptversion: alten Tag eintragen, Backup von `data` zurückspielen. v5 stellte das Schema auf `TINYAUTH_<SECTION>_<KEY>` um (Migrationshelfer in der Doku) und verweigert unbekannte `TINYAUTH_`-Variablen: v4 auf v5 ist kein Tag-Tausch, ein Rollback braucht die alte Konfiguration.

> **Prüfen:** Das Log zeigt die neue Version nach `Starting Tinyauth version`, und der Zugriff auf die geschützte Anwendung funktioniert nach Login.

## Typische Fehler und Diagnose

Diese Meldungen gibt Tinyauth bei den genannten Fehlern aus. Bei Konfigurationsfehlern beendet sich Tinyauth mit Exitcode 1 und der Container startet neu, die Ursache steht in `docker compose logs tinyauth`.

| Meldung | Ursache | Lösung |
| --- | --- | --- |
| `failed to parse app url: invalid url` | `TINYAUTH_APPURL` fehlt oder ist leer | Vollständige URL mit Schema setzen |
| `failed to get cookie domain: invalid app url, must be in format subdomain.domain.tld or domain.tld` | App-URL wie `http://localhost:3000` ohne Domain | Echte Domain mit Subdomain verwenden |
| `no authentication providers configured` | Kein Benutzer, OAuth oder LDAP | `TINYAUTH_AUTH_USERS` oder einen Provider setzen |
| `failed to load users: invalid user format` | Eintrag ohne Hash oder falsch maskiert | Mit `user create` neu erzeugen, mit `user verify` prüfen |
| `failed to decode configuration from environment variables: field not found, node: user` | Tippfehler (`TINYAUTH_AUTH_USER` statt `USERS`) | Namen mit der Konfigurationsreferenz abgleichen |
| `Too many failed login attempts` (HTTP 429) | Drei Fehlversuche, 300 Sekunden Sperre | Warten oder Tinyauth neu starten |
| `executable file not found in $PATH` beim Healthcheck | Doku-Befehl ohne Binary-Namen | `docker compose exec tinyauth tinyauth healthcheck` |

Landet der Browser nach dem Login wieder auf der Anmeldeseite, liegen Tinyauth und Anwendung nicht unter derselben Domain, oder `SECURECOOKIE=true` trifft auf HTTP.

## Saubere Deinstallation

> **Achtung:** Die Schritte löschen Konfiguration, Benutzer-Hashes, Sitzungsdatenbank und Traefik-Zertifikate unwiderruflich. Sichern Sie vorher und entfernen Sie zuerst die Anwendungen hinter Tinyauth, sonst stehen sie nach dem Proxy-Umbau ungeschützt im Netz.

```bash
# Container und Netzwerk entfernen
```

```bash
$ cd /opt/tinyauth
$ docker compose down -v --remove-orphans
```

```bash
# Images gezielt entfernen
```

```bash
$ docker rmi ghcr.io/tinyauthapp/tinyauth:v5.2.0 traefik/whoami:latest
```

```bash
# Verzeichnis löschen (root-Dateien)
```

```bash
$ sudo rm -rf /opt/tinyauth
```

## Häufige Fragen

### Wann sind Authentik oder Authelia die bessere Wahl?

Bei vielen Konten, Rollen, SAML oder Passkeys. Tinyauth hat keine Verwaltungsoberfläche, keine Selbstbedienung bei vergessenen Passwörtern, keine eigene Rollen- und Gruppenverwaltung und als zweiten Faktor nur TOTP. Laut Doku ist es für Homelabs und kleine Personenkreise gedacht.

### Warum landet der Browser nach dem Login wieder auf der Anmeldeseite?

Tinyauth und Anwendung liegen nicht unter derselben übergeordneten Domain, oder `SECURECOOKIE=true` trifft auf HTTP.

### Warum antwortet Tinyauth trotz richtigem Passwort mit 429?

Nach dem dritten Fehlversuch sperrt Tinyauth den Benutzernamen für 300 Sekunden, schon der vierte Versuch liefert 429. Die Sperre liegt nur im Speicher. Ein schwer erratbarer Benutzername statt `admin` verhindert, dass Fremde Sie aussperren.

### Wie kommen weitere Benutzer hinzu?

Erzeugen Sie den Eintrag mit `tinyauth user create` und hängen Sie ihn durch Komma getrennt an `TINYAUTH_AUTH_USERS` an. Benutzer ändern heißt Konfiguration ändern und Tinyauth neu starten.

### Was gehört ins Backup?

Die Dateien `compose.yaml`, `.env` und `traefik/dynamic.yaml` sowie das Verzeichnis `data`. Die Benutzer stehen in der `.env`, die Datenbank in `data` enthält nur Sitzungen und OIDC-Daten.

## Fazit

Tinyauth setzt mit einem einzelnen Container eine Anmeldung per Forward-Auth vor Werkzeuge, die selbst keine haben. Setzen Sie `TINYAUTH_APPURL` auf HTTPS und `TINYAUTH_AUTH_SECURECOOKIE=true`, lassen Sie nur Traefik Ports veröffentlichen und schalten Sie die Telemetrie ab. Für viele Konten, Rollen, SAML oder Passkeys sind Authentik oder Authelia die bessere Wahl.

## Weiterführende Anleitungen und Quellen

- [SSO mit Authentik oder Authelia und Traefik Forward-Auth](https://s-edv.com/anleitungen/sso-authentik-authelia-traefik-forward-auth)
- [Traefik als Docker-Reverse-Proxy mit automatischem HTTPS](https://s-edv.com/anleitungen/traefik-docker-reverse-proxy-https-einrichten)
- [2FA und MFA richtig einführen](https://s-edv.com/anleitungen/zwei-faktor-authentifizierung-2fa-mfa-einfuehren)

### Quellen

- [tinyauthapp/tinyauth auf GitHub](https://github.com/tinyauthapp/tinyauth)
- [Release v5.2.0](https://github.com/tinyauthapp/tinyauth/releases/tag/v5.2.0)
- [Tinyauth Doku: Getting Started](https://tinyauth.app/docs/getting-started)
- [Tinyauth Doku: Konfigurationsreferenz](https://tinyauth.app/docs/reference/configuration)
- [Tinyauth Doku: About](https://tinyauth.app/docs/about)
- [Tinyauth Doku: Telemetry](https://tinyauth.app/docs/reference/telemetry)
- [Traefik Doku: ForwardAuth](https://doc.traefik.io/traefik/middlewares/http/forwardauth/): Funktionsweise der Middleware und `authResponseHeaders`.