Agentic Ventures Wiki

Cloudflare-Migration agenticventures.de — Schritt-fuer-Schritt

6 Min. Lesezeit

Cloudflare-Migration agenticventures.de

Anleitung fuer den NS-Switch von Strato auf Cloudflare. Voraussetzung fuer Step 1B.5 (mcp-vf-Origin auf AWS) und alle kommenden hosted MCPs (gsuite-hosted, kunden-hosted etc.). Zeit: ~30 Min Setup + 1-6h Propagation.

Warum

ECS Express Mode bringt *.ecs.eu-central-1.on.aws als AWS-managed TLS-Cert mit. Wenn wir mcp-vf.agenticventures.de direkt per Strato-CNAME auf den AWS-Endpoint zeigen lassen, gibts einen TLS-Cert-Mismatch (Browser akzeptiert das *.ecs...-Cert nicht fuer unsere Subdomain). Cloudflare loest das, weil es:

  1. Eigenes TLS-Cert fuer mcp-vf.agenticventures.de ausstellt (Browser-Edge)
  2. Full (strict) zur Origin nutzt — Cloudflare validiert das *.ecs...-Cert auf der Backend-Seite
  3. WAF + Rate-Limit + DDoS-Schutz inklusive (Free-Tier reicht)
  4. Pattern-konsistent zu allen kuenftigen MCPs (Skalierung ohne weiteren TLS-Bau)

Pre-Check

Beantwortet werden muessen bevor wir starten:

FrageAntwortWo
Wer ist Registrar?Strato (NS shades17/docks10.rzone.de)dig NS agenticventures.de
Welche DNS-Records existieren?siehe Bestandsaufnahme untenStrato-Webinterface DNS-Verwaltung
Hat Strato eine DNS-Export-Funktion?ja, im DNS-Verwaltungs-BereichDomain-Verwaltung → DNS
E-Mail-Provider?Strato Mail (smtpin.rzone.de)MX-Records
Existiert ein Cloudflare-Account?tbd — falls nein, neu anlegen Free-Plandash.cloudflare.com
Off-business-hours Slot?Sonntag Nachmittag/Abend ideal — niedrige E-Mail-LastKalender pruefen

Bestandsaufnahme — Strato-Records (Stand 2026-05-10)

Per dig ermittelt. Strato-Export liefert ggf. mehr (DKIM-Selektoren, interne Records).

Apex und Root-Records

RecordTypeValueFunktion
agenticventures.de.A216.198.79.1Strato-Webspace (Marketing-Site)
agenticventures.de.MX5 smtpin.rzone.de.E-Mail-Empfang ueber Strato Mail
agenticventures.de.NSshades17.rzone.de., docks10.rzone.de.Strato-NS (wird ersetzt)
agenticventures.de.SOAshades17.rzone.de. hostmaster.strato-rz.de. ...wird automatisch ersetzt

Subdomains mit echten Records

RecordTypeValueFunktion
_dmarc.agenticventures.de.TXTv=DMARC1;p=reject;DMARC-Policy
www.agenticventures.de.CNAMEagenticventures.de.www-Redirect
autoconfig.agenticventures.de.CNAMEautoconfigure.strato.de.E-Mail-Client-Auto-Setup
mcp-vf.agenticventures.de.CNAMEaaeah48n.up.railway.app.aktueller Railway-Origin (wird nach Switch zu AWS)
_railway-verify.mcp-vf.agenticventures.de.TXTrailway-verify=5ecd81...Railway-Domain-Ownership-Token — Pflicht solange Railway parallel laeuft, NACH Railway-Stop loeschen

Strato-Wildcard-Default

Strato beantwortet ALLE non-existing Subdomain-MX-Queries mit 5 smtpin.rzone.de. — das ist Strato-Default und KEIN echter Record. Bei Cloudflare gibts dieses Verhalten nicht. Subdomains die das nutzen wuerden (z.B. nicht-existente mail@gmail.agenticventures.de) bouncen. Praktisch: Marvin nutzt hello@agenticventures.de und hello@marvinkuehlmann.com, also nur Apex relevant.

Was fehlt (nicht durch Cloudflare-Migration verursacht — bestehender Zustand)

WasAuswirkungFix-Empfehlung
Kein SPF-Record (TXT auf @)E-Mails von hello@agenticventures.de werden manchmal als “soft-fail” gewertetnach Migration: TXT-Record v=spf1 include:_spf.strato.com ~all (oder Strato-Doku)
Kein DKIM-Selektor gefundenStrato signiert vermutlich nicht mit DKIMStrato-Support fragen ob DKIM verfuegbar ist
_dmarc policy ist reject ohne SPF/DKIMinkonsistent — DMARC-reject braucht SPF oder DKIM um nicht-konforme Mails zu rejectennach SPF-Setup neu pruefen

