Zurück zum Blog
Vibe CodingHostingDeploymentCloud

Vibe-Coding-App hosten: Vom localhost ins Internet

Auf deinem Rechner läuft die App. Du öffnest localhost, klickst dich durch alle Funktionen und bist zum ersten Mal wirklich zufrieden. Dann schickst du den Link an jemanden – und merkst: Für alle anderen führt localhost ebenfalls auf den eigenen Rechner. Nicht auf deinen.

An diesem Punkt beginnt Hosting. In Folge 006 von Kontext.FM sprechen Kai und Trutz darüber, wie aus einem lokalen Vibe-Coding-Projekt eine erreichbare Anwendung wird: mit Git als Sicherheitsnetz, optional mit Docker und vor allem mit einer bewussten Entscheidung darüber, wer den Betrieb übernimmt.

Die wichtigste Frage lautet dabei nicht: „Ist Vercel, Netlify oder ein eigener Server am besten?“ Sie lautet: Wie viel Hausmeister möchtest du für deine App sein? Je mehr ein Anbieter für dich erledigt, desto weniger musst du dich um Betriebssysteme, Updates, Zertifikate und Neustarts kümmern. Dafür gibst du Kontrolle ab und bezahlst bei wachsender Nutzung möglicherweise mehr.

Muss deine App überhaupt ins Internet?

Veröffentlichen fühlt sich wie der natürliche nächste Schritt an. Für viele Mikro-Tools ist es trotzdem die falsche Entscheidung.

Wenn nur du das Tool verwendest, es mit sensiblen lokalen Dateien arbeitet und keine dauerhaften Aufgaben ausführen muss, darf es auf deinem Rechner bleiben. Damit entfallen öffentlich erreichbare Zugänge, Benutzerkonten, Hostingkosten und ein großer Teil der Sicherheitsarbeit.

Hosting wird sinnvoll, wenn mindestens einer dieser Punkte zutrifft:

  • Andere Menschen sollen die App ohne eigenes Setup verwenden.
  • Eine öffentliche URL wird für eine Präsentation oder einen Test benötigt.
  • Die Anwendung soll auch laufen, wenn dein Rechner ausgeschaltet ist.
  • Externe Dienste müssen deine App über Webhooks oder APIs erreichen.
  • Ein geplanter Job soll regelmäßig im Hintergrund ausgeführt werden.
  • Daten sollen zwischen mehreren Nutzern oder Geräten synchronisiert werden.

Formuliere den Grund möglichst konkret. „Meine Vereinskollegen sollen Termine über eine URL eintragen“ führt zu einer besseren Architekturentscheidung als „Die App soll jetzt professionell werden“.

Das mentale Modell: Sechs Bausteine statt eines Servers

Eine veröffentlichte App besteht selten nur aus „Hosting“. Für die Entscheidung helfen sechs getrennte Bausteine:

  1. Code: Die Dateien deines Projekts, idealerweise in einem Git-Repository.
  2. Build: Ein Prozess, der aus dem Quellcode die auslieferbare Anwendung erzeugt.
  3. Runtime: Die Umgebung, in der der Code läuft – zum Beispiel Browser, Node.js oder Python.
  4. Daten: Datenbank, Dateispeicher und Backups.
  5. Zugang: Öffentliche URL, Domain, DNS und HTTPS.
  6. Konfiguration: API-Keys, Datenbankadressen und andere Umgebungsvariablen.

Bei einem einfachen Browser-Tool fallen einige Ebenen fast weg: Die Plattform baut statische Dateien und liefert sie über eine URL aus. Bei einer Anwendung mit Login, Datenbank, Dateiupload und Hintergrundjobs brauchst du mehrere Dienste oder eine Plattform, die diese Bausteine kombiniert.

Git verbindet den lokalen und den veröffentlichten Stand. Wenn du mit Commits noch unsicher bist, beginne mit dem Artikel Git-Befehle für Einsteiger. Für das Hosting reicht als mentales Modell: Ein funktionierender Commit ist ein klar benannter Stand, den eine Plattform bauen und ausliefern kann.

Managed-Plattformen machen daraus einen sehr kurzen Ablauf:

lokal testen → committen → zu GitHub pushen → automatisch bauen → Vorschau prüfen → veröffentlichen

