Viele selbst gehostete Werkzeuge bringen keine eigene Anmeldung mit: Dashboards wie Homepage, Statusseiten, einfache Dateifreigaben oder interne Test-Instanzen. Wer sie trotzdem über das Internet erreichbar machen will, braucht eine Schicht davor, die erst nach einem Login durchlässt. Authentik und Authelia leisten das zuverlässig, sind aber für zwei oder drei Dienste und eine Handvoll Personen oft mehr Aufwand als nötig. Tinyauth setzt genau hier an: ein einzelner Container, konfiguriert über Umgebungsvariablen, der sich per Forward-Auth vor Traefik, Caddy oder Nginx hängt.

Diese Anleitung zeigt den vollständigen Aufbau mit Docker Compose, Traefik und einem Beispieldienst, die Erzeugung der Benutzer mit bcrypt-Hash, den Funktionstest, Backup und Restore, Updates und die typischen Fehlermeldungen. Alle Fehlermeldungen im Text stammen aus einer eigenen Testumgebung mit Tinyauth v5.2.0 vom 27.09.2026. Ebenso deutlich beschreibt der Artikel, wo Tinyauth aufhört und ein vollwertiger Identity Provider die bessere Wahl ist.

Was Tinyauth ist und wo die Grenzen liegen

Tinyauth ist ein in Go geschriebener Authentifizierungsdienst unter AGPL-3.0. Das Projekt liegt inzwischen unter tinyauthapp/tinyauth (früher steveiliop56/tinyauth) und hatte laut GitHub-API am 27.09.2026 rund 8.290 Sterne; das aktuelle Release ist v5.2.0 vom 07.09.2026. Das Prinzip ist Forward-Auth: Der Reverse Proxy fragt bei jeder Anfrage an einen geschützten Dienst zuerst Tinyauth. Antwortet Tinyauth mit 200, reicht der Proxy die Anfrage durch. Andernfalls landet der Browser auf der Login-Seite von Tinyauth, die nach erfolgreicher Anmeldung ein Sitzungscookie für die übergeordnete Domain setzt und zurück zum ursprünglichen Ziel leitet.

Die Stärken liegen im geringen Aufwand:

Ein Container, keine externe Datenbank, kein Redis. Sitzungen liegen standardmäßig in einer SQLite-Datei unter /data.
Benutzer stehen als benutzer:bcrypt-hash direkt in einer Umgebungsvariablen oder einer Datei.
Optional TOTP als zweiter Faktor, Login über OAuth (Google, GitHub, generisches OIDC wie Pocket ID), LDAP und Tailscale.
Zugriffsregeln pro Anwendung (Benutzer, Gruppen, IP-Bereiche, Pfade) über Umgebungsvariablen oder Docker-Labels.
Sehr geringer Ressourcenbedarf: Im Test belegte der laufende Tinyauth-Container knapp 7 MiB RAM, das Image ist rund 64 MB groß.

Die Grenzen nennt das Projekt selbst: Tinyauth ist laut offizieller Doku für Homelabs und das Teilen von Diensten mit einem kleinen Personenkreis gedacht und ausdrücklich nicht für Produktionsumgebungen mit Bedarf an RBAC und feingranularen Berechtigungen. Für solche Fälle empfiehlt das Projekt Authentik. Konkret fehlen im Vergleich zu Authentik und Authelia:

Eine Verwaltungsoberfläche. Benutzer anlegen, Passwort ändern oder sperren heißt: Konfiguration ändern und Container neu starten. Es gibt keine Selbstbedienung für Passwort vergessen.
Rollen, Gruppenverwaltung und Genehmigungsabläufe im Dienst selbst. Gruppen kommen nur aus OAuth oder LDAP.
WebAuthn, Passkeys und Hardware-Schlüssel. Als zweiter Faktor steht nur TOTP zur Verfügung.
Audit-Protokolle in Unternehmensqualität, SAML und Hochverfügbarkeitskonzepte.

Für ein kleines Team, das zwei interne Werkzeuge absichern will, ist Tinyauth eine pragmatische Lösung. Wer Dutzende Konten verwaltet, Onboarding und Offboarding sauber dokumentieren muss oder Single Sign-on für Anwendungen mit SAML braucht, sollte direkt zu Authentik oder Authelia greifen.

