# Bunny.net – Ersteinrichtung und Vorab-Veröffentlichung

Ziel: `iwz-ferienwohnungen` bei Bunny.net anlegen, eine erste Fassung der Hugo-Seite
online stellen und den Zugriff darauf auf dich + den Kunden beschränken (Vorschau,
bevor die Seite öffentlich unter der echten Domain läuft).

> Hinweis: Dieser Weg ersetzt den früher geplanten Cloudflare-Pages-Ansatz.
> Details zum alten Cloudflare/IONOS-Plan siehe weiter unten im Abschnitt
> "Alt: Cloudflare-Variante (nicht mehr aktuell)".

## 1. Bunny.net-Account anlegen

1. Auf [bunny.net](https://bunny.net) registrieren (E-Mail + Passwort, keine
   Kreditkarte für den Start nötig, Abrechnung erfolgt nach Traffic/Storage).
2. E-Mail-Adresse bestätigen und einloggen ins Dashboard.

## 2. Storage Zone anlegen (Ablage für die gebauten Hugo-Dateien)

1. Im Dashboard-Menü **Storage** → **Add Storage Zone**.
2. Name vergeben, z. B. `iwz-ferienwohnungen`.
3. **Main Region**: Region wählen, die am nächsten an euch/den Besuchern liegt
   (z. B. Frankfurt/Falkenstein, Europa).
4. Replikations-Regionen optional dazuwählen, falls später Besucher aus anderen
   Kontinenten erwartet werden (für die Vorschau-Phase nicht nötig).
5. Zone erstellen.

## 3. Zugangsdaten der Storage Zone notieren

1. Storage Zone öffnen → Reiter **FTP & API Access**.
2. **Hostname**, **Username** und **Password** (nicht das Read-only-Passwort!)
   notieren – diese werden später für den Upload per `deploy.bat`/`deploy.py`
   gebraucht (als `BUNNY_STORAGE_ZONE` und `BUNNY_API_KEY`, siehe CLAUDE.md).
3. Zugangsdaten **nicht** ins Git-Repo einchecken (z. B. in `.env` oder als
   Windows-Umgebungsvariable ablegen).

## 4. Erste Fassung hochladen

Lokal die Seite bauen und die `public/`-Inhalte in die Storage Zone hochladen:

```powershell
hugo --gc --minify
```

Für den allerersten Test kann der Upload manuell per **File Manager** im Bunny-
Dashboard (Storage Zone → Files → Drag & Drop von `public/`) erfolgen. Sobald
`deploy.bat`/`deploy.py` entsprechend erweitert ist, übernimmt das Skript diesen
Schritt automatisch (Ordnerinhalt von `public/` 1:1 in die Storage Zone spiegeln).

## 5. Pull Zone anlegen (macht die Storage Zone über HTTPS erreichbar)

1. In der Storage Zone → **Connected Pull Zones** → **Connect Pull Zone**
   (oder im Menü **CDN → Add Pull Zone** und als Origin die Storage Zone wählen).
2. Namen vergeben, z. B. `iwz-ferienwohnungen`.
3. Zonen für die Auslieferung wählen (Europa reicht für die Vorschau).
4. Pull Zone erstellen → Bunny vergibt automatisch eine Test-URL:
   `https://iwz-ferienwohnungen.b-cdn.net`
5. HTTPS ist auf dieser `b-cdn.net`-URL automatisch aktiv, kein eigenes
   Zertifikat nötig.

Damit ist die Seite technisch live – als nächstes wird sie geschützt, bevor der
Link an den Kunden geht.

## 6. Zugriff beschränken: nur du + der Kunde

Bunny.net Pull Zones bieten dafür **Token Authentication**: Requests an die
Pull Zone werden nur ausgeliefert, wenn die URL einen gültigen, signierten Token
enthält. Es gibt keinen klassischen Basic-Auth-Login-Dialog im Browser –
stattdessen bekommt der Kunde einen fertigen Link mit Token, der bis zu einem
festgelegten Ablaufzeitpunkt gültig ist.

### 6.1 Token Authentication aktivieren

1. Pull Zone öffnen → Reiter **Security**.
2. **Token Authentication** aktivieren.
3. Den angezeigten **Authentication Key** kopieren und sicher aufbewahren
   (nicht ins Git-Repo, nicht per unverschlüsselter Mail verschicken) – wer
   diesen Key kennt, kann selbst gültige Links erzeugen.

Ab jetzt liefert die Pull Zone **nichts mehr aus**, ohne gültigen Token in der
URL – das ist der eigentliche Zugriffsschutz.

### 6.2 Signierten Link erzeugen

