#Domain & Deployment Concept

Status: ratifiziert am 2026-06-04 per Operator-Direktive. Dies ist die einzige maschinen- und agentenlesbare Quelle der Wahrheit, die für jeden Agenten eine Frage beantwortet: "Ich habe einen neuen Service / ein neues Tool / eine neue Seite — WO lege ich das an?"

Zwei Dinge waren vorher unklar und werden hier festgezurrt:

1. Die alte Server-Regel vermischte die generische Entscheidungslogik mit unserer konkreten Host-Liste. Beides ist jetzt strikt getrennt: Die Logik ist universell (sie funktioniert für jeden, sogar mit einem einzigen Server); unsere Host-Liste ist nur Config — eine Instanziierung der Logik.
2. Eine zweite Achse fehlte: welche DOMAIN (TLD) ein Service gehört.

Eine Platzierungs-Entscheidung hat DREI unabhängige Dimensionen. Entscheide jede einzeln:

Die Dimensionen sind orthogonal: Ein Service hat eine TLD und eine Umgebung. Maschinenlesbarer Spiegel aller drei: /etc/bbe/policy.yaml (domain_placement, deployment_targets.decision_order, server_map).

#Dimension 1 — Domain-Platzierung (welche TLD)

Eine Frage entscheidet:

Greift ein Dritter darauf zu? JA → .cloud (zabazingo.cloud). NEIN — nur intern / Dokumentation / Marken-Kollektion → .eu (zabazingo.eu).

#.cloud = zabazingo.cloud — ÖFFENTLICH / DRITTE

Alles, in das Nutzer, Kunden oder Dritte sich einloggen oder das sie verwenden. Produkte und Services, die nach außen exponiert sind.

Beispiele (nicht abschließend): mail, secrets, cloud, storage, vault, keychain, login, app. → mail.zabazingo.cloud, secrets.zabazingo.cloud, cloud.zabazingo.cloud, storage.zabazingo.cloud, vault.zabazingo.cloud, keychain.zabazingo.cloud, login.zabazingo.cloud, app.zabazingo.cloud.

#.eu = zabazingo.eu — INTERN + DOKUMENTATION + MARKE / KOLLEKTIONEN

Nur-interne Tools, die Dokumentationsseite und die Marken- / Kollektions-Seiten. Nicht für Login / Nutzung durch Dritte gedacht.

• Dokumentation (gebaut im Stil von claude.adam---eve.com, aber in ZABAZINGO CI) lebt hier: docs.zabazingo.eu.
• Marke / Kollektionen: collection.zabazingo.eu, collections.zabazingo.eu.
• Interne Tools: jede Admin- / Ops- / agenten-interne Oberfläche.

Beispiele (nicht abschließend): docs, collection, collections, plus alle internen / Admin- / Ops-Werkzeuge → .eu.

#Entscheidungsbaum (Dimension 1)

neuer Service
  └─ Loggt sich ein Dritter (Nutzer/Kunde/extern) ein oder nutzt es?
        ├─ JA → .cloud   (mail, secrets, cloud, storage, vault, keychain, login, app …)
        └─ NEIN → ist es Doku / Marken-Kollektion / nur-intern?
                    └─ JA → .eu   (docs, collection(s), interne/Admin-Tools)

#Dimension 2 — Additivität (.cloud kommt hinzu, .eu bleibt)

Einen Service auf .cloud zu bringen ist ADDITIV, niemals ein Verschieben-mit-Löschen.

• TU: Stelle die .cloud-Instanz zusätzlich auf. Verifiziere sie. Betreibe sie.
• Die .eu-Instanz bleibt vollständig unangetastet und läuft weiter.
• NIEMALS die .eu-Instanz löschen, deaktivieren oder umbiegen, um .cloud bereitzustellen. Zu keinem Moment verliert das Estate die .eu-Oberfläche.
• .eu-Stilllegung ist eine SEPARATE Entscheidung — explizit, pro Service und Operator-gated. Sie wird nie in den .cloud-Rollout gebündelt, nie autonom.