Voraussetzungen und Ressourcen

Linux-Host mit Docker Engine und Docker Compose v2. Getestet mit Docker Compose 2.40.3.
Eine eigene Domain mit Subdomains, zum Beispiel auth.example.com für Tinyauth und app.example.com für den geschützten Dienst. Tinyauth setzt das Cookie auf die übergeordnete Domain, deshalb müssen Tinyauth und die Anwendungen unter derselben Domain liegen.
Ein Reverse Proxy mit Forward-Auth. Die Doku beschreibt Traefik als Standard und liefert Anleitungen für Nginx Proxy Manager, SWAG und Caddy (Caddy als Community-Beitrag).
RAM: Tinyauth selbst benötigt nur wenige MiB, Traefik lag im Test bei etwa 130 MiB.

Punkt	Wert
Getestete Version	Tinyauth v5.2.0 (Commit 653b747, Build 07.09.2026), Traefik v3.6
Image	`ghcr.io/tinyauthapp/tinyauth`, Tags `v5`, `v5.2.0`, `latest`
Architekturen	linux/amd64 und linux/arm64 (laut Manifest in der Registry)
Interner Port	3000
Persistente Daten	`/data` mit `tinyauth.db` (Sitzungen, OIDC-Daten)
Lizenz	AGPL-3.0

Wichtig beim Pinnen der Version: Die Tags in der Registry tragen das v. v5.2.0 existiert, 5.2.0 liefert beim Abruf einen Fehler 404.

Benutzer mit bcrypt-Hash anlegen

Ein Tinyauth-Benutzer besteht aus Benutzername, bcrypt-Hash des Passworts und optional einem TOTP-Geheimnis im Format benutzer:hash:totp. Den Hash erzeugt das Image selbst. Interaktiv, ohne dass das Passwort in der Shell-Historie landet:

# Fragt Benutzername und Passwort ab und gibt fertige Zeilen aus
docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 user create --interactive

Nicht interaktiv geht es mit --username und --password. Der Schalter --docker verdoppelt die Dollarzeichen, damit Docker Compose sie nicht als Variablen interpretiert:

# Achtung: das Passwort steht danach in der Shell-Historie
docker run --rm ghcr.io/tinyauthapp/tinyauth:v5 user create --username admin --password 'IhrPasswort' --docker

Die Ausgabe im Test sah so aus (Hash gekürzt):

Created user 'admin'.

Environment variable:

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

CLI flags:

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

Welche Form Sie brauchen, hängt vom Ablageort ab. Direkt im environment-Block der compose.yaml verwenden Sie die Form mit $$, so wie es die Doku empfiehlt. In einer .env-Datei, die per env_file eingebunden wird, funktionierte im Test die Form mit einfachen Dollarzeichen. Mehrere Benutzer trennen Sie mit Kommas. Ob ein Eintrag passt, prüft der Befehl user verify:

# Prüft Benutzer und Passwort gegen den gespeicherten Hash
docker run --rm ghcr.io/tinyauthapp/tinyauth:v5 user verify --user 'admin:$2a$10$...' --username admin --password 'IhrPasswort'

Bei richtigem Passwort meldet der Befehl ✓ User verified, bei falschem password is incorrect: crypto/bcrypt: hashedPassword is not the hash of the given password mit Exitcode 1.

Verzeichnisstruktur und .env

Die Anleitung verwendet folgende Struktur unter /opt/tinyauth:

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

Die .env enthält die Einstellungen von Tinyauth. Setzen Sie die Rechte auf 600, weil dort die Hashes stehen:

# Tinyauth-Konfiguration, Beispielwerte ersetzen
TINYAUTH_APPURL=https://auth.example.com
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 von Tinyauth, daraus wird die Cookie-Domain abgeleitet	leer, Pflicht
`TINYAUTH_AUTH_USERS`	Kommagetrennte Liste `benutzer:hash`	leer
`TINYAUTH_AUTH_USERSFILE`	Alternativ: Pfad zu einer Datei mit Benutzern	leer
`TINYAUTH_AUTH_TRUSTEDPROXIES`	Proxy-Adressen, denen `X-Forwarded-For` geglaubt wird; nötig für IP-Regeln	leer
`TINYAUTH_AUTH_SECURECOOKIE`	Cookie nur über HTTPS senden	`false`
`TINYAUTH_AUTH_SESSIONEXPIRY`	Sitzungsdauer in Sekunden	`86400`
`TINYAUTH_AUTH_LOGINMAXRETRIES` / `LOGINTIMEOUT`	Fehlversuche bis zur Sperre und Sperrdauer in Sekunden	`3` / `300`
`TINYAUTH_ANALYTICS_ENABLED`	Heartbeat mit Version und Instanz-UUID an api.tinyauth.app alle 12 Stunden	`true`
`TINYAUTH_LABELPROVIDER`	Quelle für ACL-Labels: `auto`, `docker`, `kubernetes`, `none`	`auto`

Die Telemetrie ist standardmäßig aktiv. Laut Doku werden nur Version, eine aus der App-URL abgeleitete UUID und der Zeitpunkt übertragen. In Unternehmensnetzen sollten Sie sie trotzdem abschalten, wie im Beispiel. TINYAUTH_LABELPROVIDER=none ist sinnvoll, wenn Sie Zugriffsregeln per Umgebungsvariablen statt per Docker-Labels pflegen, denn für Labels bräuchte Tinyauth Zugriff auf den Docker-Socket.

compose.yaml mit Traefik und Beispieldienst

Das offizielle Beispiel bindet den Docker-Socket in Traefik ein und konfiguriert alles per Labels. Die hier gezeigte Variante nutzt stattdessen den File-Provider von Traefik. Das ist etwas mehr Schreibarbeit, aber kein Container erhält Zugriff auf den Docker-Socket, der faktisch Root-Rechte auf dem Host bedeutet. Als geschützter Dienst dient traefik/whoami, der die empfangenen Header zurückgibt.

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@example.com
      - --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

Tinyauth veröffentlicht bewusst keinen Port auf dem Host. Der Dienst ist nur über das Docker-Netz und damit nur über Traefik erreichbar. Ebenso wichtig: Auch die geschützte Anwendung darf keinen eigenen Hostport haben, sonst umgeht jeder den Login, der den Port direkt anspricht.

Die dynamische Konfiguration in traefik/dynamic.yaml definiert die Middleware und hängt sie an den Router der Anwendung:

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

  routers:
    tinyauth:
      rule: Host(`auth.example.com`)
      entryPoints: [websecure]
      service: tinyauth
      tls:
        certResolver: le
    whoami:
      rule: Host(`app.example.com`)
      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 selbst bekommt keine Middleware, sonst entsteht eine Schleife. Mit authResponseHeaders übernimmt Traefik die Header Remote-User, Remote-Name und Remote-Email aus der Antwort von Tinyauth und reicht sie an die Anwendung weiter. Anwendungen mit Header-Login können so den angemeldeten Benutzer übernehmen. Weitere Dienste schützen Sie, indem Sie für jeden einen Router mit middlewares: [tinyauth] ergänzen.

Installation und Start

DNS-Einträge für auth.example.com und app.example.com auf die öffentliche IP des Hosts setzen.
Verzeichnisse anlegen und Rechte setzen.
Benutzer erzeugen und in die .env eintragen.
Stack starten und Logs prüfen.

# Verzeichnisse anlegen
sudo mkdir -p /opt/tinyauth/data /opt/tinyauth/traefik/acme
cd /opt/tinyauth

# compose.yaml, .env und traefik/dynamic.yaml wie oben anlegen, dann Rechte setzen
sudo chmod 600 .env

# Stack starten
docker compose up -d

# Start von Tinyauth prüfen
docker compose logs tinyauth

Ein erfolgreicher Start zeigt im Log diese beiden Zeilen:

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

Fehlt TINYAUTH_AUTH_TRUSTEDPROXIES, erscheint zusätzlich WRN Trusted proxies are not configured, IP access controls will NOT work. Der Login funktioniert dann trotzdem, aber IP-basierte Regeln greifen nicht. Das Docker-Netz liegt in der Regel in 172.16.0.0/12. Enger ist sauberer: Tragen Sie das konkrete Subnetz aus docker network inspect ein.

