Build Once, Serve Everywhere: Wie ein KI-Agent unsere Infrastruktur in einer Session konsolidiert hat

Auf einer einzigen EC2-Instanz in Frankfurt laufen gerade 7 Docker-Container. Sie bedienen Staging- und Produktions-Traffic für eine Cashback-Plattform. Der Quellcode liegt nicht auf diesem Server. Der gesamte Konfigurationsfußabdruck: 72 Kilobyte.

Vor drei Wochen hatten wir zwei EC2-Instanzen, zwei separate CI/CD-Pipelines, Docker-Images, die für jede Umgebung separat gebaut werden mussten, und ein Git-Repository auf dem Produktionsserver. Eine Frage hat die Aufräumaktion gestartet: „Können wir die Demo einfach auf den Prod-Server migrieren?”

Vier Stunden später war die Antwort: Ja. So sah die Session wirklich aus.

---

Der Ausgangspunkt

Das hier ist eine Fortsetzung der ursprünglichen Build-Session, in der wir diese Cashback-Plattform von null in einem Tag gebaut haben, und der ersten Runde Production Hardening danach. Die Infrastruktur war gewachsen, aber nie aufgeräumt worden.

Vor dieser Session sah es so aus:

• demo: t3.small, x86, Ubuntu, mit einem lokalen Postgres-Container. ~20 $/Monat.
• prod: t4g.medium, ARM (Graviton), Amazon Linux, verbunden mit Amazon RDS. ~40 $/Monat.
• ~60 $/Monat für etwas, das vernünftigerweise eine Instanz sein könnte.

Die unterschiedlichen CPU-Architekturen haben sich ausgewirkt: ARM-Builds laufen nicht auf x86, also hatten wir zwei separate Docker-Build-Targets in CI. Zwei separate Deploy-Jobs. Zwei Umgebungen, die auseinanderdrifteten, sobald eine Änderung in der einen fehlte.

Das tiefere Problem war die Umgebungskonfiguration. Jede API-URL war eine VITE_*-Variable, die zur Build-Zeit ins Bundle eingebacken wurde. VITE_API_URL=https://backend.myapp.com wurde während npm run build ins JavaScript eingebettet. Man konnte ein production-gebautes Image also nicht nehmen und auf ein anderes Backend zeigen — man musste neu bauen.

Das praktische Ergebnis: Demo lief auf älterem Code, mit anderen Einstellungen, auf anderer Hardware. Das war keine Staging-Umgebung — es war eine zweite Produktionsumgebung, um die sich niemand so richtig gekümmert hat.

---

Das Gespräch, das alles startete

Ich kam in die Session mit dem Konsolidierungsplan im Kopf: ein Server, Staging und Production nebeneinander, gemeinsames RDS mit Isolation auf Datenbankebene, Runtime-Config statt Build-Time-Variablen. Die Architektur war klar. Was ich wollte, war ein zweites Paar Augen — Ansatz validieren, Randfälle durchdenken, bevor ich mich auf ein 7-Phasen-Refactoring festlege.

Das Planungsgespräch hat sich gelohnt. Ein konkretes Ergebnis daraus: Resource Limits auf den Staging-Containern. Staging und Production auf demselben Host ohne CPU- und Memory-Constraints zu betreiben bedeutet, dass ein außer Kontrolle geratener Staging-Prozess Production zum Absturz bringen kann. Wir haben mem_limit: 512m und cpus: 0.5 zum Staging-Backend hinzugefügt, mem_limit: 128m und cpus: 0.25 zum Static-Container — das Docker-Compose-Äquivalent von Kubernetes-Namespace-Level-Resource-Quotas. Auf einem Kubernetes-Cluster würde man Staging und Production ins selbe Hardware-Pool legen und mit Namespaces trennen; dasselbe Prinzip. Mit dem Budget eines Nebenprojekts auf einem überdimensionierten t4g.medium, das bei 10 % Auslastung läuft, ist das der richtige Trade-off.

