Ohne Lock-Datei darf jede Installation andere Fassungen ziehen: "^4.21.2" erlaubt alles unter 5.0. Auf dem Server laeuft deshalb express 4.22.2, waehrend in der package.json 4.21.2 steht -- geprueft wird also nie genau das, was ausgeliefert wird. Solche Unterschiede fallen nicht beim Deploy auf, sondern im Betrieb, und dann sucht man den Fehler im eigenen Code. WARUM SIE AUSGESCHLOSSEN WAR Ein "git pull" auf dem Server scheiterte daran: Git ueberschreibt keine unverfolgte Datei -- unabhaengig davon, ob ihr Inhalt derselbe ist. Der Ausschluss hat den Deploy repariert und dabei den Zweck der Datei beseitigt. Nachgemessen statt vermutet: Die Datei hier und die auf dem Server sind Byte fuer Byte identisch (SHA-256 a50b028d…). Es gab also nie einen inhaltlichen Konflikt, nur einen formalen. Er loest sich, indem die Datei einmal vom Server entfernt und danach aus dem Repo geholt wird. DEPLOY.md ergaenzt: auf dem Server "npm ci" statt "npm install". ci loescht node_modules vorher und baut streng nach der Lock-Datei; es schreibt sie nie um und bricht ab, wenn sie nicht zur package.json passt -- statt still etwas anderes zu installieren. server-internal/ folgt, sobald die dortige Lock-Datei vorliegt. Dieses Verzeichnis liegt unter /home/dogiintern mit Rechten 700. Co-Authored-By: Claude Opus 5 <[email protected]>
9.2 KiB
DOGFATHER UNIVERSE — Go-Live-Anleitung
⚠️ ZUERST LESEN: Die echte Seite läuft auf dem NETCUP-SERVER, nicht auf Cloudflare
Seit dem öffentlichen Start (21.08.2026) wird dogfather-universe.com vom eigenen
Netcup-Server ausgeliefert. Der alte Cloudflare-Worker existiert zwar noch und lässt sich
auch weiterhin deployen — er erreicht die echte Domain aber nicht mehr.
Das ist die gefährlichste Stelle im ganzen Projekt: npx wrangler deploy läuft ohne Fehler
durch und meldet „Deployed", die Änderung ist danach auf …workers.dev sichtbar — und auf
dogfather-universe.com passiert nichts. Genau so ist es am 22.08.2026 beim Sprachfenster-
Fix passiert (siehe unten). Wer nur die Erfolgsmeldung von Wrangler liest, meldet „ist live",
obwohl Filipe auf dem Handy weiterhin den kaputten Stand sieht.
| Adresse | Läuft wo | Wird von wo beliefert |
|---|---|---|
dogfather-universe.com ← die echte Seite |
Netcup, Caddy → localhost:4100, systemd-Dienst dogiweb.service, Verzeichnis /home/dogiweb/dogfather-universe/ |
Gitea git.dogfather-universe.com/DogFatherGit/dogfather-universe, Zweig main |
www.dogfather-universe.com |
dasselbe (Caddy nimmt beide Namen) | dasselbe |
dogfather-universe.dogfather1608.workers.dev |
Cloudflare Worker (Altbestand) | npx wrangler deploy |
Erkennungsmerkmal im Zweifel: curl -sI https://dogfather-universe.com/ | grep -i via
→ zeigt via: 1.1 Caddy, also Netcup. Käme die Seite von Cloudflare, stünde da kein Caddy.
So wird eine Änderung wirklich live (der einzige gültige Weg)
cd ~/Documents/Obelix/DogiHompage
# 1. Änderung committen
git add <dateien> && git commit
# 2. In die Ablage schieben (Gitea ist die Quelle der Wahrheit)
git push gitea master:main
# 3. Auf dem Server holen
ssh dogfather-server "cd /home/dogiweb/dogfather-universe && git pull --ff-only origin main"
Statische Dateien (HTML/CSS/JS/Bilder) sind damit sofort live — der Express-Dienst liefert das Verzeichnis direkt aus, ein Neustart ist dafür nicht nötig.
⚠️ ES GIBT ZWEI CHECKOUTS AUF DEM SERVER, NICHT EINEN
Am 22.08.2026 beim Ausrollen des Webdesign-Bereichs gefunden — diese Datei beschrieb vorher nur den ersten und war damit unvollständig:
| Dienst | Checkout | Liefert |
|---|---|---|
dogiweb.service (Port 4100) |
/home/dogiweb/dogfather-universe/ |
die öffentliche Website + server/ |
dogiintern.service (Port 4200) |
/home/dogiintern/dogfather-universe/ |
die API unter postfach.dogfather-universe.com + server-internal/ |
Ein git pull in /home/dogiweb ändert an server-internal/ also gar nichts.
Wer nur dort zieht und danach dogiintern.service neu startet, startet den
Dienst mit unverändertem Code neu und wundert sich, warum nichts passiert.
claudian hat auf /home/dogiintern/ keinen Zugriff (weder lesend noch
über den begrenzten sudo). Änderungen an server-internal/ muss deshalb
Filipe selbst ausrollen:
sudo -u dogiintern git -C /home/dogiintern/dogfather-universe pull --ff-only origin main
sudo systemctl restart dogiintern.service
Server-Code geändert? Dann ist ein Neustart PFLICHT
Statische Dateien sind nach dem Pull sofort live. Server-Code nicht — der läuft weiter mit dem alten Stand, bis der Dienst neu startet.
ssh dogfather-server "sudo systemctl restart dogiweb.service" # nach Änderungen in server/
ssh dogfather-server "sudo systemctl restart dogiintern.service" # nach Änderungen in server-internal/
Warum das hier besonders steht (Vorfall 22.08.2026): Nach dem Pull des
Webdesign-Bereichs war /webdesign/ für einige Minuten ohne Zugangsschutz
öffentlich erreichbar (HTTP 200 statt der Umleitung zur Zugangswand). Die
HTML-Dateien waren durch den Pull sofort da — die Schranke in
server/webdesign-gate.js lief aber erst nach dem Neustart von
dogiweb.service. Bei einem Bereich, der ausdrücklich nicht öffentlich sein
soll, ist genau dieses Zeitfenster der gefährliche Teil eines Deploys.
Merksatz: Erst neu starten, dann „ist live" melden — und danach mit
curl -I prüfen, dass die Schranke wirklich greift:
curl -sI https://dogfather-universe.com/webdesign/ | grep -iE "^location|x-robots-tag"
# erwartet: location: /webdesign/zugang.html?next=... und x-robots-tag: noindex, ...
Achtung bei Zweig-Namen: lokal heißt der Zweig master, auf dem Server und in Gitea main.
Deshalb master:main beim Push. Ein blankes git push schiebt sonst nach gitea/master —
einen alten, abgehängten Zweig, den niemand ausliefert.
Abhängigkeiten: npm ci, nicht npm install
Seit dem 26.08.2026 ist package-lock.json versioniert. Auf dem Server gilt
deshalb:
npm ci # richtig: installiert exakt das, was in der Lock-Datei steht
npm install # falsch: darf neuere Fassungen ziehen und schreibt die Datei um
Warum der Unterschied zählt. In package.json steht "express": "^4.21.2" —
das erlaubt alles unter 5.0. Vor dieser Umstellung lief auf dem Server deshalb
express 4.22.2, während hier 4.21.2 stand. Geprüft wurde also nie ganz das,
was ausgeliefert wurde. Solche Unterschiede fallen nicht beim Deploy auf,
sondern im Betrieb — und dann sucht man den Fehler im eigenen Code.
npm ci löscht node_modules vorher vollständig und baut streng nach der
Lock-Datei neu auf. Es schreibt sie nie um; passt sie nicht zur package.json,
bricht es ab, statt still etwas anderes zu installieren.
Die Lock-Datei war früher ausgeschlossen (.gitignore), weil ein git pull
daran scheiterte: Git überschreibt keine unverfolgte Datei, auch wenn ihr Inhalt
derselbe ist. Das war ein formaler Konflikt, kein inhaltlicher — nachgemessen
waren beide Fassungen Byte für Byte identisch. Wenn dieser Fall irgendwo erneut
auftritt, ist die Lösung, die Datei auf dem Server einmal zu entfernen und
danach aus dem Repo zu holen:
ssh dogfather-server "rm -f /home/dogiweb/dogfather-universe/server/package-lock.json"
ssh dogfather-server "cd /home/dogiweb/dogfather-universe && git pull --ff-only origin main"
Pflicht-Prüfung nach JEDEM Deploy
Nicht auf die Erfolgsmeldung des Deploy-Befehls verlassen, sondern die echte Domain fragen:
# Kommt meine Änderung wirklich auf der Seite an, die Filipe benutzt?
curl -s https://dogfather-universe.com/assets/css/main.css | grep "<mein Merkmal>"
Erst wenn das anschlägt, gilt eine Änderung als erledigt. Bei optischen Änderungen zusätzlich mit einem echten Browser im Handy-Format nachsehen (Playwright, Viewport 390×844) und einen Screenshot machen — Text im Quelltext beweist noch nicht, dass es auch richtig aussieht.
Der Cloudflare-Worker (Altbestand)
Bleibt vorerst bestehen, liefert aber nur noch …workers.dev aus. Ein Deploy dorthin ändert
an der echten Seite nichts. Der Versuch, die Domain per wrangler wieder anzubinden, schlägt
bewusst fehl:
Hostname 'dogfather-universe.com' already has externally managed DNS records
Das ist kein Fehler, den man beheben sollte — es ist die Schutzwirkung davon, dass die
Domain jetzt auf Netcup zeigt. routes mit custom_domain = true steht deshalb nur noch aus
historischen Gründen in wrangler.toml.
Der Bewerbungs-Postfach-Worker ist davon unabhängig und läuft weiter auf Cloudflare:
https://dogfather-universe-postfach.dogfather1608.workers.dev (API_BASE_URL in
assets/js/forms.js, index.html, postfach.html).
Git-Ablage
- Quelle der Wahrheit: Gitea,
git.dogfather-universe.com/DogFatherGit/dogfather-universe, Zweigmain(auf dem eigenen Server, kostenlos, in eigener Hand). - Lokal heißt das Fernziel
gitea, der Zweigmaster. - Auf dem Server heißt das Fernziel
origin, der Zweigmain. gitea/masterist ein alter, abgehängter Zweig (Stand44086b0) — nicht benutzen.- Sicherungszweig
server-stand-vor-abgleich-22-08-2026auf dem Server: der Stand, bevor die beiden Fassungen am 22.08.2026 zusammengeführt wurden. Kann irgendwann weg, kostet nichts.
Nie direkt auf dem Server Dateien bearbeiten, ohne sie danach in Gitea nachzutragen. Genau
dadurch waren am 22.08.2026 zwei Reparaturen (Autofokus in gate.html, abgeschnittene
Öffnen-Knöpfe in verwaltung.html) nur auf dem Server vorhanden und wären beim nächsten
Deploy vom Rechner aus überschrieben worden.
Offene Punkte
- Mehrere Hintergrundbilder liegen nur auf dem Server und auf Filipes Rechner, aber in
keiner Git-Ablage (
bg-bewerben-modi*.jpg,bg-bewerben-scout*.jpg,bg-links-seite*.jpg,bg-medien-casper*.jpg,bg-medien-hasidog*.jpg,bg-supporter*.jpg,bg-modis.jpg, Ordnerassets/img/stimmen-avatare/). Die Seitenbewerben-modi.html,links.html,medien-casper.html,supporter.htmlu.a. benutzen sie live. Geht der Server verloren, fehlen sie. Sie sind bewusst nicht in.gitignore— sie wurden schlicht nie hinzugefügt. - CORS im Postfach-Worker weiterhin offen (
"*"), siehe TODO incloudflare-worker/src/lib/http.js.
Alternative Hosting-Optionen (nur als Notfall-Plan)
Die Seite ist reines statisches HTML/CSS/JS und läuft überall — netlify.toml und .nojekyll
liegen bereit. Relevant nur, falls der Netcup-Server einmal ausfällt.