Um Ember selbst zu betreiben, brauchst du:

Das Installationsskript fragt die Handvoll Dinge ab, die sich zwischen Installationen unterscheiden, schreibt die Compose-Datei, startet alles und zeigt am Ende die Zugangsdaten des angelegten Administrators:

Wer lieber klickt als tippt, stellt die Installation vorher zusammen und nimmt nur einen kurzen Code mit auf den Server.

Ember besteht aus zwei Containern: dem Backend (Java API) und dem Frontend (Nuxt SSR). Der einfachste Weg ist Docker Compose. Das folgende Beispiel enthält Traefik-Labels für automatisches HTTPS:

Ersetze ember.example.com durch deine Domain. Der API-Router hat eine höhere Priorität, sodass /api-Anfragen ans Backend gehen und alles andere ans Frontend. Starte alles mit docker compose up -d. Beim ersten Start wird automatisch eine Konfigurationsdatei unter config/ erstellt und ein Admin-Konto mit zufälligem Passwort generiert (in der Konsole sichtbar).

Beim ersten Start legt Ember ein Konto an, das die Instanz verwaltet, und schreibt in die Konsole, womit du dich anmeldest: den Benutzernamen admin und ein zufälliges Passwort. Eine E-Mail-Adresse hat das Konto noch nicht, denn welche das sein soll, weißt nur du.

• Melde dich mit dem Benutzernamen und dem Passwort aus der Konsole an. Das Passwort gilt nur für diese eine Anmeldung, du wirst sofort nach einem neuen gefragt.
• Danach fragt Ember nach einer E-Mail-Adresse, unter der du wirklich erreichbar bist. Erst wenn sie hinterlegt ist, kommst du in die Anwendung.
• Richte anschließend den Mailversand ein, damit die Adresse auch etwas nützt: ohne Mailversand erreicht dich weder eine Passwortzurücksetzung noch eine Sicherheitsmeldung.

Rückfragen, die Ember sonst per E-Mail stellt, kann es dann nicht stellen. Statt auf eine Antwort zu warten, die nie kommen kann, führt Ember die Handlung sofort aus: ein neues Konto gilt als bestätigt, eine geänderte Adresse wird direkt übernommen, und eine Wache wird ohne Rückfrage gelöscht. Sobald ein Mailversand eingerichtet ist, wird wieder nachgefragt. Links zum Setzen eines Passworts sind davon nicht betroffen: sie übergeben ein Passwort, statt etwas zu bestätigen, und werden weiterhin nur per E-Mail verschickt.

Die vollständige Liste aller Einstellungen und Umgebungsvariablen ist auf einer eigenen Seite zusammengefasst:

Das data/ Verzeichnis im Container (im Beispiel oben auf ./data des Hosts gemappt) enthält alle Dateien, die nicht in der Datenbank gespeichert werden:

• data/documents/ - Rechtliche Dokumente (Datenschutz, Einwilligung, Nutzungsbedingungen, Impressum) als Markdown. Werden beim ersten Start aus dem Container kopiert und können auf dem Host mit einem Editor bearbeitet werden.
• data/station/<id>/ - Alle Wachen-Dateien - Seiten-Anhänge, Wiki-Dateien, Board-Anhänge, Fundsachen-Bilder, Quiz-Bilder, Wiki-Icons und -Bilder. Eine Wache pro Unterordner.
• data/account/<id>/ - Konto-bezogene Dateien - derzeit nur Profilbilder. Pro Konto ein Unterordner.
• data/inst/ - Instanz-weite Dateien - Logo-Fragmente und ähnliche Branding-Bilder.
• data/discovery/ - Schlüsselpaar für die Föderation. Geht der private Schlüssel verloren, müssen alle Partner-Wachen die Verbindung neu aufbauen.
• data/maps/ - Karten-Tile-Cache. Reine Caches, dürfen verloren gehen - werden bei Bedarf neu geladen.

Beim ersten Start werden Vorlagen für die rechtlichen Dokumente automatisch aus dem Container kopiert, wenn sie noch nicht vorhanden sind.

Wache-Inhalte können wahlweise auf einem entfernten Speicher (S3, SMB, SFTP) liegen statt auf der lokalen Festplatte. Dann sind die Dateien dort und nicht im data/ Verzeichnis. Die Einstellung erfolgt entweder über die Admin-Oberfläche (Instanz-Standard) oder pro Wache durch deren Verwalter.

Ember läuft standardmäßig auf Port 8080. Für den Produktivbetrieb solltest du einen Reverse Proxy davor schalten:

• Nginx, Caddy oder Traefik als Reverse Proxy verwenden.
• HTTPS mit SSL-Zertifikat (z.B. Let's Encrypt) einrichten.
• WebSocket-Verbindungen durchleiten (für Echtzeit-Updates).

Ember wird als Docker-Image bereitgestellt. Zum Aktualisieren:

Ziehe das neueste Image mit docker compose pull und starte neu mit docker compose up -d. Datenbank-Migrationen laufen automatisch beim Start.

Sichere regelmäßig die folgenden Bereiche. Ein vollständiges Backup besteht aus allen vieren - fehlt einer, kann der Stand nach einem Crash nicht wiederhergestellt werden.

• Datenbank: Die PostgreSQL-Datenbank, am einfachsten mit pg_dump (oder einem Volumen-Snapshot des pgdata-Volumens, wenn der Container gestoppt ist). Enthält Konten, Mitglieder, Termine, Anwesenheit, Inventar - der Großteil der Anwendungsdaten.
• Konfigurations-Ordner: Der auf den Container gemappte config/ Ordner. Enthält die config.yml mit allen Einstellungen sowie verschlüsselte Anmeldedaten für ausgelagerten Speicher (S3, SMB, SFTP), falls die Admin-Oberfläche zum Setzen verwendet wurde.
• Daten-Ordner: Der auf den Container gemappte data/ Ordner. Enthält alles aus dem Datenverzeichnis oben - rechtliche Dokumente, hochgeladene Dateien (sofern lokal gespeichert), den Föderations-Schlüssel und Logo-Fragmente. Wenn Wache-Dateien auf S3/SMB/SFTP liegen, brauchst du zusätzlich ein Backup beim jeweiligen Anbieter.
• Geheime Umgebungsvariablen: STORAGE_CREDENTIALENCRYPTIONKEY und AUTH_TOKENPEPPER an einem sicheren Ort außerhalb des Servers (z.B. Passwort-Manager). Geht der Verschlüsselungsschlüssel verloren, sind alle in der Datenbank gespeicherten Speicher-Anmeldedaten nicht mehr lesbar; ohne den Token-Pepper sind alle bestehenden Anmelde-Sitzungen ungültig.

Hinweis: Wenn Wache-Dateien auf einem entfernten Speicher (S3, SMB, SFTP) liegen, sind sie nicht im data/ Ordner. Sorge dafür, dass der Anbieter dort sein eigenes Backup hat oder erstelle es selbst.