Claude Code Deploy: Der Trockenlauf-Check vor dem Produktiv-Push

An einem Freitagabend sagte ich zu Claude Code: “Stell die Korrektur an diesem Artikel live.” Zurück kam nur ein kurzes “Veröffentlicht” und ein grüner Haken. Ich machte beruhigt Feierabend. Am nächsten Morgen war die Startseite meiner Website komplett weiß.

Die Ursache war banal: Niemand hatte die Vorschau geöffnet. Claude Code hatte nur ins Build-Log geschaut, gesehen, dass der Build durchlief, und das als “Erfolg” verbucht. Die echte Seite zog aber das Template eines anderen Artikels und war inhaltlich leer. Weil HTTP trotzdem 200 zurückgibt, sieht so etwas rein maschinell wie eine “erfolgreiche Veröffentlichung” aus.

Was mir in dem Moment klar wurde: Schnelligkeit und Sicherheit sind zwei verschiedene Dinge. Wenn du den ganzen Deploy abgibst, ist er gefühlt in einer Sekunde durch. Aber wenn nirgends festgehalten ist, was eigentlich geprüft wurde, weißt du nach dem Sturz nicht, was du zurückrollen musst. Heute schreibe ich darüber, wie ich dagegen vorgehe: ein Trockenlauf (Dry Run), der die Belege zusammenträgt, bevor irgendjemand Produktionsrechte bekommt.

Das Wichtigste in Kürze

Die meisten Unfälle beim delegierten Deploy entstehen nicht durch Dummheit der KI, sondern weil die Prüfung vor dem Zugriff auf die Produktion übersprungen wurde.
Bevor du Produktionsrechte vergibst, prüfst du im Trockenlauf fünf Dinge: Build, Diff, Preview-URL, Rollback-Verantwortliche und den unberührten Bereich.
Wer “maschinell prüfbare Checks” von “Dinge, die ein Mensch mit eigenen Augen beurteilt” trennt, hat nachts deutlich weniger Notfälle.
Es gibt eine Copy-Paste-Prompt-Vorlage und ein lauffähiges Skript, das deine Trockenlauf-Ergebnisse maschinell auswertet.
Du brauchst nicht von Anfang an perfekte Betriebsregeln. Du testest mit einer einzigen Korrektur und ergänzt die Checkliste um jede Stelle, an der du gestolpert bist.

Deploy-Unfälle entstehen nicht durch fehlende Intelligenz, sondern durch fehlende Prüfung

Claude Code ist clever. Aber clever zu sein und in der Produktion sicher zu agieren, sind zwei verschiedene Paar Schuhe.

Es ist wie bei der Schülerin, die jede Klausur mit Bestnote schreibt und am ersten Aushilfstag die Kasse zerlegt: Das Problem ist nicht das Können, sondern das fehlende Gerüst. Beim Deployen heißt “Gerüst” schlicht: Was prüfst du, bevor du die Produktion anfasst?

Gerade bei statischen Websites scheitern Deploys leise. Wenn der Build durchläuft und HTTP 200 liefert, sieht oberflächlich alles in Ordnung aus. Ob der Inhalt leer ist oder gegen eine fremde Seite ausgetauscht wurde, merkst du nicht, wenn du nur auf den Statuscode schaust. Deshalb musst du nicht prüfen “ist der Code gelaufen?”, sondern “kommt die richtige Seite richtig raus?” - und das einmal mit menschlichem Auge.

Die fünf Trockenlauf-Schritte vor dem Produktiv-Push

Das hier ist das ganze Verfahren, das ich aktuell nutze. Die Reihenfolge ist wichtig, deshalb stehen die Schritte von oben nach unten.

Erst lokal den Build durchlaufen lassen. Wenn es schon hier scheitert, erübrigt sich das Thema Produktion. Du trennst vor dem Zugriff auf die Produktion, ob das Problem im Code oder in der Umgebung liegt.
Das Diff lesen. Mit eigenen Augen kontrollieren, ob sich vertrauliche Daten (API-Schlüssel, Tokens) oder abrechnungsrelevante Änderungen eingeschlichen haben.
Die Preview-URL öffnen. Im echten Bild prüfen, ob Überschrift (h1), kanonische URL (canonical) und das Ziel des Anmelde-Buttons wie erwartet sind.
Rollback-Verantwortliche und Rollback-Weg festlegen. Wer rollt im Fehlerfall mit welchem Befehl auf den vorherigen Stand zurück? Wenn du das nicht vorher klärst, erstarrst du im Moment des Unfalls.
Erst wenn die Belege vorliegen, Produktionsrechte anfragen. Erst wenn die Ergebnisse aus 1 bis 4 da sind, beauftragst du Claude Code mit dem Produktiv-Deploy.

