Zuerst ein Geständnis: Ich bin kein Entwickler. Ich kann einfaches HTML schreiben, mit CSS eine Seite ganz ordentlich aussehen lassen, und ich weiß ungefähr, was eine Datenbank ist. Das war’s.
Trotzdem betreibe ich seit dieser Woche sechs Websites und kleine Apps auf meinen eigenen Domains. Da ist ein privates Finanz-Dashboard mit Datenbank hinter einem Login. Da ist ein Tool, das die Ladevorgänge der Wallbox einer Familie sammelt und daraus monatliche Belege erstellt. Dazu zwei Websites für Vereine aus der Gegend, eine persönliche Landingpage und der Blog, den du gerade liest. Alles läuft auf einem einzigen Cloudflare-Konto.
Den Code habe nicht ich geschrieben. Das haben KI-Coding-Agenten gemacht, vor allem Claude Code und Codex. Meine Aufgabe war, zu entscheiden, was ich will, zu prüfen, was zurückkommt, und ein Hosting-Setup zu wählen, das jemand wie ich tatsächlich versteht und am Laufen halten kann. Um diesen letzten Punkt geht es hier, weil er wichtiger ist, als viele glauben.
Das eigentliche Problem ist nicht das Programmieren
Wer als Marketer mit KI-Agenten experimentiert, merkt schnell: Code schreiben zu lassen ist nicht mehr das Schwierige. Du beschreibst, was du willst, und ein paar Minuten später läuft etwas auf deinem Laptop.
Schwierig wird es danach. Wo läuft das Ganze? Wer spielt die Updates am Server ein? Was passiert, wenn um 23 Uhr etwas kaputtgeht? Wie verhindere ich, dass das ganze Internet meine Finanzdaten sieht? Klassisches Webhosting beantwortet diese Fragen mit Dingen, die ich nicht kann: per SSH auf Server zugreifen, Nginx konfigurieren, Zertifikate erneuern, PHP aktualisieren, Datenbank-Backups verwalten.
Ich brauchte ein Setup, bei dem der Agent die Arbeit macht und ich trotzdem noch verstehe, was passiert.
Was ich tatsächlich verwende
Alles folgt demselben einfachen Muster:
- Workers mit statischen Assets. Jede Website ist ein Ordner mit einfachem HTML, CSS und ein bisschen JavaScript, dazu ein kleines Skript (ein „Worker“), das im Netzwerk von Cloudflare läuft. Kein Server, um den ich mich kümmern muss.
- D1 für die Datenbanken. Unter der Haube steckt SQLite. Die Daten sind also eine einzige Datei, die ich herunterladen und selbst öffnen könnte, wenn ich wollte.
- R2 für Dateien, etwa die Foto-Uploads auf einer Vereinsseite oder die Bilder auf diesem Blog.
- Cloudflare Access, um alles Private hinter einen Login zu stellen. Meine Finanz-App ist nur erreichbar, nachdem ein Code an meine eigene E-Mail-Adresse gegangen ist. Ein eigenes Login-System musste ich dafür nicht bauen.
- DNS am selben Ort. Die Domains liegen ohnehin bei Cloudflare. Eine neue Subdomain mit einem Worker zu verbinden, ist eine Zeile in einer Konfigurationsdatei.
Und das Wichtigste: Alles ist in Dateien im Projekt beschrieben. Pro Projekt gibt es eine Konfigurationsdatei, in der steht, welche Datenbank, welcher Speicher-Bucket und welche Domain verwendet werden. Ein Deploy ist ein einziger Befehl. Kein Herumklicken in Dashboards, an das sich eine Woche später niemand mehr erinnert.
Warum das so gut zu Nicht-Entwicklern passt
Ein Ort, eine Rechnung, großteils gratis. Meine Websites haben keine Millionen Besucher. Das kostenlose Kontingent deckt fast alles ab, und falls ich es je überschreite, startet der bezahlte Workers-Plan bei fünf Dollar im Monat. Ich habe nicht fünf Hosting-Anbieter mit fünf Logins und fünf Rechnungen.
Nichts zu patchen. Unter meinen Websites liegt kein Betriebssystem, für das ich verantwortlich bin. Allein das beseitigt die unangenehmste Art von Problemen für jemanden wie mich.
Agenten verstehen es. Das hat mich überrascht. Weil das ganze Setup aus Dateien besteht (eine Konfiguration, ein Datenbankschema, ein Ordner mit Seiten), kann ein KI-Agent es lesen, ändern und deployen. Wenn ich sage: „Füge eine Seite hinzu, die die Ladevorgänge vom letzten Monat zeigt“, weiß der Agent, wo die Datenbank ist, wie sie aufgebaut ist und wie er die Änderung live bringt. Ein Hosting-Setup, das in einem Web-Dashboard lebt, ist für den Agenten unsichtbar. Ein Setup in Dateien ist etwas, womit er arbeiten kann.
Zurückrollen ist eingebaut. Jeder Deploy ist eine Version. Wenn etwas kaputtgeht, ist der Weg zurück ein einziger Befehl. Bei zwei Vereinswebsites habe ich das alte Hosting sogar parallel weiterlaufen lassen: Der Worker sitzt einfach davor. Entferne ich eine Route, ist die alte Seite wieder live. Genau so ein Sicherheitsnetz willst du, wenn du nicht ganz sicher bist, ob du weißt, was du tust.
Sicherheit, die ich nicht selbst bauen musste. Access vor eine App zu stellen, war ein einziger Einrichtungsschritt. Einen sicheren Login selbst zu bauen (oder besser gesagt: darauf zu vertrauen, dass ein Agent ihn richtig baut) wäre ein viel größeres Risiko gewesen.
Was schiefgegangen ist (damit du es nicht wiederholen musst)
Zauberei ist es nicht. Ein paar Dinge haben mich erwischt, und alle stehen jetzt in den Projekten, damit weder ich noch der nächste Agent wieder darauf hereinfallen:
- Zwei Konten, ein Fehler. Ich habe ein berufliches und ein privates Cloudflare-Konto auf demselben Laptop. Ein Agent hat einmal eine Datenbank im falschen Konto angelegt, weil das Tool, das er verwendet hat, mit dem beruflichen Konto verbunden war. Jetzt steht in jedem privaten Projekt die ID des privaten Kontos in der Konfiguration. Ein Deploy ins falsche Konto schlägt damit einfach fehl.
- „Auto-Deploy“ hat nicht deployed. Eine Website sollte sich bei jedem Push auf GitHub neu deployen. Irgendwann hat sie damit einfach aufgehört, ohne jede Meldung. Die Lösung war nicht technisch, sondern eine Gewohnheit: Nach einer Änderung prüfen, welche Version live ist.
- Ein Login, der keiner war. Bei einer App hat Cloudflare die HTML-Dateien direkt ausgeliefert, noch bevor meine Login-Prüfung überhaupt lief. Die Daten dahinter waren geschützt, die Seite selbst nicht. Eine einzige Einstellung („Worker zuerst ausführen“) hat es behoben. So etwas findest du nur, wenn du wie ein Außenstehender testest.
- Fehlermeldungen lügen manchmal. Einmal behauptete das Deploy-Tool, ich sei nicht eingeloggt. Ich war es. Ein Plugin hatte einen Ordner angelegt, der es durcheinandergebracht hat. Ein Agent hat das in Minuten gefunden. Ich hätte Tage gebraucht.
Worum es eigentlich geht
Jahrzehntelang hieß „Ich bin nicht technisch“ so viel wie „Dafür brauche ich jemanden aus der IT oder eine Agentur“. Mit KI-Agenten ändert sich das, aber nur, wenn die Plattform darunter einfach genug ist, dass du den Überblick behältst. Für mich ist diese Plattform Cloudflare. Für dich ist es vielleicht eine andere.
Meine Faustregel: Wähle eine Plattform, auf der sich dein ganzes Setup in einfachen Dateien aufschreiben lässt. Dann können sowohl du als auch deine Agenten es lesen. Genau das macht aus „Der Agent hat mir ein bisschen Code geschrieben“ ein „Ich betreibe das selbst“.
Dieser Blog ist übrigens mein neuestes Experiment. Er läuft auf EmDash, einem neuen Open-Source-CMS, das auf Cloudflare läuft, und ich teste es als Alternative zu WordPress. Mehr dazu, wenn ich eine Weile damit gelebt habe.