Funktionstest und Healthcheck

Das Image bringt einen eingebauten Healthcheck mit, der Container meldet nach wenigen Sekunden (healthy). Den Check von Hand aufrufen geht so:

# Healthcheck im laufenden Container
docker compose exec tinyauth tinyauth healthcheck

Die Doku schreibt an dieser Stelle docker compose exec tinyauth healthcheck. Das scheiterte im Test mit exec: "healthcheck": executable file not found in $PATH, weil das Binary tinyauth heißt. Mit vorangestelltem tinyauth kommt Tinyauth is healthy response={"message":"Healthy","status":200}.

Das Verhalten des Schutzes lässt sich mit curl prüfen. Im Test ergaben sich diese Antworten:

Anfrage	Ergebnis
Anwendung ohne Cookie, Browser-User-Agent	`302 Found` auf `/login?login_for=app&redirect_uri=...`, Pfad und Query bleiben erhalten
Anwendung ohne Cookie, curl ohne Browser-Kennung	`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`, Domain ist die übergeordnete Domain
Anwendung mit gültigem Cookie	`200`, Anwendung erhält `Remote-User`, `Remote-Name`, `Remote-Email`
Nach Logout, auch mit kopiertem altem Cookie-Wert	`401`, die Sitzung ist serverseitig ungültig
Gefälschter Header `Remote-User: admin` ohne Login	`401`

Ob Tinyauth eine Weiterleitung oder ein 401 schickt, entscheidet der User-Agent: Nur Kennungen mit Chrome, Gecko, AppleWebKit, Opera oder Edge gelten als Browser. Skripte und API-Clients bekommen deshalb ein sauberes 401 statt einer HTML-Seite. Den kompletten Ablauf per curl nachstellen können Sie so:

# Login, Cookie in Datei speichern
curl -c jar -H 'Content-Type: application/json' -d '{"username":"admin","password":"IhrPasswort"}' https://auth.example.com/api/user/login

# Geschützten Dienst mit Cookie abrufen, erwartet 200
curl -b jar -o /dev/null -w '%{http_code}\n' https://app.example.com/

# Abmelden
curl -b jar -X POST https://auth.example.com/api/user/logout

Erstkonfiguration: TOTP und Anmeldesperre

Nach dem dritten falschen Passwort sperrt Tinyauth das Konto für 300 Sekunden. Im Test lieferte schon der vierte Versuch 429 mit Too many failed login attempts. Try again in 299 seconds, und zwar auch mit dem richtigen Passwort. Die Sperre gilt pro Benutzername. Das bremst Passwortraten, bedeutet aber auch: Wer Ihren Benutzernamen kennt, kann Sie durch wiederholte Fehlversuche aussperren. Ein wenig erratbarer Benutzername statt admin hilft. Die Sperre lag im Test nur im Speicher und war nach einem Neustart des Containers aufgehoben.

Für einen zweiten Faktor erzeugen Sie aus dem vorhandenen Eintrag einen TOTP-Benutzer. Der Befehl zeigt einen QR-Code für die Authenticator-App und gibt den neuen Eintrag benutzer:hash:geheimnis aus, der den alten in TINYAUTH_AUTH_USERS ersetzt:

# TOTP-Geheimnis für einen bestehenden Benutzer erzeugen
docker run -i -t --rm ghcr.io/tinyauthapp/tinyauth:v5 totp generate --interactive

# Danach Tinyauth neu starten
docker compose up -d --force-recreate tinyauth

Für mehr als eine Handvoll Personen ist die Anbindung an einen vorhandenen Identitätsdienst per OIDC oder LDAP sinnvoller als lokale Konten. Tinyauth wird dann zur schlanken Forward-Auth-Schicht vor einem zentralen Verzeichnis. Hinweise zur Einführung eines zweiten Faktors im Unternehmen finden Sie in unserer Anleitung zu 2FA und MFA.

Persistente Daten und Rechte

Unter /data legt Tinyauth die SQLite-Datei tinyauth.db an. Im Test enthielt sie die Tabellen sessions, oidc_sessions, oidc_consents und schema_migrations. Benutzer stehen dort nicht, sie kommen immer aus der Konfiguration. Die Datenbank sorgt dafür, dass Sitzungen einen Neustart überleben: Nach docker compose restart tinyauth blieb das Cookie gültig.

