Claude Code hat gerade eine Landing Page für Sie erstellt. Das HTML ist sauber. Das CSS ist responsiv. JavaScript übernimmt die Interaktionen reibungslos. Die Datei liegt in Ihrem Projektverzeichnis und ist startklar.
Dann stellen Sie fest: Ihr Agent kann alles bauen, aber er kann es nicht online stellen. Der Build ist fertig. Das Deployment hat noch nicht begonnen.
So schließen Sie diese Lücke — drei Methoden zum Deployen aus Claude Code, von manuell bis Ein-Befehl.
Die Build-Deploy-Lücke
Coding-Agents sind hervorragend im Bauen. Fürs Deployment sind sie nicht gemacht.
Claude Code schreibt den Code. Führt die Tests aus. Poliert das Ergebnis. Deployment bedeutet jedoch Server, Domains, HTTPS-Zertifikate, CDN-Konfiguration — Infrastruktur, die in einer völlig anderen Welt lebt als die Terminalsitzung, in der Ihr Agent arbeitet.
Die meisten Entwickler erledigen das manuell:
- Agent baut die Seite
- Sie öffnen ein Terminal
- Sie konfigurieren Hosting (Netlify, Vercel, GitHub Pages, S3)
- Sie pushen oder laden hoch
- Sie warten auf den Build
- Sie erhalten eine URL
Ihr Agent erledigt Schritt 1. Sie erledigen Schritte 2–6. Das ist nicht agentisch — das ist eine Übergabe.
Methode 1: GitHub Pages (Manuell, Kostenlos)
GitHub Pages ist der häufigste Ansatz für statische Seiten. Ihr Agent baut das HTML. Sie pushen in ein Repo. GitHub deployt.
Einrichtung:
- GitHub-Repo erstellen
- Die Ausgabe des Agents ins Repo pushen
- GitHub Pages in den Repo-Einstellungen aktivieren
- Auf den CI-Build warten
- URL erhalten
Das funktioniert. Es ist kostenlos. Es ist versioniert. Aber es erfordert einen Git-Push für jeden Deploy — Ihr Agent braucht Repo-Zugriff, und jede Wegwerfseite erzeugt permanente Commit-Historie.
Nicht agentisch. Nur automatisierte manuelle Arbeit.
Methode 2: Manueller Cloud-Upload (S3, R2 usw.)
Direkter Upload in Cloud-Speicher:
- S3/R2-Bucket erstellen
- Öffentlichen Zugriff konfigurieren
- Static Website Hosting einrichten
- Ausgabedateien des Agents hochladen
- CORS und Caching konfigurieren
- URL erhalten
Mehr Kontrolle als GitHub Pages. Auch mehr Konfiguration. Jede Seite braucht eine Bucket-Policy-Überprüfung. Jedes Update braucht Cache-Invalidierung. Das ist Infrastrukturarbeit, die als Deployment verkleidet ist.
Methode 3: Ein-Befehl-Deploy (Der AnyCap-Weg)
Ihr Agent baut die Seite. Dann führt er einen Befehl aus:
anycap page deploy ./build/index.html --title "My Landing Page"
Das war's. Ein Befehl. Ihr Agent erhält eine Live-URL zurück. Kein Repo. Kein Bucket. Keine manuelle Konfiguration.
Was die Runtime übernimmt:
- Rendering. HTML und Markdown werden beide unterstützt. Ihr Agent gibt eines der Formate aus — die Runtime rendert es.
- Hosting. Seiten gehen sofort live. Kein Build-Schritt, keine CI-Pipeline, keine DNS-Konfiguration.
- HTTPS. Jede Seite erhält automatisch TLS. Keine Zertifikatskonfiguration.
- URL. Ihr Agent erhält eine öffentliche URL zurück. Er kann diese URL in eine Slack-Nachricht, eine E-Mail oder eine andere Seite einbetten.
Installation:
npm i -g anycap
anycap login
anycap skill install --target ~/.claude/skills/anycap-cli/
→ AnyCap kostenlos installieren — 250 Credits für neue Nutzer
Vollständiger Workflow: Bauen + Deployen in einer Sitzung
Hier ist ein vollständiger Claude Code-Workflow, der von der Idee zur Live-Seite führt:
# 1. Claude Code baut die Landing Page
# (Agent schreibt index.html, styles.css, app.js)
# 2. Hero-Bild für die Seite generieren
anycap image generate \
--prompt "a modern SaaS dashboard on a laptop, clean lighting, product photography" \
--model seedream-5 \
-o hero.jpg
# 3. Bild in die Seite einbetten
# (Agent aktualisiert das HTML, um hero.jpg zu referenzieren)
# 4. Deployen
anycap page deploy ./build/index.html \
--title "Product Launch — June 2026" \
--description "New feature announcement page"
# 5. URL zurückerhalten
# "Page deployed: https://anycap.ai/page/..."
Ihr Agent hat die Seite gebaut, die Visuals generiert, sie eingebettet und deployed — alles in einer Sitzung. Sie haben das Ergebnis beschrieben. Alles andere passierte im Agent-Loop. Das ist, was agentische KI in der Praxis bedeutet: Der Agent bleibt nicht bei „Ich hab's gebaut" stehen, sondern geht den ganzen Weg bis „es ist live."
Wann Deployen vs. Wann Speichern
Nicht alles braucht eine Live-Seite. So treffen Sie die Entscheidung:
| Deployen wenn... | Speichern wenn... |
|---|---|
| Die Seite soll öffentlich geteilt werden | Die Datei ist für den internen Gebrauch oder spätere Referenz |
| Sie eine URL brauchen, um sie jemandem zu senden | Sie persistenten Speicher für Ihren Agent benötigen |
| Die Ausgabe eine vollständige Seite ist | Die Ausgabe ein Asset ist (Bild, Video, CSV) |
| Es ein Einmal-Report, Prototyp oder eine Ankündigung ist | Es Teil eines größeren Projektbuilds ist |
Für Speicherung ohne Veröffentlichung: anycap drive upload ./report.md — die Datei geht in Cloud-Speicher und erhält einen Freigabelink, wird aber keine öffentliche Webseite. Mehr dazu in unserem Cloud-Storage-Leitfaden.
Echte Anwendungsfälle
Sofortige Changelog-Seiten
Ihr Agent zieht die neuesten Commits, generiert eine Changelog-Seite und deployt sie:
# Agent liest git log, formatiert als HTML-Changelog
anycap page deploy changelog.html --title "Changelog — Week of May 18, 2026"
Ein Befehl. Live-Changelog. Kein CMS.
Kunden-Prototypen
Ihr Agent baut einen Prototypen auf Basis einer Spezifikation. Sie deployen ihn und senden die URL an den Kunden:
anycap page deploy prototype/landing.html --title "Client Preview — Homepage Redesign v3"
Der Kunde klickt den Link. Keine Staging-Umgebung. Kein Netlify-Deploy. Nur eine URL.
Forschungsberichte
Ihr Agent recherchiert ein Thema, fasst die Ergebnisse zusammen und veröffentlicht den Bericht:
anycap search --prompt "competitor product launches Q2 2026" --citations
# Agent analysiert Ergebnisse, schreibt Bericht als HTML
anycap page deploy q2-competitive-analysis.html --title "Q2 2026 Competitive Analysis"
Recherche → Bericht → Veröffentlichen. Alles im Agent-Loop.
Der Page + Drive + Search Stack
Deployment ist am wirkungsvollsten kombiniert mit anderen Fähigkeiten:
SEARCH → Thema recherchieren
↓
CRAWL → Detaillierte Daten extrahieren
↓
IMAGE GEN → Visuals erstellen
↓
BUILD → Agent schreibt die Seite
↓
DEPLOY → Seite geht live
↓
DRIVE → Assets dauerhaft speichern
Eine CLI. Eine Sitzung. Ihr Agent recherchiert, erstellt und veröffentlicht — ohne dass Sie auch nur eine einzige Deployment-Konfiguration anfassen.
FAQ
Funktioniert das mit Markdown-Dateien?
Ja. anycap page deploy ./report.md rendert Markdown als gestylte Seite. Ihr Agent kann in dem Format schreiben, das er bevorzugt.
Kann ich eine eigene Domain verwenden?
Eigene Domains sind in kostenpflichtigen Plänen verfügbar. Kostenlose Deployments erhalten eine anycap.ai/page/...-URL.
Wie unterscheidet sich das von GitHub Pages?
GitHub Pages erfordert einen Git-Push, ein Repo und CI-Konfiguration. AnyCap Page ist ein Befehl aus der Terminalsitzung Ihres Agents — kein Repo, kein Push, keine CI. Für Agent-Workflows gebaut, nicht für manuelle Workflows.
Funktioniert das mit Cursor und Codex?
Ja. anycap page deploy verwendet dieselbe CLI für Claude Code, Cursor und Codex. Eine Installation, alle Agents.
Kann mein Agent eine bestehende Seite aktualisieren?
Ja. Deployen Sie an denselben Pfad mit aktualisiertem Inhalt, und die Seite wird aktualisiert.
Das Fazit
Claude Code kann alles bauen. Es kann es nur nicht online stellen — bis Sie ihm diese Fähigkeit geben. Die Build-Deploy-Lücke ist die letzte Meile zwischen dem, was Ihr Agent erstellt, und dem, was Ihr Team tatsächlich nutzen kann.
Schließen Sie die Lücke. Ein Befehl, Live-Seite, keine manuellen Schritte.
→ Claude Code Ein-Befehl-Deploy geben — direkt aus dem Terminal veröffentlichen
📖 Was Sie als Nächstes lesen sollten
- Wie man Web-Crawling zu Claude Code hinzufügt — Vollständiger Web-Zugriff für recherche-getriebene Builds.
- Wie man Videos mit Claude Code generiert: Der vollständige Leitfaden 2026 — Video zu Ihren agent-erstellten Seiten hinzufügen.
- KI Bild-zu-Video: Die vollständige Pipeline für Coding Agents — Visuals und Bewegung für Ihre deployte Seiten generieren.
- Wie man Claude Code Cloud-Speicher gibt — Assets speichern, bevor Sie die Seite deployen.
Verwandte Artikel
- Was ist ein Capability Runtime? — Warum eine CLI fünf separate APIs schlägt.
- Was ist ein KI-Agent? Der vollständige Entwicklerleitfaden — Die Grundlagen: Was Agents sind und der vollständige Tool-Stack.
- Agentische KI vs. Traditionelle KI: 5 wesentliche Unterschiede — Warum die Build-Deploy-Lücke genau das ist, was agentische KI löst.
Verfasst vom AnyCap-Team. Wir bauen den Capability Runtime, der Ihren Agent in einem Befehl vom Build zum Deploy bringt — keine manuellen Schritte, kein separates Hosting.