→ Diese Punkte sind nicht-blockierend fuer Migration, aber sollte als Folge-Aufgabe ins Backlog. Eintragen unter intern/ideen/ideas-backlog.md.

Migrations-Schritte

Schritt 0: Strato-DNS-Export (Marvin)

  1. strato.de Login
  2. „Meine Domains” → agenticventures.de auswaehlen
  3. „DNS-Verwaltung” oder „Erweitertes DNS”
  4. Komplette Record-Liste exportieren (PDF / Screenshot / CSV — je nach Strato-UI)
  5. Mit der dig-Liste oben abgleichen — falls Records dort gelistet sind die nicht in der dig-Liste auftauchen (z.B. proprietaere Strato-Eintraege, DKIM, weitere TXT), zur Cloudflare-Aufnahme markieren

Schritt 1: Cloudflare-Account anlegen (Marvin)

  1. dash.cloudflare.com/sign-up — Free-Plan
  2. E-Mail bestaetigen, MFA aktivieren (1Password als Authenticator)
  3. „Add a Site” → agenticventures.de eintippen → Free-Plan waehlen
  4. Cloudflare scannt automatisch existierende DNS-Records (per dig-Lookup) und schlaegt sie zur Uebernahme vor

Schritt 2: Records-Sanity-Check (gemeinsam)

Cloudflare zeigt eine Liste der gefundenen Records. Wir pruefen:

Soll-RecordCloudflare-Auto-Scan?Manuell ergaenzen?Proxy?
agenticventures.de A 216.198.79.1ja—proxied (orange)
agenticventures.de MX 5 smtpin.rzone.de.ja—DNS-only (grau) — niemals MX proxien
_dmarc.agenticventures.de TXT v=DMARC1;p=reject;meistens jafalls nein: anlegenDNS-only
www.agenticventures.de CNAME agenticventures.deja—proxied (orange)
autoconfig.agenticventures.de CNAME autoconfigure.strato.de.ja—DNS-only — E-Mail-Auto-Setup darf nicht durch CF
mcp-vf.agenticventures.de CNAME aaeah48n.up.railway.app.ja—proxied (orange) — wird in Schritt 6 auf AWS umgestellt
_railway-verify.mcp-vf.agenticventures.de TXT railway-verify=...meistens jafalls nein: aus Strato-Export 1:1 uebernehmenDNS-only (grau) — Railway-Verify, behalten bis Step 1B.7 (Railway-Stop), dann loeschen

Plus aus Strato-Export ergaenzen falls dort weitere Records auftauchen (z.B. strato-reflect, Verifications-TXT, DKIM, etc.). DNS-only fuer alles E-Mail/Auth-bezogene, proxied fuer Web.

Schritt 3: SSL/TLS-Mode setzen (Marvin)

In Cloudflare-Dashboard:

  1. SSL/TLS → Overview → Full (strict)
  2. Edge Certificates → Always Use HTTPS aktivieren
  3. Edge Certificates → HSTS aktivieren (Max-Age 6 months, Apply to subdomains, Preload)

Schritt 4: NS-Switch in Strato (Marvin)

  1. Cloudflare zeigt zwei zugewiesene NS, z.B. ada.ns.cloudflare.com und bob.ns.cloudflare.com (Namen sind randomisiert pro Account) — NS-Werte notieren
  2. strato.de Login → Domain-Verwaltung → agenticventures.de
  3. „Nameserver bearbeiten” oder „Andere Nameserver verwenden”
  4. Zwei Cloudflare-NS einsetzen → Speichern
  5. Strato bestaetigt mit „Nameserver geaendert”
  6. Ab jetzt 1-6h Propagations-Phase — Strato-Resolver lesen alte Records, neue Resolver fragen Cloudflare. Beide URLs muessen waehrend der Phase funktionieren — sie tun das, weil:
    • Alte Resolver finden Strato-Records mit Railway-CNAME → mcp-vf zeigt auf Railway → AWS bleibt unverwendet
    • Neue Resolver finden Cloudflare-Records mit Railway-CNAME (Schritt 2) → mcp-vf zeigt weiterhin auf Railway → kein Outage

Schritt 5: Cloudflare-Aktivierungs-E-Mail abwarten (automatisch)