Allein wenn du diese Reihenfolge einhältst, passiert der “weiße Startseite”-Unfall vom Anfang praktisch nicht mehr. Denn in Schritt 3 öffnest du zwingend die Vorschau.

Was du der KI überlässt - und was der Mensch entscheidet

Du gibst weder alles an die KI ab noch fällst du auf reine Handarbeit zurück. Du teilst die Rollen auf. Die Tabelle unten zeigt, wo ich in der Praxis die Grenze ziehe.

Situation	Was Claude Code übernimmt	Beleg, den der Mensch ansieht
Artikel veröffentlichen	Vorab den dist-Build und einen automatischen Check der Live-URL laufen lassen	Build-Ergebnis, Diff, URL
Anmelde-Button ändern	Linkziel und Beratungs-Funnel in der Vorschau abgleichen	Build-Ergebnis, Diff, URL
Workers-Korrektur	Umgebungsvariablen nicht anfassen, nur das Trockenlauf-Log ausgeben	Build-Ergebnis, Diff, URL

Der Kern ist diese Aufteilung: Lesen, Auflisten und maschinelles Prüfen überlässt du der KI; Operationen, die unumkehrbare Änderungen an der Produktion vornehmen, genehmigt ein Mensch. Löschen, Schreiben in die Produktionsdatenbank, Abrechnung und Force-Push stellst du anfangs alle auf “vorher den Menschen fragen”. Nur Operationen, die sich als sicher erwiesen haben, stufst du später auf automatisch hoch.

Wer die Grenzen der Rechte feiner ziehen will, findet im Leitfaden zu den Berechtigungseinstellungen von Claude Code und im Permission-Audit vor dem Deploy gute Anhaltspunkte.

Copy-Paste-Prompt-Vorlage

Der Trick: Den Auftrag nicht blind abgeben, sondern ausdrücklich sagen “noch nicht live stellen”. Die folgende Vorlage kannst du direkt einfügen.

Wandle diese Änderung in eine "Trockenlauf-Checkliste" vor dem Produktiv-Deploy um.
Gib die folgenden Punkte als Tabelle zurück:
- Build-Ergebnis (Erfolg / Fehler samt Kernaussage des Logs)
- Diff-Risiko (sind vertrauliche Daten, Abrechnung oder Löschungen enthalten?)
- Preview-URL
- Rollback-Verantwortliche und Rollback-Befehl
- unberührter Bereich
- Bedingungen für einen erneuten Versuch
Führe den Produktiv-Deploy noch NICHT aus. Warte, bis ich die Checks geprüft habe.

Die letzten beiden Zeilen sind entscheidend. Wenn du “noch nicht ausführen” und “warte, bis ich geprüft habe” hinschreibst, verhinderst du, dass Claude Code übereifrig wird und ungefragt veröffentlicht. Wie du Prompts grundsätzlich auf die sichere Seite kippst, habe ich auch im Prompt-Design für Fortgeschrittene zusammengefasst.

Lauffähiges Prüfskript zum Kopieren

Wenn du das Prüfergebnis nicht nach “Bauchgefühl”, sondern maschinell auswertest, gehen dir weniger Dinge durch die Lappen. Das folgende Skript nimmt das Ergebnisobjekt des Trockenlaufs entgegen und gibt als Wahrheitswert zurück, ob der Zustand reif ist, Produktionsrechte anzufragen. Mit Node.js läuft es direkt.

// Ergebnis des Trockenlaufs. Hier kommen die echten Prüfinhalte rein
const deployCheck = {
  build: "passed",              // Ist der lokale Build durchgelaufen?
  diffReviewed: true,           // Wurde das Diff mit Auge geprüft?
  previewUrl: "https://example.pages.dev", // Preview-URL
  rollbackOwner: "Masa",        // Rollback-Verantwortliche
  changedAreas: ["content", "cta-copy"],   // berührter Bereich
};