Der Planungs-Agent hat ein 460-Zeilen-Dokument produziert, das 7 Phasen abdeckt. Wir sind es durchgegangen, haben uns auf den Ansatz geeinigt und angefangen. Über die gesamte Session hinweg hat eine Flotte spezialisierter Agenten alles übernommen — von SQL-Migrationen und parallelen Frontend-Refactorings bis zur CI-Fehlerdiagnose und nginx-Config-Review — jeder in seinem eigenen Scope.

---

Phase 1: Runtime-Config — Der schwierige Teil

Das VITE-Variablen-Problem war der größte Blocker. Wenn man dasselbe Docker-Image nicht in Staging und Production betreiben kann, kann man keine einheitliche CI/CD-Pipeline haben. Also zuerst das lösen.

Der Ansatz teilte sich in zwei Strategien auf:

Für das Admin-Panel: Die Admin-Backend-URL ist immer vorhersehbar — gleicher Hostname, aber admin. durch backend. ersetzt. Statt eine Config-Datei zu lesen, leitet das Admin-Panel seine API-URL direkt aus der aktuellen Seitenadresse ab:

export function getApiUrl(): string {
  if (typeof window === 'undefined') return 'http://localhost:4000';
  const { hostname, protocol } = window.location;
  if (hostname === 'localhost') return 'http://localhost:4000';
  return `${protocol}//${hostname.replace(/^admin\./, 'backend.')}`;
}

Fünf Zeilen. Keine Config-Datei. Keine Umgebungsvariablen. Kein Rebuild nötig. Das Admin-Panel unter admin.staging.myapp.com zeigt automatisch auf backend.staging.myapp.com. Synchron — keine Loading States zu managen.

Für Landing Pages: Kampagnenspezifische Landing Pages brauchten mehr als nur eine API-URL. Sie brauchten Kampagnen-Metadaten: Start-/Enddatum, Cashback-Beträge, API-Keys, Texte. Diese Informationen hatten in VITE_*-Variablen gelebt, die in den Build eingebacken wurden.

Wir haben das durch eine Runtime-/config.json-Datei ersetzt, die beim Start geladen wird:

{
  "apiUrl": "https://backend.myapp.com",
  "apiKey": "your-api-key-here",
  "startDate": "2026-04-01",
  "endDate": "2026-08-31",
  "cashbackType": "FIXED",
  "cashbackAmount": 5.0
}

Das Async-Loading-Pattern nutzt einen Lazy-Singleton, damit nicht mehrfach pro Seitenaufruf gefetcht wird:

let configCache: Config | null = null;

export async function loadConfig(): Promise<Config> {
  if (configCache) return configCache;
  const res = await fetch('/config.json');
  // Bewusst kein Error Handling — wenn die Config nicht lädt, soll die App
  // beim Start laut scheitern, statt mit fehlenden Daten zu rendern.
  configCache = await res.json();
  return configCache;
}

export function getConfig(): Config {
  if (!configCache) throw new Error('Config not loaded yet — call loadConfig() first');
  return configCache;
}

Der Top-Level-Entry-Point ruft await loadConfig() auf, bevor irgendetwas gerendert wird. Danach kann der Rest der App getConfig() synchron aufrufen. Fail fast, fail early.

Das war nicht nur eine technische Vereinfachung — es hat verändert, was „eine Kampagnenänderung deployen” bedeutet. Vorher: VITE-Variable editieren, committen, pushen, warten bis CI neu baut und deployed. Nachher: JSON-Datei editieren, pushen, der SCP-Deploy läuft. Marketing kann Kampagnendaten oder Cashback-Beträge ändern, ohne CI anzufassen.

Drei Agenten liefen für diese Phase parallel — einer für Admin, einer für die Haupt-Landing-Page, einer für die generische Landing-Page-Struktur. Dieses Multi-Agenten-Parallel-Pattern ist eine der saubersten Möglichkeiten, Änderungen zu handhaben, die mehrere Codebasen gleichzeitig betreffen. Jeder Agent hat das Refactoring in seinem eigenen Scope durchgeführt, der Orchestrator hat die Ergebnisse zusammengeführt und verifiziert, dass die Builds überall durchlaufen.

---

Phase 2–3: Datenbank-Isolation — Der sorgfältige Teil