Vercel erstellt bei einer Git-Anbindung automatisch Deployments aus Branches und unterscheidet zwischen Vorschau und Produktion. Netlify beschreibt denselben Grundablauf als Continuous Deployment: Repository verbinden, Build konfigurieren und bei neuen Pushes automatisch ausliefern. Die Details stehen in den offiziellen Dokumentationen von Vercel und Netlify.

Die wichtigste Trennlinie: Aufruf oder Dauerbetrieb?

Bevor du einen Anbieter auswählst, kläre, wie deine App arbeitet.

Die App reagiert auf einen Aufruf

Eine Webseite wird geladen, ein Formular abgeschickt oder eine API-Funktion kurz aufgerufen. Danach ist die Arbeit erledigt. In diese Kategorie fallen:

  • statische Webseiten und Single-Page-Apps;
  • Astro-, React- oder ähnliche Frontends;
  • kleine API-Endpunkte;
  • Formulare und Webhooks;
  • Funktionen, die nur bei einer Anfrage kurz laufen.

Für diesen Fall sind Plattformen wie Netlify, Vercel oder Cloudflare Pages ein naheliegender Einstieg. Du verbindest das Repository, gibst gegebenenfalls Build-Befehl und Ausgabeverzeichnis an und erhältst eine öffentliche URL. Cloudflare Pages kann bei angebundenen GitHub- oder GitLab-Repositories ebenfalls automatisch nach einem Push deployen und Vorschau-URLs für Branches erzeugen, wie die Pages-Dokumentation erklärt.

Die App muss unabhängig von einem Aufruf arbeiten

Ein Prozess soll dauerhaft laufen, Nachrichten aus einer Warteschlange abarbeiten oder jeden Morgen einen Job starten. Beispiele:

  • ein Bot, der ständig auf neue Nachrichten wartet;
  • ein Hintergrundprozess für längere Aufgaben;
  • ein Worker, der eine Warteschlange verarbeitet;
  • ein eigener API-Server mit dauerhaftem Prozess;
  • ein geplanter Import oder Report.

Dann brauchst du eine Plattform, die solche Dienste ausdrücklich unterstützt, oder einen eigenen Server. Render unterscheidet beispielsweise zwischen Web Services, Background Workern und Cron Jobs. Railway kann einen Dienst aus einem GitHub-Repository, einem lokalen Verzeichnis oder einem Docker-Image starten. Prüfe vor der Auswahl die aktuellen Render-Servicearten beziehungsweise die Railway-Service-Dokumentation.

Die Grenzen zwischen den Kategorien sind nicht absolut. Viele Plattformen bieten statische Seiten, kurzlebige Funktionen und geplante Jobs nebeneinander an. Die Trennung zwingt dich aber, das Verhalten deiner App zu beschreiben, bevor ein Coding-Agent einfach irgendeinen Anbieter auswählt.

Vier Hosting-Wege und wann sie passen

1. Kurz teilen: Tunnel vom eigenen Rechner

Für einen zeitlich begrenzten Test kannst du eine lokal laufende Anwendung über einen Tunnel erreichbar machen. Bei Cloudflare Tunnel baut das Programm cloudflared eine ausgehende Verbindung zum Cloudflare-Netzwerk auf. Dadurch muss nicht einfach ein eingehender Port im Router geöffnet werden. Cloudflare erklärt dieses Verbindungsmodell in der Tunnel-Dokumentation.

Das ist praktisch für eine Demo oder einen Test mit wenigen Personen. Es ist aber noch kein zuverlässiger Produktionsbetrieb:

  • Dein Rechner und deine Internetverbindung müssen verfügbar bleiben.
  • Du bist weiterhin für Anwendung, Updates und Daten verantwortlich.
  • Eine öffentliche URL macht auch einen Prototypen zu einem erreichbaren Ziel.
  • Authentifizierung und Berechtigungen werden durch den Tunnel nicht automatisch gelöst.

Nutze diesen Weg, wenn du etwas kurz zeigen möchtest – nicht als stillschweigenden Dauerbetrieb für eine wichtige Anwendung.

2. Managed Platform: Der beste Standard für den Einstieg

Für eine Webseite oder typische kleine Web-App ist eine Managed Platform meist der kleinste sinnvolle Schritt. Der Anbieter übernimmt den Build, die Auslieferung, HTTPS und einen großen Teil der Laufzeitumgebung. Häufig bekommst du außerdem Deploy-Logs, Vorschau-URLs und eine Historie früherer Versionen.