Ein signierter Link besteht aus einem Hash über `Authentication Key + Pfad +
Ablaufzeitpunkt`. Das lässt sich einfach per kleinem Python-Snippet erzeugen,
z. B. lokal ausführen, wenn ein neuer Vorschau-Link für den Kunden gebraucht
wird:

```python
import hashlib
import base64
import time

security_key = "DEIN_AUTHENTICATION_KEY"
url_path = "/index.html"          # z.B. Startseite, oder "/" je nach Setup
expires = int(time.time()) + 7 * 24 * 60 * 60  # 7 Tage gültig

hashable = f"{security_key}{url_path}{expires}"
token_hash = hashlib.sha256(hashable.encode()).digest()
token = base64.urlsafe_b64encode(token_hash).decode().rstrip("=")

print(f"https://iwz-ferienwohnungen.b-cdn.net{url_path}?token={token}&expires={expires}")
```

Den ausgegebenen Link schickst du dem Kunden. Läuft die Gültigkeit ab, einfach
ein neues Snippet mit neuem `expires`-Wert ausführen und den frischen Link
verschicken.

### 6.3 Praktisch für Vorschau-Zwecke

- Länge der Gültigkeit (`expires`) nach Bedarf wählen – z. B. 7 Tage für eine
  kurze Abstimmungsrunde, oder wenige Stunden für einen einzelnen Termin.
- Ohne gültigen Token bekommt jeder andere Besucher einen Fehler von Bunny –
  die Seite ist damit faktisch nur über den geteilten Link erreichbar.
- Sobald die Seite live gehen soll (echte Domain, öffentlich), wird Token
  Authentication in der Pull Zone einfach wieder deaktiviert.

## 7. Domain-Anbindung (später, für den echten Umzug)

Noch offen und erst relevant, wenn die Seite final ist:

- Eigene Domain (`iwz-ferienwohnungen.de`) als Custom Hostname in der Pull Zone
  hinterlegen.
- Entweder DNS bei IONOS per CNAME auf die Bunny-Pull-Zone zeigen lassen, oder
  DNS komplett zu Bunny.net DNS umziehen (Nameserver-Wechsel bei IONOS,
  ähnlich wie ursprünglich für Cloudflare geplant).
- SSL-Zertifikat für die eigene Domain wird von Bunny automatisch ausgestellt,
  sobald der Hostname verifiziert ist.
- Domain-Registrar bleibt in jedem Fall IONOS.

## Zusammenfassung des Stacks (aktuell)

```
Domain-Registrar:  IONOS (bleibt so)
DNS:               noch offen (IONOS bleibt vorerst / später ggf. Bunny.net DNS)
Hosting:           Bunny.net (Storage Zone + Pull Zone/CDN)
Vorschau-Schutz:    Bunny Token Authentication (signierte, befristete Links)
Code/Content:       Gitea (eigene Instanz, kein CI/CD-Workflow)
Deploy:            manuell per deploy.bat / deploy.py (hugo build + Upload zur Storage Zone)
Buchungskalender:  webplanner.de (bleibt so, extern)
```

---

# Alt: Cloudflare-Variante (nicht mehr aktuell)

Der folgende Abschnitt beschreibt den ursprünglich geplanten Umzug auf
Cloudflare Pages und wird nicht mehr weiterverfolgt (Entscheidung: Umstieg auf
Bunny.net, siehe oben). Als Referenz stehen gelassen.

## SSL/HTTPS auf Cloudflare Pages

Ja, vollautomatisch. Es gibt keine Tokens oder Zertifikate, die du selbst beantragen oder verlängern musst. Das läuft komplett im Hintergrund über Let's Encrypt, gesteuert von Cloudflare. Du siehst davon nichts.

## DNS und IP-Adresse — das ist der entscheidende Teil

Hier gibt es zwei verschiedene Szenarien:

### Szenario A: Domain bei einem anderen Registrar (z.B. IONOS, Strato, Hetzner)

Du hast zwei Möglichkeiten:

#### Option 1 — Nameserver umziehen (empfohlen):
Beim Registrar trägst du statt dessen Nameserver die Cloudflare-Nameserver ein:

aria.ns.cloudflare.com
bob.ns.cloudflare.com

Danach verwaltest du alle DNS-Einträge bei Cloudflare. Cloudflare kennt dann deine Domain vollständig und stellt automatisch ein SSL-Zertifikat aus. Keine IP-Adresse nötig — Cloudflare Pages bekommt einfach einen CNAME-Eintrag wie:

www → dein-projekt.pages.dev