Die Merged-Server-Architektur bedeutete, dass Staging und Production dieselbe Amazon-RDS-Instanz teilen. Der Staging-Seed-Job, der Testdaten für E2E-Tests befüllt, durfte die Production-Datenbank unter keinen Umständen anfassen.

Der sicherste Ansatz: Isolation auf PostgreSQL-Ebene, kein Application-Level-Trust.

Vom Terminal des KI-Agenten aus, via SSH in die EC2 und psql gegen RDS:

CREATE DATABASE app_staging;
CREATE USER cd_staging WITH PASSWORD '...';
GRANT ALL PRIVILEGES ON DATABASE app_staging TO cd_staging;

-- Cross-Database-Zugriff explizit sperren
REVOKE ALL ON DATABASE app_prod FROM cd_staging;

Die Production-Datenbank bekam ihren eigenen dedizierten User mit Ownership über alle bestehenden Objekte:

-- RDS-Eigenheit: Das braucht man, bevor REASSIGN OWNED funktioniert
GRANT cd_prod TO postgres;
REASSIGN OWNED BY postgres TO cd_prod;

Die Zeile GRANT cd_prod TO postgres ist eine RDS-spezifische Besonderheit. Ohne sie wirft REASSIGN OWNED BY postgres TO cd_prod einen Permission-Error — der verwaltete postgres-Superuser von RDS kann nicht als eine Rolle agieren, in der er keine explizite Mitgliedschaft hat.

Dem Agenten beim SQL-Ausführen gegen Production-RDS zuzuschauen hat mich nervös gemacht — ich habe jede Query im Log verfolgt. Die rettende Gnade: Das war ein brandneues System ohne echte Kundendaten. Kein Risiko, wenn etwas schiefläuft. Und die Agenten haben gründliche Arbeit geleistet: neue User, neue Datenbankschemas, Passwort-Setup, Environment-File-Konfiguration — alles ohne dass ich eine einzige SQL-Anweisung tippen musste. Allerdings ist das genau die Art von Operation, über die ich anders nachdenken würde, wenn es Jahre von Produktionsdaten geben würde. Die Frage, wie viel Vertrauen man einem Agenten auf echter Infrastruktur entgegenbringt, hat keine einfache Antwort.

Nach der Migration haben wir die Isolation explizit verifiziert: cd_staging versucht, sich mit der Production-Datenbank zu verbinden — bestätigt, dass es mit einem Permission-Error scheitert. Dem SQL nicht vertrauen — das Ergebnis bestätigen.

---

Phase 4–5: Compose und Pipeline — Zwei Bugs und eine Sicherheitserkenntnis

Das docker-compose

Staging zur docker-compose hinzuzufügen war größtenteils mechanisch: Backend- und Static-Services duplizieren, hinter --profile staging sperren, Staging-Hostnamen zu nginx hinzufügen, Resource Limits setzen.

Die Überprüfung der nginx-Config hat etwas Unerwartetes zutage gebracht: einen /api/-Proxy-Block. Das war ein Überbleibsel aus der Zeit vor Phase 1 — als Landing Pages noch relative URLs wie /api/submit verwendet hatten, die nginx zum Backend proxyen musste. Nach Phase 1 nutzen alle API-Calls absolute URLs, die direkt auf das Backend zeigen. Der Proxy-Block war toter Code, der zwei Sessions Infrastrukturarbeit überlebt hatte, ohne dass es jemandem aufgefallen wäre.

Toten Code aus Infrastruktur zu entfernen ist befriedigend. Es ist kein Feature, taucht in keinen Metriken auf — aber es ist eines weniger, das in sechs Monaten falsch verstanden werden kann. Konsolidierung legt Ansammlungen offen. Man sieht den Schrott erst, wenn man das Ganze auf einmal im Blick hat.

Die Pipeline

Der Pipeline-Aufbau: Release Please übernimmt die Versionierung, Build erstellt ARM-Images, dann Deploy Staging, Verify Staging (5-Punkte-Smoke-Test), Deploy Prod, Verify Prod. Sequenziell. Staging sichert Production ab.