Dieser Weg passt, wenn du dich auf die App konzentrieren möchtest und mit den technischen Grenzen der Plattform leben kannst. Du brauchst weiterhin:

  • einen funktionierenden Build;
  • eine klare Trennung zwischen Frontend und geheimen Serverfunktionen;
  • eine Lösung für Daten und Dateiuploads;
  • Monitoring für Fehler;
  • ein Verständnis der Abrechnung.

Managed bedeutet nicht verantwortungslos. Die Plattform hält ihre Infrastruktur am Laufen. Ob deine App Zugriffsrechte korrekt prüft, Daten sinnvoll sichert und externe APIs begrenzt, bleibt deine Aufgabe.

3. Managed Backend oder dauerhaft laufender Dienst

Sobald eine App Login, Datenbank, Dateispeicher oder Hintergrundprozesse benötigt, kannst du spezialisierte Dienste kombinieren.

Supabase stellt pro Projekt eine PostgreSQL-Datenbank bereit und baut darauf unter anderem Authentifizierung und Storage auf. Es ist damit eher ein Backend-Baukasten als ein Ersatz für das Frontend-Hosting. Die Supabase-Dokumentation beschreibt auch, welche Backup-Funktionen vom gewählten Tarif abhängen.

Render oder Railway können wiederum einen API-Server oder Worker aus deinem Repository starten. Diese Kombination ist für viele kleine Apps übersichtlicher als ein eigener Server: Frontend bei einer Web-Plattform, Daten in einem Managed Backend und ein dauerhafter Prozess nur dann, wenn die Anwendung ihn wirklich braucht.

Jeder zusätzliche Dienst erzeugt allerdings eine weitere Verbindung, Rechnung und Fehlerquelle. Baue nicht vorsorglich fünf Plattformen ein. Starte mit der kleinsten Architektur, die die aktuelle Aufgabe erfüllt.

4. Eigener Server: Maximale Kontrolle, dauerhafte Verantwortung

Ein virtueller Server – oft VPS genannt – ist ein gemieteter Rechner im Rechenzentrum. Du kannst dort fast alles installieren und mehrere Anwendungen gemeinsam betreiben. Die monatlichen Ressourcen sind meist gut nachvollziehbar, und du bestimmst selbst über Betriebssystem, Datenbank und Netzwerk.

Dafür bist du der Hausmeister:

  • Sicherheitsupdates installieren;
  • Firewall und SSH-Zugänge absichern;
  • HTTPS und Domains konfigurieren;
  • Prozesse nach Abstürzen oder Neustarts automatisch starten;
  • Speicherplatz, Arbeitsspeicher und Logs überwachen;
  • Backups erstellen und ihre Wiederherstellung testen.

Ein Coding-Agent kann die Einrichtung beschleunigen. Er übernimmt aber nicht die Verantwortung für die nächsten zwei Jahre. Ein Server, den niemand pflegt, wird nicht dadurch sicher, dass die ursprüngliche Installation elegant automatisiert war.

Für das erste öffentliche Projekt ist ein VPS deshalb selten die beste Wahl. Er wird interessant, wenn du bewusst mehr Kontrolle brauchst, mehrere dauerhaft laufende Dienste bündeln möchtest oder die Grenzen einer Managed Platform konkret benennen kannst.

Hyperscaler wie AWS, Azure oder Google Cloud sind noch einmal etwas anderes: Dort mietest du nicht einfach einen größeren Server, sondern kombinierst viele einzelne Infrastrukturbausteine. Das ist sinnvoll, wenn du bestimmte Managed Services, Skalierungsmöglichkeiten oder Unternehmensvorgaben brauchst. Es ist aber nicht automatisch der nächste Schritt nach localhost.

Docker löst Verpackung, nicht Hosting

Docker wird in Hosting-Diskussionen schnell mit einem Server verwechselt. Ein Container ist jedoch zunächst eine reproduzierbare Laufzeitverpackung für deine Anwendung. Ein Dockerfile beschreibt, wie ein Image gebaut wird. Eine compose.yaml kann mehrere zusammengehörige Dienste wie Web-App, API und Datenbank konfigurieren.

Docker Compose ist laut Docker-Dokumentation dafür gedacht, mehrere Container und ihre Konfiguration gemeinsam zu definieren. Das hilft, wenn dein lokaler Aufbau und die spätere Serverumgebung möglichst ähnlich sein sollen.

Docker ist sinnvoll, wenn:

  • mehrere Prozesse oder Dienste zusammenspielen;
  • die App auf unterschiedlichen Rechnern gleich laufen soll;
  • dein Zielanbieter Docker-Images erwartet;
  • du später zwischen Anbietern wechseln können möchtest.

