Claude Code hat dir gerade eine Landingpage gebaut. Das HTML ist sauber. Das CSS ist responsiv. Das JavaScript steuert Interaktionen flüssig. Die Datei liegt in deinem Projektverzeichnis und ist bereit.
Dann merkst du: Dein Agent kann alles bauen, aber er kann es nicht ins Netz stellen. Der Build ist fertig. Das Deployment hat noch nicht begonnen.
So schließt du diese Lücke — drei Wege, um direkt aus Claude Code zu deployen, von manuell bis per Einzeiler.
Die Lücke zwischen Build und Deployment
Coding-Agenten sind stark beim Erstellen. Für das Ausrollen sind sie nicht gemacht.
Claude Code schreibt den Code. Führt Tests aus. Poliert das Ergebnis. Aber Deployment bedeutet Server, Domains, HTTPS-Zertifikate, CDN-Konfiguration — Infrastruktur in einer anderen Welt als die Terminal-Sitzung, in der dein Agent arbeitet.
Die meisten Entwickler machen das manuell:
- Der Agent baut die Seite
- Du öffnest ein Terminal
- Du richtest Hosting ein (Netlify, Vercel, GitHub Pages, S3)
- Du pushst oder lädst hoch
- Du wartest auf den Build
- Du bekommst eine URL
Dein Agent erledigt Schritt 1. Du übernimmst Schritte 2 bis 6. Das ist nicht agentisch — das ist ein Übergabepunkt.
Methode 1: GitHub Pages (manuell, kostenlos)
GitHub Pages ist der gängigste Ansatz für statische Websites. Dein Agent baut das HTML. Du pushst es in ein Repository. GitHub übernimmt das Deployment.
Einrichtung:
- GitHub-Repository erstellen
- Die Ausgabe des Agents ins Repo pushen
- GitHub Pages in den Repository-Einstellungen aktivieren
- Auf den CI-Build warten
- Die URL abrufen
Das funktioniert. Es ist kostenlos. Es ist versioniert. Aber für jedes Deployment braucht es einen Git-Push. Das bedeutet, dein Agent braucht Repository-Zugriff und jede Wegwerfseite erzeugt dauerhafte Commit-Historie.
Nicht agentisch. Nur automatisierte Handarbeit.
Methode 2: Manueller Cloud-Upload (S3, R2 usw.)
Direktes Hochladen in Cloud-Speicher:
- Einen S3/R2-Bucket erstellen
- Öffentlichen Zugriff konfigurieren
- Statisches Website-Hosting einrichten
- Die Dateien des Agents hochladen
- CORS und Caching konfigurieren
- Die URL abrufen
Mehr Kontrolle als bei GitHub Pages. Aber auch mehr Konfiguration. Jede Seite braucht eine Prüfung der Bucket-Policy. Jedes Update braucht Cache-Invalidierung. Das ist Infrastrukturarbeit, die als Deployment getarnt ist.
Methode 3: Ein Befehl zum Deployen (der AnyCap-Weg)
Dein 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. Dein Agent bekommt eine Live-URL zurück. Kein Repo. Kein Bucket. Keine manuelle Konfiguration.
Was die Runtime übernimmt:
- Rendering. HTML und Markdown werden unterstützt. Dein Agent gibt eines von beiden aus — die Runtime rendert es.
- Hosting. Seiten gehen sofort live. Kein Build-Schritt, keine CI-Pipeline, keine DNS-Konfiguration.
- HTTPS. Jede Seite bekommt automatisch TLS. Keine Zertifikatskonfiguration.
- URL. Dein Agent erhält eine öffentliche URL zurück. Er kann sie 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
Voller Workflow: Build + Deploy in einer Sitzung
Hier ist ein kompletter Claude-Code-Workflow von der Idee bis zur Live-Seite:
# 1. Claude Code baut die Landingpage
# (Der Agent schreibt index.html, styles.css, app.js)
# 2. Ein 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. Das Bild in die Seite einbetten
# (Der Agent aktualisiert das HTML, damit hero.jpg referenziert wird)
# 4. Deployen
anycap page deploy ./build/index.html \
--title "Product Launch — June 2026" \
--description "New feature announcement page"
# 5. Die URL zurückbekommen
# "Page deployed: https://anycap.ai/page/..."
Dein Agent hat die Seite gebaut, die Visuals erzeugt, sie eingebettet und deployed — alles in einer Sitzung. Du hast das Ergebnis beschrieben. Alles andere passierte in der Agentenschleife.
Wann deployen und wann speichern
Nicht alles braucht eine Live-Seite. So triffst du die Entscheidung:
| Deployen wenn... | Speichern wenn... |
|---|---|
| Die Seite öffentlich geteilt werden soll | Die Datei intern oder als spätere Referenz dient |
| Du eine URL zum Versenden brauchst | Du persistente Speicherung für deinen Agenten brauchst |
| Das Ergebnis eine komplette Seite ist | Das Ergebnis ein Asset ist (Bild, Video, CSV) |
| Es ein Einmalbericht, Prototyp oder eine Ankündigung ist | Es Teil eines größeren Projekt-Builds ist |
Für Speicherung ohne Veröffentlichung: anycap drive upload ./report.md — die Datei landet im Cloud-Speicher und erhält einen Freigabelink, wird aber keine öffentliche Webseite.
Praxisbeispiele
Sofortige Changelog-Seiten
Dein Agent zieht die neuesten Commits, erzeugt eine Changelog-Seite und deployed sie:
# Agent liest git log und formatiert es als HTML-Changelog
anycap page deploy changelog.html --title "Changelog — Week of May 18, 2026"
Ein Befehl. Live-Changelog. Kein CMS.
Kundenprototypen
Dein Agent baut einen Prototyp auf Basis einer Spezifikation. Du deployest ihn und schickst die URL an den Kunden:
anycap page deploy prototype/landing.html --title "Client Preview — Homepage Redesign v3"
Der Kunde klickt auf den Link. Keine Staging-Umgebung. Kein Netlify-Deploy. Nur eine URL.
Research-Reports
Dein Agent recherchiert ein Thema, schreibt die Ergebnisse zusammen und veröffentlicht den Bericht:
anycap search --prompt "competitor product launches Q2 2026" --citations
# Der Agent analysiert die Ergebnisse und schreibt den Bericht als HTML
anycap page deploy q2-competitive-analysis.html --title "Q2 2026 Competitive Analysis"
Research → Bericht → Veröffentlichung. Alles in der Agentenschleife.
Der Page + Drive + Search Stack
Deployment wird am stärksten in Kombination 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. Dein Agent recherchiert, erstellt und veröffentlicht — ohne dass du eine einzige Deployment-Konfiguration anfasst.
FAQ
Funktioniert das mit Markdown-Dateien?
Ja. anycap page deploy ./report.md rendert Markdown als gestaltete Seite. Dein Agent kann im Format seiner Wahl schreiben.
Kann ich eine eigene Domain verwenden?
Eigene Domains sind in kostenpflichtigen Plänen verfügbar. Kostenlose Deployments erhalten eine anycap.ai/page/...-URL.
Worin unterscheidet sich das von GitHub Pages?
GitHub Pages erfordert einen Git-Push, ein Repo und CI-Konfiguration. AnyCap Page ist ein Befehl aus dem Terminal deines Agents — kein Repo, kein Push, kein CI. Gebaut für Agenten-Workflows, nicht für menschliche Workflows.
Funktioniert das mit Cursor und Codex?
Ja. anycap page deploy nutzt dieselbe CLI für Claude Code, Cursor und Codex. Eine Installation, alle Agenten.
Kann mein Agent eine bestehende Seite aktualisieren?
Ja. Stelle mit aktualisiertem Inhalt auf denselben Pfad erneut bereit, und die Seite wird aktualisiert.
Fazit
Claude Code kann alles bauen. Es kann es nur nicht online stellen — bis du ihm diese Fähigkeit gibst. Die Lücke zwischen Build und Deployment ist die letzte Meile zwischen dem, was dein Agent erstellt, und dem, was dein Team tatsächlich nutzen kann.
Schließe die Lücke. Ein Befehl, eine Live-Seite, keine manuellen Schritte.
→ Claude Code Ein-Befehl-Deploy geben — direkt aus dem Terminal veröffentlichen
📖 Weiterlesen
- Wie du Web-Crawling zu Claude Code hinzufügst — Voller Webzugriff für recherchestarke Builds.
- Wie man mit Claude Code Videos erzeugt: Der vollständige Leitfaden 2026 — Füge Videos zu deinen vom Agenten gebauten Seiten hinzu.
- AI Image-to-Video: Die komplette Pipeline für Coding-Agenten — Bilder und Bewegung für deine ausgelieferten Seiten erzeugen.
Verwandte Artikel
- Wie man KI-Coding-Agenten echte Fähigkeiten gibt — Überblick über den vollständigen Fähigkeits-Stack.
- Was ist eine Capability Runtime? — Warum eine CLI fünf separate APIs schlägt.
Verfasst vom AnyCap-Team. Wir bauen die Capability Runtime, die deinen Agenten mit nur einem Befehl vom Build zum Deploy bringt — ohne manuelle Schritte, ohne separates Hosting.