Cloudflare schickt eine E-Mail „agenticventures.de is now active on Cloudflare”. Status im CF-Dashboard wird gruen. Wenn nach 6h immer noch pending: NS-Werte in Strato pruefen.

Schritt 6: mcp-vf-Origin auf AWS umlenken (1 Klick)

In Cloudflare-Dashboard:

  1. DNS → Records
  2. mcp-vf Record bearbeiten
  3. Target von aaeah48n.up.railway.app auf mc-1a56ed08537b4f9fae11028fe698af47.ecs.eu-central-1.on.aws
  4. Proxy: Proxied (orange) lassen
  5. TTL: Auto
  6. Save — wirkt innerhalb ~60s (Cloudflare-Edge-Cache-TTL)

Schritt 7: Smoke-Test (Claude/Marvin)

curl -sS -i https://mcp-vf.agenticventures.de/health
# erwartet:
#   HTTP/2 200
#   server: cloudflare
#   cf-ray: <some-id>
#   {"ok":true}

Wenn server: railway-edge zurueckkommt: DNS-Cache, paar Minuten warten oder anderen Resolver testen (dig @1.1.1.1 mcp-vf.agenticventures.de).

Schritt 8: Andre’s Connector smoken (Marvin koordiniert mit Andre)

Andre soll in claude.ai einen einfachen Tool-Call machen, z.B.:

  • „Liste die letzten 5 Papierkram-Rechnungen auf”
  • „Welche TicketPAY-Events sind diesen Monat eingegangen?”

CloudWatch-Logs pruefen ob die Tool-Calls auf AWS ankommen:

~/.local/bin/aws logs tail /aws/ecs/default/mcp-vf-hosted-f908 --profile av-production --region eu-central-1 --follow

Erwartet: tool_call Events mit subject (Andres JWT-Sub-Hash), tool (z.B. papierkram_list_invoices), status: 200.

= Phase 1B.6 ✅

Schritt 9: 24h Stabilitaets-Beobachtung

  • CloudWatch Logs auf Errors pruefen
  • ECS Service Status-Health
  • Kein 5xx-Spike in CF-Analytics

= Voraussetzung fuer Phase 1B.7 (Railway-Service abschalten)

Risiko-Mitigation

RisikoMitigation
E-Mail-Outage waehrend PropagationMX-Record VOR NS-Switch in Cloudflare gesetzt + DNS-only (grauer Wolke)
Falscher Cloudflare-Plan (Pro/Business)Free reicht — Pro/Business nur fuer Image-Resize / Workers / Bot-Mgmt-Premium
Cloudflare Always-Use-HTTPS bricht alten http-LinkPruefen ob Strato-Webspace bereits HTTPS macht (vermutlich ja)
Tool-Calls failen nach Cutoversofortiger Rollback: NS in Strato zurueckstellen, ALT bekommt wieder Traffic
TLS-Mode Flexible statt Full(strict)Default ist sometimes Flexible bei Free-Plan — explizit auf Full(strict) setzen
Andre’s Scalekit-Session ungueltig nach Cutovernicht zu erwarten — Identifier https://mcp-vf.agenticventures.de/mcp ist unveraendert, JWT-Audience matcht weiterhin

Rollback-Plan

Falls nach Schritt 6 Probleme auftauchen:

  1. Sofort-Rollback (in CF-Dashboard, ~60s wirksam):

    • DNS → mcp-vf Record bearbeiten
    • Target zurueck auf aaeah48n.up.railway.app
    • Save

  2. NS-Rollback (NS in Strato zurueckstellen, 1-6h):

    • Strato → Nameserver → shades17.rzone.de + docks10.rzone.de
    • Save
    • waehrend Propagation laufen Cloudflare-Records weiter (alte Resolver) bis sie aufgegeben werden

Beide Rollbacks sind nicht-destruktiv — Cloudflare-Account und Records bleiben fuer den naechsten Versuch erhalten.

Konsequenz fuers Pattern

Nach erfolgreicher Migration:

  • web-properties aktualisieren — alle Subdomains zeigen ueber Cloudflare auf AWS-Endpoints
  • mcp-hosting-aws-ecs-express — Cloudflare-Setup als „uebliche Cloudflare-DNS-Aktion” referenzieren statt als „muss noch gebaut werden”
  • Pattern fuer den naechsten hosted MCP (gsuite-hosted, woehrle-hosted etc.): genau dieselbe Cloudflare-Sequence ab Schritt 6 — ein neuer CNAME, fertig

Cross-Refs

Graphansicht

Backlinks