Das Dockerfile legt zwar einen Benutzer tinyauth an, der Prozess lief im Test aber als root (uid=0), und die Datenbankdatei gehörte root:root. Planen Sie Backup-Skripte und Aufräumarbeiten entsprechend mit sudo oder über einen Hilfscontainer.

Reverse Proxy, TLS und Netzwerkfreigabe

HTTPS ist Pflicht. Setzen Sie TINYAUTH_APPURL auf https:// und TINYAUTH_AUTH_SECURECOOKIE=true. Ohne diesen Schalter setzt Tinyauth das Cookie ohne Secure, wie im Test mit HTTP zu sehen.
Subdomain-Struktur. Die App-URL muss die Form sub.domain.tld oder domain.tld haben. Direkt auf einer DynDNS-Adresse wie name.duckdns.org funktioniert es laut Doku wegen Cookie-Beschränkungen der Browser nicht, nutzen Sie dort eine weitere Subdomain-Ebene.
Andere Proxys. Für Nginx Proxy Manager, SWAG und Caddy gibt es eigene Anleitungen in der Doku. Bei Nginx Proxy Manager muss auf dem Tinyauth-Host die Option "Block Common Exploits" deaktiviert sein, weil sie URLs in Query-Parametern blockiert.
Keine Umgehung. Prüfen Sie mit docker compose ps, dass nur Traefik Ports veröffentlicht.
Client-IP. Laut Doku braucht Traefik in Docker für korrekte Client-IPs unter Umständen network_mode: host, weil Docker NAT verwendet. Relevant ist das nur, wenn Sie IP-Regeln nutzen.

Backup und Restore

Zu sichern sind drei Dinge: compose.yaml, .env mit den Benutzer-Hashes und traefik/dynamic.yaml sowie das Verzeichnis data. Die Datenbank enthält nur Sitzungen. Geht sie verloren, müssen sich alle neu anmelden, Konten gehen dabei nicht verloren.

# Tinyauth kurz stoppen, damit die SQLite-Datei konsistent ist
cd /opt/tinyauth
docker compose stop tinyauth

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

# Wieder starten
docker compose start tinyauth

# Restore: stoppen, Daten ersetzen, starten
cd /opt/tinyauth
docker compose stop tinyauth
sudo rm -rf data
sudo tar xzf /backup/tinyauth-2026-09-27.tgz
docker compose up -d

Im Test wurde das Datenverzeichnis gesichert, geleert und zurückgespielt. Danach war eine zuvor angelegte Sitzung wieder gültig (HTTP 200). Nach dem Löschen der Datenbank ohne Restore lieferte dasselbe Cookie erwartungsgemäß 401, der Login mit dem Benutzer aus der Konfiguration funktionierte weiter.

Updates und Rollback

Pinnen Sie eine konkrete Version wie v5.2.0, lesen Sie vor dem Wechsel die Release-Notes und aktualisieren Sie dann gezielt:

# Vorher Backup wie oben, dann Tag in compose.yaml anpassen
docker compose pull tinyauth
docker compose up -d tinyauth
docker compose logs tinyauth | grep 'Starting Tinyauth version'

Ein Rollback innerhalb einer Hauptversion bedeutet: alten Tag eintragen, Backup von data zurückspielen, neu starten. Zwischen Hauptversionen gab es Brüche. Mit v5 hat das Projekt das komplette Konfigurationsschema auf TINYAUTH_<SECTION>_<KEY> umgestellt und stellt dafür einen Migrationshelfer in der Doku bereit. Seit v5 verweigert Tinyauth bei unbekannten Variablen mit Präfix TINYAUTH_ den Start. Ein Wechsel von v4 auf v5 ist deshalb kein einfacher Tag-Tausch, und ein Rollback braucht die alte Konfiguration.

Typische Fehler und Diagnose