// Türsteher: prüft, ob man Produktionsrechte anfragen darf
function canRequestProductionAccess(check) {
  return (
    check.build === "passed" &&          // Build ist durchgelaufen
    check.diffReviewed &&                // Diff wurde gesehen
    /^https:\/\//.test(check.previewUrl) && // Preview-URL existiert per https
    check.rollbackOwner.length > 0 &&    // Rollback-Verantwortliche stehen fest
    !check.changedAreas.includes("secrets") // vertraulicher Bereich nicht berührt
  );
}

const ready = canRequestProductionAccess(deployCheck);
console.log({ ready });
// Solange "ready" false ist, fragst du keine Produktionsrechte an

Der Wert dieses Codes steckt in der Stelle, an der er false zurückgibt, sobald "secrets" in changedAreas auftaucht. Hast du versehentlich vertrauliche Daten angefasst, kommst du nie bis zur Anfrage der Produktionsrechte durch. Selbst wenn ein Mensch im Stress etwas übersieht, stoppt der Türsteher.

Drei Situationen, in denen es wirklich geholfen hat

Erstens: das Veröffentlichen von Artikeln. Bei einem bloßen “Stell den Blog live” wird bis zur Veröffentlichung durchgerannt, sobald der Build steht. Schiebst du den Trockenlauf dazwischen, öffnest du erst die Live-URL und prüfst, ob Überschrift und Inhalt zusammenpassen - damit ist der weiße-Seite-Unfall vom Anfang gestoppt.

Zweitens: das Austauschen des Anmelde-Buttons. Ein einziger Tippfehler im Linkziel reicht, und der mühsam gebaute Funnel landet im 404. Seit ich den Schritt eingebaut habe, den Button in der Vorschau tatsächlich zu klicken und das Ziel zu prüfen, gibt es null tote Links.

Drittens: Korrekturen an Cloudflare Workers. Hier reicht es, eine einzige Umgebungsvariable zu löschen, und die Produktion geht runter. Deshalb lasse ich beim Trockenlauf die Umgebungsvariablen unangetastet und nur das Log ausgeben. Die Besonderheiten von Workers habe ich auch im Artikel zur Cloudflare-Workers-Anbindung gesammelt.

Typische Fallstricke und wie du sie behebst

Drei Fehler, die ich tatsächlich gebaut habe - und ihre Lösung.

Fallstrick 1: den Produktionsbefehl vor dem Build abfeuern. Wer direkt wrangler deploy laufen lässt, kann im Fehlerfall nicht trennen, ob der Code oder die Umgebung schuld ist. Die Lösung ist simpel: immer zuerst den lokalen Build durchlaufen lassen. Eine einzige Änderung in der Reihenfolge, und die Ursachensuche geht schlagartig schneller.

Fallstrick 2: keine Rollback-Verantwortlichen bestimmt. Wenn du erst nach dem Fehler anfängst zu beraten “Wer rollt zurück?”, schlägt der Ausfall in genau diesen Minuten voll auf die Besucher durch. Die Lösung: Schon in der Trockenlauf-Phase Rollback-Verantwortliche und Rollback-Befehl schriftlich festhalten. Selbst wenn du nur die previousDeployId notierst, läuft die Wiederherstellung ruhiger ab.

Fallstrick 3: die Vorschau nicht öffnen und nur dem Statuscode vertrauen. HTTP 200 heißt nur “der Server hat irgendetwas zurückgegeben”, nicht “die richtige Seite ist erschienen”. Die Lösung: die Preview-URL zwingend einmal im Browser öffnen und Überschrift, kanonische URL und Hero-Bild mit eigenem Auge ansehen. Das war der einzige Weg, die weiße Seite vom Anfang zu entlarven.

Belege als “Notiz, die du nächstes Mal wieder brauchst” aufbewahren

Was du im Trockenlauf geprüft hast, solltest du nicht gleich verwerfen, sondern in einer kurzen Notiz festhalten - die nächste Aufgabe geht damit spürbar schneller.

