Neues DEPLOYMENT.md: Voraussetzungen, Repository holen, .env.local konfigurieren, docker compose up --build, Admin-Zugangsdaten aus ZUGANGSDATEN.md abholen, Reverse-Proxy/HTTPS (Caddy-Beispiel), Updates, Backup der Docker-Volumes. Aus README.md verlinkt. .env.example: LOCAL_PG_PASSWORD war bisher nirgends dokumentiert, obwohl docker-compose.yml die DATABASE_URL des App-Containers daraus zusammenbaut (die dortige DATABASE_URL-Zeile wird beim Docker-Compose-Betrieb ignoriert) – beim Schreiben der Anleitung aufgefallen und ergänzt. README.md: RSS-Feed und Vorschläge-Badge in der Funktionstabelle ergänzt.
5.4 KiB
Deployment auf einem neuen Server
Schritt-für-Schritt-Anleitung, um Canteen Menu auf einem frischen (Linux-)Server produktiv zu betreiben. Die App läuft vollständig selbst gehostet (PostgreSQL + eigene Auth), einzige optionale externe Abhängigkeit ist DeepL für automatische Übersetzungen.
Voraussetzungen
- Ein Server (VM oder Root-Server) mit Docker und Docker Compose v2
(
docker compose versionsollte funktionieren; auf den meisten aktuellen Distributionen perapt install docker.io docker-compose-v2bzw. dem offiziellen Docker-Install-Skript installierbar). - Eine Domain, deren DNS-A/AAAA-Eintrag auf die Server-IP zeigt (z. B.
menu.example.de). Ohne eigene Domain funktioniert die App auch unter der reinen Server-IP, dann aber ohne gültiges HTTPS-Zertifikat und ohne funktionierende Passkeys (siehe unten). - Mindestens 1 GB RAM frei (App + PostgreSQL sind genügsam, für ~250 Mitarbeiter reicht die kleinste übliche VM-Größe).
1. Repository auf den Server holen
git clone https://github.com/<dein-fork-oder-repo>/canteen-menu.git
cd canteen-menu
(Oder per git pull/scp, falls kein direkter Git-Zugriff vom Server
aus gewünscht ist.)
2. Konfiguration anlegen
cp .env.example .env.local
.env.local mit einem Editor öffnen und ausfüllen:
| Variable | Was rein muss |
|---|---|
LOCAL_PG_PASSWORD |
Ein neues, zufälliges Passwort (z. B. openssl rand -base64 24) – wird beim ersten Start zum Datenbank-Passwort des mitgelieferten PostgreSQL-Containers |
APP_URL |
Die öffentliche URL mit Schema, z. B. https://menu.example.de (auch wenn HTTPS erst in Schritt 5 eingerichtet wird – schon jetzt korrekt eintragen, da daraus u. a. die Passkey-Domain abgeleitet wird) |
SITE_TITLE |
Optional, Titel im Browser-Tab/Überschrift ohne Logo |
ADMIN_EMAIL |
Optional, E-Mail des automatisch angelegten Admin-Erstnutzers. Ohne Angabe: admin@<Hostname aus APP_URL> |
DEEPL_API_KEY |
Optional, nur für automatische Übersetzung |
DATABASE_URL in .env.local nicht anpassen – die wird nur für
den Betrieb ohne Docker gebraucht (siehe README) und beim
Docker-Compose-Start ignoriert.
Zusätzlich eine leere Datei für die automatisch generierten Admin-Zugangsdaten anlegen, da sie per Bind-Mount in den Container eingebunden wird:
touch ZUGANGSDATEN.md
3. App starten
docker compose --env-file .env.local up -d --build
Das baut das Docker-Image, startet PostgreSQL und die App, wendet beim ersten Start automatisch das Datenbankschema an und legt – da die Datenbank leer ist – einen einzigen Admin-Benutzer mit zufällig generiertem Passwort an.
Kurz prüfen, ob beides läuft:
docker compose ps
docker compose logs app --tail 30
In den Logs sollte u. a. bootstrap-admin – Admin angelegt: ...
stehen.
4. Admin-Zugangsdaten abholen
cat ZUGANGSDATEN.md
Enthält E-Mail-Adresse und Passwort des automatisch angelegten Admin-Kontos. Direkt nach dem ersten Login unter „Mein Konto“ das Passwort ändern und optional einen Passkey registrieren.
Die App ist jetzt unter http://<server-ip>:3000 erreichbar – für den
produktiven Betrieb fehlt noch HTTPS/die Domain (nächster Schritt).
5. Reverse-Proxy + HTTPS einrichten
Die App selbst spricht nur HTTP auf Port 3000; TLS/HTTPS übernimmt ein Reverse-Proxy davor. Am einfachsten mit Caddy (automatisches Let’s-Encrypt-Zertifikat, keine manuelle Zertifikats- verwaltung nötig):
sudo apt install caddy # oder: siehe caddyserver.com/docs/install
/etc/caddy/Caddyfile:
menu.example.de {
reverse_proxy localhost:3000
}
sudo systemctl reload caddy
Caddy holt beim ersten Aufruf automatisch ein Zertifikat und leitet
danach HTTP→HTTPS um. Alternative: nginx + certbot, falls bereits ein
nginx-Setup existiert (Standard-proxy_pass-Konfiguration auf
http://127.0.0.1:3000, Zertifikat separat per certbot --nginx).
Danach in .env.local sicherstellen, dass APP_URL=https://menu.example.de
gesetzt ist (Schema https, keine Portangabe), und die App neu
starten, falls diese Variable nach Schritt 2 noch geändert wurde:
docker compose --env-file .env.local up -d
6. Danach
- Passkeys funktionieren erst mit korrekt gesetzter
APP_URL(RP-Domain wird direkt daraus abgeleitet) und über HTTPS (Passkeys verlangen eine sichere Origin,localhostausgenommen). - Weitere Kantinenmitarbeiter/Admins unter „Benutzer“ (nur als Admin sichtbar) anlegen.
- Essenszeiten, Gerichte, Allergene/Zusatzstoffe sind zu Beginn leer und werden im Kantinen-Bereich gepflegt.
- Logo/Favicon/Farben unter „Design“ (nur Admin) anpassen.
Updates einspielen
git pull
docker compose --env-file .env.local up -d --build
Neue Datenbank-Migrationen (db/migrations/*.sql) werden beim Start
automatisch und idempotent angewendet, bestehende Daten bleiben
erhalten.
Backup
Zwei Docker-Volumes enthalten alle persistenten Daten:
canteen-menu_pgdata– die komplette PostgreSQL-Datenbankcanteen-menu_branding_data– hochgeladenes Logo/Favicon
docker run --rm -v canteen-menu_pgdata:/data -v "$PWD":/backup alpine \
tar czf /backup/pgdata-backup.tar.gz -C /data .
Für ein reines Datenbank-Backup eignet sich auch docker compose exec db pg_dump -U postgres canteen_menu > backup.sql.