Die folgenden Meldungen wurden im Test gezielt provoziert. Tinyauth beendet sich bei Konfigurationsfehlern sofort mit Exitcode 1, der Container startet dann in einer Schleife neu. Die Ursache steht immer 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`	Weder Benutzer noch OAuth oder LDAP konfiguriert	`TINYAUTH_AUTH_USERS` oder einen Provider setzen
`failed to load users: invalid user format`	Eintrag ohne Hash oder kaputt maskiert	Mit `user create` neu erzeugen, mit `user verify` prüfen
`failed to decode configuration from environment variables: field not found, node: user`	Tippfehler, hier `TINYAUTH_AUTH_USER` statt `USERS`	Variablennamen mit der Konfigurationsreferenz abgleichen
`Too many failed login attempts` (HTTP 429)	Drei Fehlversuche, Konto für 300 Sekunden gesperrt	Warten oder Tinyauth neu starten
`executable file not found in $PATH` beim Healthcheck	Befehl aus der Doku ohne Binary-Namen	`docker compose exec tinyauth tinyauth healthcheck`

Landet der Browser nach dem Login immer wieder auf der Anmeldeseite, liegen Tinyauth und Anwendung meist nicht unter derselben übergeordneten Domain, oder SECURECOOKIE=true trifft auf eine Verbindung ohne HTTPS. Die Developer-Tools des Browsers zeigen, für welche Domain das Cookie tinyauth-session-... gesetzt wurde.

Saubere Deinstallation

Achtung: Die folgenden Schritte löschen die Konfiguration mit allen Benutzer-Hashes, die Sitzungsdatenbank und die Zertifikate von Traefik unwiderruflich. Legen Sie vorher ein Backup an. Entfernen Sie außerdem zuerst die Anwendungen hinter Tinyauth oder sichern Sie sie anders ab, sonst stehen sie nach dem Umbau des Proxys ungeschützt im Netz.

# Container und Netzwerk entfernen
cd /opt/tinyauth
docker compose down -v --remove-orphans

# Images gezielt entfernen, kein pauschales Prune
docker rmi ghcr.io/tinyauthapp/tinyauth:v5.2.0 traefik/whoami:latest

# Verzeichnis löschen, Dateien gehören root
sudo rm -rf /opt/tinyauth

Testumfang

Getestet mit Tinyauth v5.2.0 hinter Traefik v3.6 (File-Provider, HTTP auf einem lokalen Port): Benutzererzeugung und Prüfung per CLI, Weiterleitung und 401 ohne Login, falsches Passwort, Anmeldesperre, Login mit Zugriff auf whoami samt Remote-Headern, Logout, Healthcheck, Sitzungen über Neustarts, Backup und Restore des Datenverzeichnisses sowie alle Fehlermeldungen der Tabelle. Nur aus der Doku übernommen: TLS mit Let's Encrypt und Secure-Cookie, TOTP, OAuth, OIDC, LDAP, Zugriffsregeln per Labels, die Anbindung an Nginx Proxy Manager, SWAG und Caddy sowie Updates zwischen Versionen.

Passende Anleitungen auf S-EDV

SSO mit Authentik oder Authelia und Traefik Forward-Auth: Der nächste Schritt, wenn Sie Rollen, Gruppen, WebAuthn und zentrale Benutzerverwaltung brauchen.
Traefik als Docker-Reverse-Proxy mit automatischem HTTPS: Grundlagen zu Entrypoints, Zertifikaten und Routern für das Setup in dieser Anleitung.
2FA und MFA richtig einführen: Wie Sie einen zweiten Faktor organisatorisch sauber im Unternehmen verankern.

Quellen

tinyauthapp/tinyauth auf GitHub: Quellcode, Lizenz AGPL-3.0, 8.291 Sterne laut GitHub-API, abgerufen am 27.09.2026.
Release v5.2.0: Release-Notes vom 07.09.2026.
Tinyauth Doku: Getting Started: Benutzererzeugung, Domainstruktur, Beispiel mit Traefik.
Tinyauth Doku: Konfigurationsreferenz: Alle Umgebungsvariablen mit Standardwerten.
Tinyauth Doku: About: Einsatzzweck und Abgrenzung zu Authentik, Authelia und Keycloak.
Tinyauth Doku: Telemetry: Umfang und Abschaltung des Heartbeats.
Traefik Doku: ForwardAuth: Funktionsweise der Middleware und authResponseHeaders.