Blog · Agenturpraxis ·
Vibe-Coding-Website veröffentlichen: Was nach dem Prototyp kommt
Eine Vibe-Coding-Website zu veröffentlichen bedeutet, den erzeugten Code auf einer passenden Laufzeit bereitzustellen, eine eigene Domain mit HTTPS anzubinden und die Kundenfunktionen zu prüfen. Für Agenturen gehört noch etwas dazu: festzulegen, wer Updates, Störungen und Wiederherstellung übernimmt. Der sichtbare Prototyp beantwortet diese Betriebsfragen noch nicht.
Welches Hosting braucht das Projekt?
Entscheidend ist der erzeugte Code. Prüfen Sie Build-Skripte, Framework-Konfiguration, Serverfunktionen und externe Dienste. Der Name des KI-Werkzeugs reicht als Hosting-Anforderung nicht aus.
| Projekt | Benötigt | Offene Verantwortung |
|---|---|---|
| Statische HTML-, CSS- und JavaScript-Dateien | Statisches Hosting | Domain, Auslieferung, Releases |
| Statisches Frontend mit API, Login oder Datenbankdienst | Statisches Hosting plus erreichbare Backend-Dienste | Zusätzlich Zugriffsrechte, Daten, API-Betrieb |
| Serverseitiges Rendering oder Serverfunktionen | Eine zum Framework passende Serverlaufzeit | Zusätzlich Laufzeit, Skalierung und Server-Updates |
Diese Grenze verändert sich mit den Werkzeugen. Laut Lovable-Dokumentation verwenden neue Projekte seit dem 13. Mai 2026 TanStack Start mit Servercode; ältere React-und-Vite-Projekte erzeugen statische Dateien. Auch bei Next.js gilt: Ein statischer Export unterstützt nicht jede Funktion, etwa Server Actions oder anfrageabhängige Verarbeitung. Ein Quellcode-Export ist deshalb noch kein Nachweis für statisches Hosting.
Beispiel: eine statische Vite-Website
Angenommen, eine Agentur hat eine Unternehmenswebsite mit Startseite, Leistungsseiten und Kontaktformular erstellt. Sie verwendet Vite ohne SSR. Das Formular sendet an einen separat betriebenen HTTPS-Endpunkt. Dies ist ein hypothetisches Arbeitsbeispiel, kein getestetes Kundendeployment.
Mit passender Node-Version, vorhandenem package-lock.json und den
üblichen Vite-Skripten lautet der lokale Ablauf:
npm ci
npm run build
npm run preview
Vite legt den Build standardmäßig in dist/ ab. Prüfen Sie den
tatsächlichen Ausgabeordner in der Projektkonfiguration.
Vite Preview dient der
lokalen Prüfung, nicht als Produktionsserver. Für dieses Beispiel wird
anschließend der Inhalt von dist/ als zusammengehöriges Release beim
statischen Host bereitgestellt. Der Formular-Endpunkt muss unabhängig davon
verfügbar sein.
Eigene Domain, DNS und HTTPS
Bestimmen Sie zuerst die öffentliche Hauptadresse, etwa
www.example.com, und den Domaininhaber. Dokumentieren Sie Registrar,
DNS-Zugriff und Verlängerungsverantwortung. Setzen Sie die vom Host verlangten A-,
AAAA- oder CNAME-Einträge; bestehende Mail-Einträge bleiben erhalten.
DNS-Änderungen erreichen Nutzer abhängig von zwischengespeicherten Antworten und ihrer TTL. Halten Sie die bisherige Website während des Übergangs verfügbar. Prüfen Sie danach Hauptadresse, Weiterleitung der zweiten Namensvariante, HTTP-zu-HTTPS-Weiterleitung und Zertifikat für jeden öffentlich verwendeten Namen. Legen Sie fest, wer die automatische Erneuerung überwacht. Die Grundlagen erklären unsere Seiten zu DNS, Zertifikaten und TLS-Terminierung.
Der Launch-Check
Prüfen Sie den veröffentlichten Build unter seiner endgültigen Domain. Eine funktionierende Editor-Vorschau ersetzt diese Abnahme nicht:
- Seiten und Pfade: Jede wichtige Unterseite direkt öffnen und neu laden. Clientseitige Navigation kann fehlende Hosting-Regeln verdecken. Bei einer SPA bekannte Routen gezielt behandeln; ein pauschaler Fallback darf fehlende Bilder und Skripte nicht durch HTML mit Status 200 ersetzen.
- Fehlerfälle: Eine unbekannte URL und eine fehlende Datei abrufen. Für nicht vorhandene Inhalte eine sinnvolle Fehlerseite und passenden HTTP-Status vorsehen. Die Weiterleitung auf die Startseite erklärt den Fehler nicht.
- Assets: Bilder, Schriften, CSS und JavaScript auf Mobilgeräten prüfen. Basis-Pfad und Großschreibung müssen zur Bereitstellung passen. In der Browserkonsole und Netzwerkansicht nach fehlgeschlagenen Anfragen suchen.
- Formular: Eine eindeutig bezeichnete Testnachricht bis zum echten Empfänger verfolgen. Leere Felder, ungültige Eingaben, Serverfehler und doppelte Klicks prüfen. Erfolg erst anzeigen, wenn der Endpunkt den vorgesehenen Erfolg bestätigt.
- Bedienung: Navigation und Formular mit Tastatur bedienen; Beschriftungen, sichtbaren Fokus, lesbare Fehler und kleine Ansichten prüfen. Ein schöner Screenshot belegt keine zugängliche Website.
-
Auffindbarkeit: Seitentitel, Beschreibungen, kanonische URLs
und interne Links kontrollieren. Versehentliche
noindex-Anweisungen entfernen. Prüfen, welcher Text im ausgelieferten HTML steht und welcher erst durch JavaScript erscheint.
Geheimnisse bleiben auf dem Server
Alles, was der Browser erhält, kann ein Besucher lesen. Bei Vite werden verwendete
VITE_*-Variablen in den Client-Build übernommen. Darin gehören keine
Datenbankpasswörter, privaten API-Schlüssel oder Service-Zugangsdaten. Eine lokale
.env-Datei macht einen eingebetteten Wert nicht geheim. Die
Vite-Dokumentation zu Umgebungsvariablen
beschreibt diese Grenze ausdrücklich.
Prüfen Sie Quellcode und fertige Dateien auf versehentlich enthaltene Geheimnisse. Öffentlich vorgesehene Client-Kennungen ersetzen keine serverseitigen Zugriffsregeln. Ein Formular-Endpunkt braucht Eingabeprüfung und Missbrauchsschutz; eine versteckte Schaltfläche ist keine Berechtigungsprüfung. Wird ein Geheimnis veröffentlicht, muss es widerrufen und ersetzt werden. Nur den nächsten Build zu bereinigen genügt nicht.
Rollback ist keine Datenwiederherstellung
Halten Sie das vorherige vollständige Release samt zugehöriger Konfiguration bereit. Definieren Sie einen klaren Auslöser für die Rückkehr, etwa ein defektes Kontaktformular, und üben Sie den Wechsel vor der ersten Kundenübergabe. Kontrollieren Sie danach erneut die öffentliche URL und betroffene Funktionen. Berücksichtigen Sie dabei Caches und bereits geöffnete Browserfenster.
Ein Deployment-Rollback stellt frühere Dateien oder Anwendungsversionen wieder bereit. Er nimmt keine versendete Nachricht zurück und repariert keine gelöschten Datensätze. Sobald Daten gespeichert werden, brauchen diese einen eigenen Sicherungs- und Wiederherstellungsplan. Datenbankänderungen müssen außerdem mit der zurückgerollten Anwendung zusammenpassen.
Wer übernimmt nach der Übergabe?
Geben Sie dem Kunden eine kurze Betriebsübersicht mit benannten Verantwortlichen. Sie gehört zur Projektabnahme und sollte fünf Fragen beantworten:
- Wem gehören Domain, Repository und Anbieter-Konten, und wer kann Zugänge wiederherstellen?
- Wer gibt Änderungen frei, veröffentlicht sie und löst einen Rollback aus?
- Wer überwacht Website, Zertifikate und Formularzustellung, und wohin gehen Störungsmeldungen?
- Wer aktualisiert Abhängigkeiten, prüft Sicherheitsmeldungen und betreut angebundene Dienste?
- Was wird gesichert, wie wird die Wiederherstellung geprüft, und wie erfolgt ein Anbieterwechsel?
Tragen Sie vereinbarte Reaktionszeiten, laufende Kosten und ausgeschlossene Leistungen konkret ein. Die Zusage „Wir kümmern uns“ wird erst durch diese Zuständigkeiten belastbar.
Wo obhut ansetzt
obhut entwickelt Hosting für Webdesign- und Vibe-Coding-Agenturen: Gestaltung und Kundenprojekt bleiben bei der Agentur, die Bereitstellung bekommt eine gemeinsame Grundlage. Statische Deployments und Rollback sind implementiert. Der aktuelle Betriebsstand ist ein interner Pilot; eine öffentliche Beta ist noch nicht verfügbar. Managed Backends, Datenbanken und beliebige Serveranwendungen gehören nicht zum aktuellen Angebot.
Für ein erstes Gespräch genügt ein konkretes Projekt mit Framework, Build-Ausgabe, Domain und externen Diensten. Daraus lässt sich die passende Aufteilung der Betriebsverantwortung ableiten.
