Zehn Artikel. Ein VPS, Debian, Docker, Tailscale, Komodo, Caddy, Mail-Relay, Authelia, CrowdSec. Kein einziger davon war eine App, die du täglich benutzt.

Das war Absicht. Was du aufgebaut hast, ist eine Plattform – ein Fundament, auf dem neue Apps in 15–30 Minuten laufen. Ohne jedes Mal den Reverse Proxy neu aufzusetzen, ohne HTTPS-Zertifikate per Hand, ohne Login-Schutz von Null zu konfigurieren. Das alles ist schon da.

Dieser Artikel zeigt einmal, wie die Bausteine zusammenspielen – bevor ab Artikel 12 die ersten echten Apps einziehen.

Am Ende hast du

  • Verstanden, warum die letzten zehn Artikel so aufgebaut waren
  • Das Muster hinter jeder App-Installation einmal komplett durchgespielt
  • whoami als Testapp über HTTPS und hinter Authelia erreichbar
  • Den Stack danach wieder aufgeräumt
  • Ein klares Bild davon, was dich in Artikel 12, 13, 14 … erwartet

1. Was die letzten zehn Artikel gebracht haben

Jetzt weißt du, wofür der ganze Aufwand war. Vaultwarden, Immich, Paperless – die Apps, die du eigentlich haben willst – brauchen alle dasselbe Drumherum: HTTPS, einen gesicherten Eingang, Login-Schutz, Mail-Versand, eine Verwaltung. Das hast du gebaut. Einmal. Und es steht jetzt für jede App bereit:

  • Artikel 02–03 – Server abgesichert, Docker läuft, Firewall steht
  • Artikel 04 – DNS eingerichtet, Subdomains lösen auf
  • Artikel 05–06 – Tailscale-VPN für den Admin-Zugang, Komodo zum Verwalten
  • Artikel 07 – Caddy vergibt HTTPS automatisch für jede neue Subdomain
  • Artikel 08 – Mail-Relay steht bereit, Apps können E-Mails verschicken
  • Artikel 09 – Authelia schützt mit Login und 2FA
  • Artikel 10 – CrowdSec erkennt und blockiert Angriffe

Ab jetzt installierst du nur noch die App selbst. Alles andere läuft im Hintergrund mit.

Konkretes Beispiel: Wenn du in Artikel 12 Vaultwarden installierst, beantragst du kein Zertifikat – Caddy macht das. Du richtest keinen Login ein – Authelia ist schon da. Du setzt keine Firewall-Regel – UFW ist konfiguriert. Du legst einen Stack an, ergänzt einen Caddyfile-Block, eine Authelia-Regel – fertig.

2. Die Entscheidungen vor jeder App

Bevor du eine App installierst, beantwortest du drei Fragen. Die Antworten bestimmen, was du tun musst.

Frage 1: Wie soll die App erreichbar sein?

Profil Bedeutung Beispiele
🔒 VPN-only Nur über Tailscale erreichbar Komodo, interne Tools
🔐 Public + Auth Öffentlich, aber hinter Authelia Vaultwarden, Immich, Paperless
🌐 Public Für jeden erreichbar Blog, öffentliche Dokumentation

Admin-Tools wie Komodo laufen VPN-only – die haben im öffentlichen Internet nichts verloren. Persönliche Apps wie Vaultwarden laufen Public + Auth – du willst von überall drankommen, aber nicht jeder soll rein. Ein Blog läuft Public.

Frage 2: Braucht die App einen Login davor (Authelia)?

Authelia ist der Kontrolleur an der Tür – er prüft, wer zur App durchkommt (→ Artikel 09).

  • 🔒 VPN-only → kein Authelia nötig, das VPN ist der Schutz
  • 🔐 Public + Auth → Authelia mit 2FA davor
  • 🌐 Public → kein Authelia

Eine Besonderheit gibt es bei Apps mit eigenen Handy-Clients (Vaultwarden, Immich): Dort darf Authelia nicht den ganzen Host blockieren, sonst brechen die Apps ab. Authelia sichert dann nur das Admin-Panel. Das erklärt der jeweilige App-Artikel an Ort und Stelle – für jetzt reicht: Authelia ja oder nein.

Frage 3: Braucht die App E-Mail?

Nicht jede App verschickt Mails. Viele können damit aber mehr:

App Ohne Mail Mit Mail
Vaultwarden kein Self-Service Passwort-Reset, Einladungen
Immich läuft vollständig –
Paperless-ngx läuft vollständig –

Der Mail-Relay läuft bereits (→ Artikel 08). Braucht eine App Mail, trägst du in ihrer .env mail-relay:2500 als SMTP-Host ein – die Variablennamen zeigt der App-Artikel.

3. Die Voraussetzungs-Box – das Ergebnis auf einen Blick

Die Antworten auf diese drei Fragen lassen sich als Bild zusammenfassen: Welche Fundament-Bausteine braucht diese App – und welche nicht? Genau diese Box steht ab Artikel 12 ganz oben in jedem App-Artikel. So lernst du sie hier einmal zu lesen.

Ein grüner Haken heißt „für diese App nötig", ein graues Kreuz „für diese App nicht nötig". Basis und Zugang sind immer grün – ohne Server, Docker und Komodo läuft keine App. Caddy, Mail und Authelia wechseln je nach den drei Fragen.

So sieht das für die nächste App aus, Vaultwarden (Artikel 12) – öffentlich erreichbar, mit Mail und Login:

Voraussetzungen für Vaultwarden Basis, Zugang, Caddy, Mail und Authelia sind nötig. 02–03 · Basis Server & Docker 05 + 06 · Zugang Tailscale VPN + Komodo 07 · Caddy HTTPS & Subdomain 08 · Mail Einladungs- & Reset-Mails 09 · Authelia 2FA vor dem Admin-Panel