deploy-prod:
  needs: [release-please, deploy-staging]
  if: needs.release-please.outputs.releases_created == 'true'

Zwei Bugs tauchten sofort in CI auf.

Bug 1: Image-Tagging. Der CI-Job hat ARM-Images gebaut und sie :latest für den SCP-Transfer getaggt. Die docker-compose-Datei erwartete Images mit den Tags :prod und :staging. Als Docker Compose versuchte, Container zu starten, fand es die Images nicht. Fix: explizite docker tag app-backend:latest app-backend:prod-Schritte nach dem Laden der Images auf dem Server. Zwei CI-Iterationen bis zur Lösung.

Bug 2: Git-Konflikt. Die EC2 hatte noch ein Git-Repository. Der Deploy-Job hat git pull ausgeführt, um das aktualisierte docker-compose zu holen. Aber das config/-Verzeichnis war manuell erstellt und mit -e config/ aus git clean ausgeschlossen worden. Dieses Verzeichnis war jetzt im Repo getrackt. Merge-Konflikt. Nicht automatisch auflösbar.

Die Erkenntnis

Während ich den Git-Konflikt im CI-Fehlerlog betrachtete, fing ich an, über ein anderes Problem nachzudenken: Was passiert, wenn jemand diesen Server kompromittiert? Mit einem Git-Repository da drin hätten wir ihm den kompletten Quellcode auf dem Silbertablett geliefert. Alle Anwendungslogik, die Konfigurationsmuster, die Service-Struktur — fertig verpackt und bereit zur Analyse.

Das ist der eigentliche Grund, Quellcode von einem Produktionsserver zu trennen. Nicht Ordnung. Sicherheit.

Der Server baut nichts. Er braucht exakt fünf Dinge: die docker-compose-Datei, die Prometheus-Konfiguration, die Environment-Config-JSONs, die nginx-Vhost-Configs und die Secrets.

Diese fünf Dinge per SCP übertragen. Alles andere entfernen. Ein Produktionsserver ist keine Entwicklungsumgebung. Er sollte nicht wissen, wie man das baut, was er ausführt. Der Quellcode gehört in die Versionsverwaltung — nicht auf jeder Maschine exponiert, die das Ergebnis ausführen muss.

---

Die unerwartete Bugsuche

Während sich die CI-Pipeline stabilisierte, haben wir uns die E2E-Testabdeckung angesehen, um zu definieren, was die Staging-Smoke-Tests prüfen sollen. Diese Untersuchung hat zu einer unangenehmen Entdeckung geführt: Das war das erste Mal, dass wir versucht haben, einen Customer und eine Campaign von Hand im Admin-Panel zu erstellen. Nicht über ein Seed-Skript — manuell, über die UI.

Es hat nicht funktioniert. Acht Formulare waren kaputt.

Customer-Erstellung kaputt. Campaign-Erstellung kaputt. User-CRUD kaputt. Export-Generierung kaputt.

Die Ursache: Eine ts-rest-React-Query-v5-Migration von vor Monaten hatte verändert, wie Mutation-Calls strukturiert sein müssen:

// Kaputt: übergibt formData direkt
await createCustomer.mutateAsync(formData);

// Korrekt: wrapped in { body }
await createCustomer.mutateAsync({ body: formData });

Alle acht Call-Sites hatten das alte Pattern. Keiner war aufgefallen, weil die E2E-Tests ein Seed-Skript zum Erstellen von Testdaten nutzten — die Erstellungs-Formulare wurden nie direkt getestet. Die Features existierten, die Tests haben bestanden, und die Formulare haben still nichts erstellt.

Die Frage, die hängen bleibt: Warum haben die E2E-Tests das nicht gefunden? Sie haben nur den Happy Path mit vorab geseedeten Daten getestet. Die Erstellungs-Flows wurden als funktionierend angenommen, weil sie vor der React-Query-Migration funktioniert hatten. Staging als echte Vor-Production-Umgebung hinzuzufügen — eine, in der man das Produkt wirklich ausprobiert, bevor man deployed — war das, was es schließlich ans Licht gebracht hat.