Docker ist unnötiger Ballast, wenn du lediglich eine einzelne HTML-Datei oder eine statisch gebaute Seite veröffentlichst. Es nimmt dir außerdem weder Backups noch Updates, Monitoring oder eine sichere Konfiguration ab.

Secrets: Der Teil, den du vor dem ersten Deploy klären musst

Ein API-Key ist praktisch eine Kreditkarte im Textformat. Wer ihn besitzt, kann im Rahmen seiner Rechte und Limits Anfragen auf deine Rechnung stellen.

Lokal landen solche Werte häufig in einer .env-Datei. Diese Datei gehört in .gitignore und niemals in einen Commit. Beim Hosting trägst du die Werte in der Plattform als Environment Variables oder Secrets ein. Vercel speichert solche Variablen außerhalb des Quellcodes und kann sie nach Umgebungen wie Development, Preview und Production trennen; Netlify empfiehlt ebenfalls, lokale .env-Werte in die Build-Umgebung zu importieren, statt die Datei ins Repository zu legen. Siehe dazu die Dokumentationen zu Vercel Environment Variables und Netlify Environment Variables.

Eine wichtige Grenze bleibt: Alles, was dein Frontend an den Browser ausliefert, kann ein Besucher untersuchen. Ein geheimer Schlüssel darf deshalb nicht durch JavaScript im Browser direkt verwendet werden. Wenn eine fremde API einen geheimen Schlüssel verlangt, gehört der Aufruf in eine Serverfunktion oder ein Backend.

Ist ein Schlüssel bereits in GitHub gelandet, reicht Löschen aus der aktuellen Datei nicht aus. Er kann weiterhin in der Historie stehen. Der erste Schritt ist dann, den Schlüssel beim Anbieter zu widerrufen oder zu rotieren. Genau das empfiehlt auch GitHub in der Anleitung zum Entfernen sensibler Daten.

Der sichere Veröffentlichungsablauf

Arbeite nicht mit dem Prompt „Mach die App jetzt live“ und überlasse dem Agenten alle Entscheidungen. Verwende einen Ablauf, dessen Zwischenschritte du prüfen kannst.

  1. Verhalten beschreiben: Festhalten, ob die App nur auf Anfragen reagiert, dauerhaft laufen muss, Daten speichert oder Dateien verarbeitet.
  2. Lokalen Stand sichern: Tests ausführen, Änderungen prüfen und einen sauberen Git-Commit erstellen.
  3. Kleinste Plattform wählen: Statische Plattform, Managed Service, Backend-Baukasten oder bewusst ein VPS.
  4. Repository verbinden: Nur dem benötigten Repository Zugriff geben.
  5. Build konfigurieren: Installationsbefehl, Build-Befehl, Ausgabeverzeichnis und gegebenenfalls Startkommando prüfen.
  6. Secrets getrennt hinterlegen: Werte für Preview und Production bewusst setzen.
  7. Vorschau testen: Kernabläufe mit anonymisierten Testdaten durchspielen und Logs auf Fehler prüfen.
  8. Produktion veröffentlichen: Erst danach den Produktionsbranch oder die eigene Domain verbinden.
  9. Betrieb absichern: Kostenwarnungen, Rate Limits, Backups und Fehlerüberwachung konfigurieren.
  10. Rückweg testen: Wissen, wie du ein früheres Deployment aktivierst oder einen fehlerhaften Commit sauber rückgängig machst.

Kostenlose Tarife sind gut für Experimente, aber kein Architekturmerkmal. Limits, enthaltene Leistungen und Preise ändern sich. Prüfe deshalb vor dem Livegang die aktuelle Preisseite des gewählten Anbieters. Bei verbrauchsabhängigen APIs brauchst du zusätzlich Rate Limits in deiner Anwendung und – soweit angeboten – Budgets, Warnungen oder Ausgabelimits beim Anbieter.

Ein Prompt für die Hosting-Entscheidung

Bevor dein Coding-Agent Dateien oder Cloud-Ressourcen verändert, lass ihn das Projekt zunächst nur analysieren:

Analysiere dieses Projekt read-only und schlage den kleinsten sinnvollen
Hosting-Aufbau vor.