Eine andere App sieht anders aus. Komodo läuft VPN-only – nur über Tailscale erreichbar, ohne Reverse Proxy, ohne Login davor. Hier sind drei Bausteine grau:

Voraussetzungen für Komodo (VPN-only) Nur Basis und Zugang nötig, Caddy, Mail und Authelia nicht. 02–03 · Basis Server & Docker 05 + 06 · Zugang Tailscale VPN + Komodo 07 · Caddy für diese App nicht nötig 08 · Mail für diese App nicht nötig 09 · Authelia für diese App nicht nötig

Du baust diese Box nie selbst – jeder App-Artikel bringt sie fertig mit. Was dir die Box spart: ein Blick, und du weißt, ob dein Fundament für diese App reicht oder ob noch ein Baustein fehlt.

Und CrowdSec? CrowdSec taucht in der Box nicht auf. Es überwacht alle Apps automatisch über die Caddy-Logs – du musst pro App nichts einrichten. Es ist eine Grundsatzentscheidung aus Artikel 10, keine, die pro App fällt. Dasselbe gilt für DNS und Firewall: einmal eingerichtet, danach unsichtbar.

4. Die vier Schritte – am Beispiel Vaultwarden

Egal welche App: Die Installation folgt immer denselben vier Schritten. Hier am Beispiel Vaultwarden, wie es in Artikel 12 konkret wird.

Schritt 1: Stack in Komodo anlegen

Jede App wird ein eigener Stack in Komodo – UI Defined, auf Server homelab. Im Compose-Tab kommt die compose.yaml, im .env-Tab die Secrets.

Drei Konventionen gelten dabei für jede App der Serie:

  • Verzeichnis: Jeder Stack lebt unter /srv/docker/stacks/<appname>/. Komodo legt Compose- und .env-Datei dort beim ersten Deploy ab.
  • Netzwerk: Alle Container hängen am externen Netzwerk homelab_net. So erreicht Caddy jede App per Service-Namen – ganz ohne ports: nach außen. Der einzige Container mit offenen Ports bleibt Caddy.
  • Secrets: Passwörter und Keys stehen in der .env (Tab in Komodo), nie direkt in der compose.yaml. Eingebunden werden sie per env_file: .env.

Apps mit Datenbank bekommen ihren eigenen PostgreSQL-Container im selben Stack – keine geteilte Datenbank über mehrere Apps. So bleibt jede App in sich abgeschlossen.

name: vaultwarden

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    env_file: .env
    volumes:
      - ./data:/data
    networks:
      - homelab_net

networks:
  homelab_net:
    external: true

Danach Poll for Updates: on, Auto Update: off, Deploy.

Schritt 2: Caddyfile ergänzen

Das Caddyfile liegt unter /srv/docker/stacks/caddy/Caddyfile. Bearbeiten per VS Codium (Remote-SSH, → Artikel 07) oder per SSH. Pro App kommt ein Block dazu:

vault.deine-domain.de {
    import public
    import auth
    reverse_proxy vaultwarden:80
}

import public bringt HTTPS, Komprimierung und Logging (definiert in Artikel 07), import auth schaltet Authelia davor (Artikel 09). Danach den Caddy-Stack in Komodo per Redeploy neu starten. (Wer im Terminal ist, kann auch docker exec caddy caddy reload --config /etc/caddy/Caddyfile nutzen.)

Bei VPN-only-Apps entfällt dieser Schritt komplett – ohne Caddyfile-Eintrag ist die App nur über Tailscale erreichbar.

Schritt 3: Authelia-Regel eintragen

Soll Authelia die App schützen, kommt eine Regel in access_control.rules (in der configuration.yml, → Artikel 09):

    - domain: vault.deine-domain.de
      policy: two_factor
      subject:
        - "group:admins"

two_factor verlangt Passwort + 2FA-Code, group:admins beschränkt den Zugang auf deinen Admin-Account aus Artikel 09. Authelia liest die Datei automatisch neu – kein Neustart nötig.

Schritt 4: Mail einbinden (falls nötig)

Verschickt die App Mails, kommt der Relay in die .env des App-Stacks:

SMTP_HOST=mail-relay
SMTP_PORT=2500

Die genauen Variablennamen unterscheiden sich pro App – der jeweilige Artikel zeigt sie. Braucht die App keine Mail, entfällt der Schritt.

5. Das war's – das ist der ganze Baukasten

Mehr ist es nicht. Drei Fragen, vier Schritte, immer dasselbe Muster. Was sich von App zu App ändert: das Image, die Subdomain, ob eine Datenbank dazukommt, ob Mail nötig ist. Was gleich bleibt: Verzeichnis, Netzwerk, .env-Prinzip, der Ablauf.

Ab Artikel 12 steht über jeder Installation die Voraussetzungs-Box, gefolgt von genau diesen Schritten. Du weißt jetzt, was sie bedeuten.

Und jetzt?

Genug Konzept – Zeit für die erste echte App. Was du zuerst baust, hängt davon ab, was dir am meisten fehlt:

  • Passwörter sicher verwalten → Artikel 12: Vaultwarden
  • Fotos vom Handy sichern → Artikel 13: Immich (Hinweis: Immich braucht viel Speicher – mehrere hundert Gigabyte sind schnell erreicht. Prüfe vorher deinen Platz; auf einem NAS ist Immich langfristig besser aufgehoben, die NAS-Serie greift das auf.)
  • Dokumente digitalisieren und durchsuchen → Artikel 14: Paperless-ngx

👉 Weiter: 12. Vaultwarden – Passwort-Manager