#### Option 2 — Nur einen CNAME/A-Record setzen (ohne Nameserver-Wechsel):
Beim Registrar trägst du einen CNAME auf dein-projekt.pages.dev ein. Cloudflare Pages erkennt die Domain und stellt trotzdem ein Zertifikat aus — dauert aber etwas länger zur Verifizierung.

### Szenario B: Domain direkt bei Cloudflare registriert

Dann ist alles von Anfang an in einem Dashboard, kein Umzug nötig.

Konkret: So funktioniert die Weiterleitung

Es gibt keine neue feste IP-Adresse im klassischen Sinne. Cloudflare Pages arbeitet mit einem globalen CDN-Netzwerk — deine Seite liegt auf Hunderten von Servern weltweit. Der DNS-Eintrag zeigt auf einen Cloudflare-CNAME, Cloudflare liefert dann vom nächstgelegenen Rechenzentrum aus.

Der Besucher tippt www.iwz-ferienwohnungen.de → DNS löst auf Cloudflare-Server auf → Cloudflare liefert deine statische Seite aus → HTTPS ist dabei immer aktiv.

# Praktischer Ablauf beim Umzug
Cloudflare-Account anlegen (kostenlos)
Domain dort hinzufügen → Cloudflare scannt bestehende DNS-Einträge automatisch
Beim Registrar die Nameserver auf Cloudflare-Nameserver umstellen (einmalig, ~10 Minuten Aufwand)
Propagation: 1–24 Stunden, meist unter 1 Stunde
In Cloudflare Pages dein Hugo-Projekt verknüpfen (GitHub-Repo auswählen)
Eigene Domain in Pages eintragen → CNAME wird automatisch gesetzt → SSL-Zertifikat wird sofort ausgestellt

Danach läuft alles von selbst — das Zertifikat verlängert sich alle 90 Tage automatisch, du wirst nicht mal benachrichtigt.

# Wo ist die Domain iwz-ferienwohnungen.de aktuell registriert?

## Ablauf IONOS

Nameserver-Wechsel bei IONOS zu Cloudflare
### Schritt 1: Cloudflare-Account anlegen und Domain hinzufügen

Auf cloudflare.com kostenlos registrieren, dann „Add a Site" → iwz-ferienwohnungen.de eingeben. Cloudflare liest die bestehenden DNS-Einträge von IONOS automatisch aus und importiert sie. Du siehst danach eine Liste — meist sind alle wichtigen Einträge (MX für E-Mail, A-Record, etc.) schon korrekt übernommen.

### Schritt 2: Nameserver bei IONOS umstellen

Im IONOS-Kontrollzentrum:

Domains & SSL → Domain auswählen → Nameserver → "Nameserver ändern"

Dort trägst du die beiden Cloudflare-Nameserver ein, die dir Cloudflare anzeigt (die sind pro Account individuell, z.B. aria.ns.cloudflare.com und bob.ns.cloudflare.com).

Wichtig bei IONOS: IONOS fragt manchmal nach, ob du „externe Nameserver" verwenden willst und warnt, dass deren DNS-Verwaltung dann deaktiviert wird. Das ist korrekt und gewollt — ab dann läuft alles über Cloudflare.

### Schritt 3: Warten

Propagation dauert bei IONOS erfahrungsgemäß 30 Minuten bis 4 Stunden. Cloudflare schickt dir eine E-Mail sobald die Verifizierung erfolgreich war.

## Was mit IONOS bleibt

IONOS bleibt weiterhin dein Domain-Registrar — das ist wichtig zu verstehen. Du verlängerst die Domain weiterhin bei IONOS, zahlst dort die Jahresgebühr. Nur die DNS-Verwaltung und das SSL-Zertifikat wandern zu Cloudflare.

## E-Mail-Adressen — aufpassen!

Falls über IONOS auch E-Mail-Adressen laufen (z.B. info@iwz-ferienwohnungen.de), dann müssen die MX-Einträge beim Import in Cloudflare korrekt übernommen werden. Cloudflare importiert die normalerweise automatisch, aber das solltest du einmal kontrollieren bevor du den Nameserver-Wechsel machst. Die E-Mail funktioniert dann wie bisher — Cloudflare leitet den Mail-Verkehr nur weiter, hostet ihn nicht selbst.

# Zusammenfassung des gesamten Stacks (alt, Cloudflare)
Domain-Registrar:  IONOS (bleibt so)
DNS + SSL:         Cloudflare (kostenlos)
Hosting:           Cloudflare Pages (kostenlos)
Code/Content:      GitHub Repository (kostenlos)
Buchungskalender:  webplanner.de (bleibt so, extern)

Laufende Kosten danach: *nur noch die Domain-Verlängerung bei IONOS* (~10–15 € pro Jahr).