Kläre dabei:
1. Wird nur eine statische Seite gebaut oder läuft ein Serverprozess?
2. Muss etwas dauerhaft im Hintergrund laufen?
3. Welche Datenbank, Dateien und externen APIs werden verwendet?
4. Welche Environment Variables sind erforderlich?
5. Welche Werte sind geheim und dürfen nie im Frontend landen?
6. Welche Build- und Startbefehle verwendet das Projekt bereits?
7. Welche Daten müssen Deployments und Neustarts überleben?
8. Welche Kosten- und Missbrauchsrisiken entstehen?

Vergleiche höchstens drei passende Optionen.
Empfiehl eine davon und begründe die Entscheidung.

Verändere noch keine Dateien, verbinde keinen Cloud-Account und führe
noch kein Deployment aus.

Der Prompt zwingt den Agenten, Architektur und Ausführung zu trennen. Erst wenn die Analyse plausibel ist, lässt du die nötigen Konfigurationsdateien ergänzen.

Die Entscheidung in einer Minute

Wenn du nicht weißt, wo du anfangen sollst, nutze diese Regeln:

  • Einzelne HTML-Datei oder statische Webseite: Netlify, Vercel oder Cloudflare Pages.
  • Web-App mit kurzen Serverfunktionen: Eine Managed Platform mit passender Functions-Laufzeit.
  • API, Bot oder Hintergrundprozess, der dauerhaft läuft: Render, Railway oder ein vergleichbarer Managed Service.
  • Login, Datenbank und Dateiupload: Managed Backend ergänzen; nicht alles im Frontend speichern.
  • Kurze Demo von deinem Rechner: Zeitlich begrenzten Tunnel prüfen.
  • Mehrere Container und bewusster Administrationswunsch: VPS oder containerfähige Plattform vergleichen.
  • Nur du brauchst das Tool: Lokal lassen und Hostingarbeit sparen.

Die richtige Lösung ist nicht die mit den meisten Logos im Architekturdiagramm. Sie ist die kleinste Lösung, deren Grenzen du verstanden hast.

Häufige Fragen

Brauche ich GitHub für das Hosting?

Nicht zwingend. Je nach Plattform werden auch GitLab, Bitbucket, ein direkter Upload oder eine CLI unterstützt. Eine Git-Anbindung ist trotzdem praktisch, weil jeder veröffentlichte Stand an einen Commit gekoppelt bleibt und Vorschau-Deployments möglich werden.

Muss ich vor dem ersten Deployment Docker lernen?

Nein. Für statische Seiten und viele Managed-Plattformen brauchst du kein eigenes Docker-Setup. Docker wird interessant, wenn deine Laufzeit besondere Abhängigkeiten hat, mehrere Dienste zusammengehören oder du eine portable Serverumgebung möchtest.

Ist eine kostenlose Hosting-Stufe für eine echte App ausreichend?

Für Prototypen und kleine Projekte oft, aber nicht garantiert. Prüfe Laufzeitlimits, Bandbreite, Datenbankgröße, Schlafmodi, Backups und Teamfunktionen beim konkreten Anbieter. Plane außerdem, was passiert, wenn die Nutzung wächst oder der Gratistarif geändert wird.

Was mache ich, wenn das Deployment die App kaputt macht?

Zuerst nicht hektisch weiterbauen. Prüfe Build- und Runtime-Logs und vergleiche das fehlerhafte Deployment mit dem letzten funktionierenden Commit. Viele Managed-Plattformen können frühere Deployments erneut aktivieren. Korrigiere anschließend den Code in Git, damit veröffentlichter Stand und Repository nicht dauerhaft auseinanderlaufen.

Fazit

Für die erste Vibe-Coding-App ist eine Managed Platform meist der vernünftige Standard. Sie reduziert den Weg von einem geprüften Git-Commit zu einer öffentlichen Vorschau auf wenige Schritte. Einen VPS solltest du nicht wählen, weil er billig oder „professionell“ wirkt, sondern weil du seine zusätzliche Kontrolle wirklich brauchst und die Wartung übernehmen möchtest.

Starte mit der Frage, ob deine App auf einen Aufruf reagiert oder dauerhaft arbeiten muss. Trenne Frontend, Daten und Secrets sauber. Veröffentliche zuerst eine Vorschau, setze Kosten- und Sicherheitsgrenzen und kenne den Weg zurück.

Folge 006 von Kontext.FM liefert dazu den Überblick aus der Praxis – von Git als Zeitmaschine über Docker bis zur Entscheidung zwischen Tunnel, Managed Platform und eigenem Server.