So viel reicht: der ursprünglich gestellte Auftragstext, der Bereich, den Claude Code gelesen hat, der unberührte Bereich, die ausgeführten Prüfbefehle, Live-URLs oder Screenshots und die Punkte, bei denen du unsicher warst. Ein langes Protokoll brauchst du nicht. Wenn du im Nachhinein nachvollziehen kannst, “warum diese Entscheidung gefallen ist”, ist das Ziel erreicht.

Besonders wirksam ist es, den “Scheidepunkt der Entscheidung” in einer Zeile festzuhalten. Zum Beispiel: “Preview-URL stimmt, aber Rollback-Verantwortliche fehlen, also noch nicht in Produktion.” Macht beim nächsten Mal dieselbe Aufgabe an - du selbst oder jemand anderes - lässt sich dieselbe Prüfung reproduzieren. Dieselbe Denkweise funktioniert auch bei anderen Automatisierungen abseits von Deploys; zusammen mit der Einführung in Claude Code für Nicht-Entwickler gelesen, bekommst du ein Gefühl dafür, wie man richtig delegiert.

Häufige Fragen

F. Ist der Trockenlauf am Ende nicht einfach nur mehr Aufwand? Anfangs fühlt es sich so an. Aber wenn einmal ein Unfall passiert, verschwinden Stunden in Wiederherstellung und Ursachensuche. Der Trockenlauf kostet ein paar Minuten. Ich halte ihn für eine Versicherung, die sich rechnet, und mache ihn deshalb durchgehend.

F. Wenn der lokale Build durchläuft, kann ich mir die Vorschau dann sparen? Nein. Auch wenn der Build durchläuft, kommen Template-Vertauschungen und leere Seiten vor. HTTP 200 und “die richtige Seite” sind zwei verschiedene Dinge, der Blick mit eigenem Auge lässt sich nicht weglassen.

F. Hat es Sinn, Rollback-Verantwortliche festzulegen, wenn ich allein arbeite? Ja. Selbst allein gilt: Wenn du vorher schriftlich festhältst “bei Fehler rolle ich mit diesem Befehl zurück”, zögerst du im Ernstfall nicht. Das Festlegen selbst wird zum Verfahren.

F. Darf ich es glauben, wenn Claude Code “Veröffentlicht” meldet? Schau weniger auf die Antwort selbst als auf die Belege des Trockenlaufs. Du entscheidest danach, ob Build, Diff, Preview und Rollback-Verantwortliche vollständig vorliegen. Worte sind Stimmung, Belege sind Fakten.

F. Muss man das bei einer kleinen Website wirklich so weit treiben? Denk weniger in Größe und mehr in “kann ich zurückrollen?”. Auch klein tut weh, wenn die Produktion ausfällt. Bau zuerst nur den einen Schritt ein, die Vorschau zu öffnen, dann spürst du die Wirkung.

Was ich tatsächlich ausprobiert habe

Nach dem weiße-Seite-Unfall vom Anfang habe ich dieses Trockenlauf-Verfahren in meinen eigenen Blog-Betrieb eingebaut.

Geprüft habe ich drei Dinge. Erstens: Seit ich die Regel habe, die Preview-URL immer zu öffnen, gibt es null leere Seiten durch Template-Vertauschung. Zweitens: Seit ich das obige Prüfskript vor jeder Veröffentlichung laufen lasse, bleiben Änderungen, die vertrauliche Bereiche berühren, bei ready: false stehen und kommen gar nicht erst bis zur Anfrage der Produktionsrechte. Drittens: Seit ich jedes Mal Rollback-Verantwortliche und Rollback-Befehl notiere, lässt sich selbst in brenzligen Momenten der vorherige Stand in wenigen Minuten wiederherstellen.

Statt alles der schlauen KI zu überlassen und zu beten, baust du dir vorher ein Gerüst, auf dem du dich beim Stolpern nicht verletzt. Das wirkt wie ein Umweg, ist aber am Ende der schnellste Weg - das ist mein heutiges Fazit. Fang mit dem einen Schritt an, die Vorschau zu öffnen, und setz deinem Deploy einen Türsteher davor.

Wenn du im Team die Grenzen des Produktiv-Deploys und sogar das Review-System aufsetzen willst, können wir das in Training und Beratung gemeinsam in ein Verfahren gießen. Die offiziellen Betriebsstandards findest du außerdem in der offiziellen Claude-Code-Dokumentation von Anthropic.