Infrastrukturarbeit legt Anwendungsbugs frei. Man fügt eine Staging-Umgebung hinzu, fängt an, Verhalten systematisch zu verifizieren, und findet Dinge, die Production nie an die Oberfläche gebracht hat — weil niemand end-to-end geprüft hat.

---

Der Endzustand

Eine EC2. Sieben Container. 72 KB Konfiguration. Ein Docker-Image, einmal auf ARM gebaut, überall eingesetzt.

Die Pipeline läuft end-to-end ohne manuellen Eingriff. Ein Merge auf main baut das Image, deployed auf Staging, führt Smoke-Tests aus (Health Check, Login, Dashboard-Load, API-Response, Container-Status) — und nur wenn alle fünf bestehen, wird auf Production deployed und dort verifiziert.

Vorher:

• 2 EC2-Instanzen, verschiedene CPU-Architekturen
• 2 CI/CD-Workflows, 2 separate Deploy-Targets
• VITE-Variablen beim Build eingebacken = separate Images pro Umgebung
• Quellcode auf dem Produktionsserver geklont
• ~60 $/Monat

Nachher:

• 1 EC2, 7 Container, ARM durchgehend
• 1 CI/CD-Pipeline, Staging sichert Production ab
• 1 Docker-Image, Runtime-Config via JSON
• 72 KB Dateien auf dem Server, kein Quellcode
• ~40 $/Monat (die Demo-EC2 abschalten bringt die vollen 20 $ Ersparnis)

Was wir aufgegeben haben: Testen auf x86 vor dem Deploy auf ARM. In der Praxis war das nie bedeutsam — die Demo-Instanz war zu veraltet, um irgendetwas Echtes abzufangen. Echtes Staging auf derselben Hardware wie Production ist das klar Bessere.

---

Was das über Agentic-Infrastrukturarbeit sagt

Das Bemerkenswerteste dieser Session war nicht das vereinheitlichte docker-compose oder das Runtime-Config-Refactoring. Es war die Erkenntnis über Quellcode auf dem Server — und die kam davon, dass ich über die Angriffsfläche nachgedacht habe, nicht aus dem Plan.

Das ist die eigentliche Arbeitsteilung. Die KI hat 50+ Dateiänderungen über 7 Phasen verfolgt, drei parallele Refactorings koordiniert, sich per SSH in Production eingeloggt, um SQL-Migrationen auszuführen, und zwei CI-Fehler diagnostiziert, indem sie GitHub-Actions-Logs gelesen hat. Ich hätte das alles nicht parallel machen können, ohne den Überblick zu verlieren. Aber ich konnte darüber nachdenken, was es bedeutet, Quellcode auf einem Server zu haben, der kompromittiert werden könnte.

Die KI führt in einem Ausmaß und einer Parallelität aus, die wirklich über das hinausgeht, was ich alleine kann. Ich bringe das architektonische Urteilsvermögen und die Risikoeinschätzung ein, die nicht automatisch laufen sollten. Die Frage, wo man diese Grenze bei echter Infrastruktur zieht, ist es wert, sorgfältig darüber nachzudenken — aber für ein Nebenprojekt ohne Kundendaten lautete die Antwort: genau hinschauen, Ergebnisse verifizieren und der Ausführung vertrauen.

Diese Session hat etwa 4 Stunden gedauert. Es manuell zu machen — die CI-Pipeline schreiben, 20+ Dateien für Runtime-Config aktualisieren, die SQL-Migrationen durchführen, zwei CI-Fehler debuggen und die acht kaputten Mutations entdecken — wären zwei oder drei Tage fokussierter Arbeit gewesen. Ein Teil davon wäre auf unbestimmte Zeit verschoben worden.

Infrastrukturkonsolidierung ist unspektakulär. Sie liefert keine Features, taucht in keinem Changelog auf, den irgendjemand liest, und die gewonnene Übersicht ist nur für die sichtbar, die das System wirklich pflegen. Agentic Tooling macht es möglich, diese Arbeit zu erledigen, wenn sie gebraucht wird — nicht wenn man endlich einen Maintenance-Sprint dafür rechtfertigen kann. Ein Teil davon wäre sonst nie gemacht worden.