Invariante: .cloud hinzufügen darf .eu nicht entfernen. Wenn eine Aufgabe sagt "verschiebe X auf .cloud", lies das als "stelle X auch auf .cloud bereit; lass .eu laufen".

#Dimension 3 — Server- / Umgebungs-Platzierung (GENERISCH)

Dies ist die universelle Logik. Sie verwendet nur abstrakte Rollen — STAGING, LIVE (Produktion), BACKUP — und funktioniert für jeden mit 1..N Servern. Sie macht keine Annahme, dass zwei getrennte Hosts existieren. (Unsere konkreten Hosts stehen im Config-Abschnitt weiter unten — das ist nicht Teil dieser Regel.)

#Generische Entscheidungs-Reihenfolge (von oben nach unten, erster Treffer gewinnt)

1. STAGING existiert? (dedizierter Host ODER Staging-Zone)
      → BAUE + VERIFIZIERE dort ZUERST. Immer. Nie überspringen.

2. SEPARATE LIVE/Produktions-Umgebung existiert? (und Staging verifiziert)
      → PROMOTE staging → live. owner/operator-gated.

3. NUR EIN Server (kein separates staging/live)?
      → läuft auf diesem EINEN Server. Staging und Live KOLLABIEREN darauf:
        nutze eine Staging-Subdomain / Pfad / Pre-Prod-Vhost auf demselben Host,
        verifiziere, DANN flippe auf den Prod-Vhost auf demselben Host.

4. BACKUP-Ziel existiert?  [IMMER — nicht erster-Treffer]
      → IMMER off-site restic-Backup einrichten UND Stateful-Daten auf eine
        DEDIZIERTE Daten-Partition/Volume legen, getrennt vom OS-Volume.

#Invariante (Dimension 3)

Kein Stateful-Service ohne Backup + dedizierte Daten-Partition, wo immer ein Backup-Ziel existiert. Daten dürfen nie auf genau einer Maschine leben (no_single_copy). Stateful-Daten sitzen nie auf dem OS-Root-Volume.

#CONFIG (nicht die Regel) — UNSERE konkrete SERVER-MAP

Diese Tabelle ist unsere Instanziierung von Dimension 3. Sie ist Konfiguration, nicht die Logik. Ein anderes Estate füllt sie anders; die Regel oben bleibt unverändert. Maschinenlesbarer Spiegel: /etc/bbe/policy.yaml → server_map.

Wendet man die generische Logik mit dieser Map an: Neues öffentliches Web wird zuerst auf bbe-demo (178) gebaut, auf bbe-live (91.99.99.252) promotet unter einem Operator-Gate, auf die Storage Box gesichert, während 159 kein neues öffentliches Web trägt und der 73er nur Rollback/Legacy ist (migrieren-weg, nie neues Main).

#Zusammengesetzt — vollständige Platzierung in 3 Fragen

Für jeden neuen Service, der Reihe nach beantworten:

1. TLD: Zugriff durch Dritte? → .cloud. intern/Doku/Kollektion? → .eu.
2. Additiv: Wenn .eu das schon bedient, .cloud hinzufügen, .eu oben lassen. (.eu-Stilllegung = später, separat, Operator-gated.)
3. Umgebung: STAGING zuerst → promote zu LIVE (gated) → (oder Kollaps auf den einzelnen Server) → immer Backup + Daten-Partition. Unsere Map: STAGING=bbe-demo/178, LIVE=bbe-live/91.99.99.252, BACKUP=Storage Box.

#Querverweise

• Staging→Live-Promotion-Flow + Hostname-Konventionen: staging-policy.md
• Maschinenlesbare Policy: /etc/bbe/policy.yaml
• Server-Inventar + Zugang: inventory.md und Kapitel Server- & Infra-Übersicht
• No-data-loss-Migrationsschritte: migration-protocol.md
• Backup-Einrichtung: backup.md
• DNS (Infomaniak, beide TLDs): infomaniak.md