INTERNAL — confidential internal documentation. = highly confidential. DE
Foundation · 2 min read · 0.5k words

#Server- & Infra-Übersicht

Diese Übersicht ist die Config-Ebene zum Kapitel "Domain & Deployment Concept". Die Platzierungs-Regel ist generisch; die Tabellen hier sind unsere konkrete Instanziierung. Vor Vertrauen verifizieren — Inventar gilt nur, solange es geprüft ist.

#Estate-Server-Rollen

Host IP(s) Provider Rolle OS
bbe-demo (host_id 4) 178.105.187.135 Hetzner cpx32 (nbg1) Kanonisches STAGING / DEMO — staging-first landet hier; off---set-Backup Debian 13, Caddy
bbe-live (host_id 5) 91.99.99.252 Hetzner cpx32 (nbg1) LIVE-Promotion-Ziel — off---set serving Debian 13, Caddy
Storage Box box u587136 Hetzner BACKUP — off-site restic, no_single_copy
159 (bbe-primary) 159.195.30.60 Netcup (v2202…) Agenten-/Infra-Host — bleibt frei von öffentlichem Web, KEINE neuen Projekte Debian 13
73er / alt-server 45.84.199.73 pph-server Legacy-Prod, überlastet, Rollback-Fallback — migrieren-weg, nie neues Main Debian 12, Apache

Andere in DNS sichtbare Hosts: zabazingo 84.16.66.164 = ein gunicorn-Redirect-Host (.it→.de, NICHT Infomaniak); ein Shopify-Storefront ist extern.

#Umgebungs-Logik (Kurzform)

STAGING (bbe-demo/178)  →  bauen + verifizieren ZUERST, immer
        │  Operator-Gate (Promotion)
        ▼
LIVE (bbe-live/91.99.99.252)  →  promoten, nie selbst der erste Schritt
        +
BACKUP (Storage Box)  →  IMMER, parallel, für alles Stateful
  • 159 trägt kein neues öffentliches Web.
    Es ist der Agenten-/Infra-Host.
  • 73er ist Rollback/Legacy.
    Neue Dienste landen dort nie als Main.
  • Kein Stateful-Service ohne Backup + dedizierte Daten-Partition.

#Fundament-Services (auf 159, 127.0.0.1)

Service Port Zweck
port-registry 5099 Port-Allokation / -Registrierung
hetzner-api 5110 governed Server-Provisioning
ip-pool-api 5340 IP-State-Machine; POST /v1/ip/reserve (clean tier)
adam-eve-bridge 5320 MCP-Brücke zum PM
infomaniak-api 5380 DNS-Adapter
dynadot-api 5390 Domain-Registrar (sandbox)

#Zugang (Verweise, keine Secrets hier)

  • Auf 159 läuft man als dev mit NOPASSWD-sudo.
  • 73er: ssh alt-server (User root, Key konfiguriert).
  • bbe-live / bbe-demo: sudo ssh -i /root/.ssh/id_ed25519 root@<ip> (Key bbe-netcup-hub).
  • rsync zu live/demo: rsync -e "ssh -i /root/.ssh/id_ed25519" … (via sudo).

Keine Schlüssel, Passwörter oder Tokens stehen in dieser Doku. Secrets liegen im age-Vault / Vaultwarden und werden nie ausgegeben.

#Der Infrastructure Conductor (Agent #9)

Alle Server-, Domain-, E-Mail-, Backup- und Deploy-Arbeit läuft über die bbe-infra-Disziplin und wird vom Infrastructure Conductor #9 ausgeführt und protokolliert. Sein Arbeitsablauf:

  1. Verify — Inventar prüfen, bevor man vertraut.
  2. Plan — Platzierung über die drei Dimensionen entscheiden (TLD, Additivität, Umgebung).
  3. Execute — provisionieren / DNS / TLS / deployen über die Provider-Adapter (Hetzner, Netcup, Infomaniak).
  4. Verify again — Render-/Health-/TLS-Checks, bevor "fertig".
  5. Record — PM-Ticket für Follow-ups/Blocker, passende Memory-Datei aktualisieren.
  6. Announce — nach jeder abgeschlossenen Aktion eine kurze Markdown-Zusammenfassung in den conductor-log-Kanal posten (Mattermost), als Infrastructure Conductor #9: /srv/oktogen-chat/scripts/conductor-post.sh "<summary>" (auf 159; Token aus dem age-Vault, nie ausgegeben). So liest der Operator, was der Conductor getan hat.

Operator-Direktive: Der Operator führt nichts manuell aus. Infra-/DNS-/Deploy-/Console-Tasks werden als [ROOT·service]-PM-Ticket an den Conductor delegiert.

GLOBAL eSIM — INTERNES DOSSIER — 6 DOCS — 2026-08-02
Markdown copied