Deployment für Solo-Founder: Cloudflare, Vercel oder Railway?

Im Deployment-Dashboard stehen vier Dienste: blog, tool-api, dashboard und worker-daily-report. Die ersten beiden laufen bei Cloudflare, das Dashboard bei Vercel, und beim täglichen Bericht ist Railway oder Workers noch offen. Jeder Dienst stößt an eine andere Grenze: Builds, Workers-CPU, Vercel-Abrechnung oder die Frage nach Container statt Function.

Ein Solo-Unternehmen betreibt oft Content-Site, Tool, SaaS-Dashboard und geplante Jobs gleichzeitig. Entscheidend ist daher nicht, welcher Anbieter „gewinnt“, sondern welche Laufzeit zum Dienst passt und wo Kosten- und Wartungsschwellen liegen.

1. Vier Dienste stoßen an vier unterschiedliche Grenzen

blog ist eine statische Astro-Site auf Cloudflare Pages. Inhalts-, Stil- und Konfigurationsänderungen lösen Builds aus, sodass die 500 monatlichen Builds des Free-Tarifs näherkommen. 20.000 Dateien sind noch kein Problem, doch Kommentare und Suche über Pages Functions verbrauchen Workers-Kontingente.

tool-api ist eine schlanke Workers-API für Anmeldung und Persistenz. Mit wachsendem Traffic können 100.000 Requests pro Tag knapp werden, und rechenintensive Requests überschreiten möglicherweise 10 ms CPU. Workers Paid beginnt mit 5 US-Dollar pro Monat; Requests und CPU folgen einem anderen Modell als statisches Hosting.

dashboard ist eine Full-Stack-Next.js-App auf Vercel. Preview Deployments sind komfortabel, die Usage-Seite trennt aber Functions, Images, Builds, Analytics und weitere Produkte. Zusätzliche bezahlte Sitze kosten je 20 US-Dollar monatlich. Hobby enthält 4 Stunden Active CPU, 360 GB-Stunden Provisioned Memory und 1 Million Invocations.

worker-daily-report erzeugt täglich einen Bericht und versendet ihn. Workers unterstützt geplanten Code, doch lange oder rechenintensive Jobs passen nicht immer zu CPU- und Speichergrenzen. Railway kann einen Node-Prozess ausführen, verlangt dafür die Überwachung von RAM, CPU, Egress und Volumes. Hobby kostet 5 US-Dollar und enthält 5 US-Dollar Nutzung.

Die gemeinsame Regel lautet: Workloads nach Laufzeit trennen. Statische Inhalte, leichte Functions, vollständige Apps und lange Jobs müssen nicht auf derselben Plattform liegen.

2. Die wichtigsten Grenzen der vier Plattformen

2.1 Cloudflare Pages: statische Assets kostenlos, Functions im Workers-Tarif

Cloudflare Pages dient vor allem dem Hosting und der globalen Auslieferung statischer Assets. Aktuelle Free-Grenzen sind:

• 500 Builds pro Monat; Git-Pushes und manuelle Builds verbrauchen das Kontingent.
• 20.000 Dateien pro Site; bildreiche und generierte Sites müssen die Gesamtzahl beobachten.
• Maximal 25 MiB pro Asset; große Videos und Datendateien gehören in Object Storage.
• 100 Custom Domains pro Projekt im Free-Tarif.
• 20 Minuten Build-Timeout.

Requests und CPU von Pages Functions zählen zum Workers-Tarif, nicht zum statischen Pages-Kontingent:

• Statische Assets werden innerhalb der Pages-Grenzen ausgeliefert.
• Kommentare, Suche und API-Proxys verwenden Workers-Kontingente und -Preise.
• Astro- und Hugo-Sites passen gut; bei Next.js ist der aktuelle Adapter- und Runtime-Support zu prüfen.

Pages ist ein guter Start für Content-Sites und statische Tools. Viele dynamische Requests oder komplexe Berechnungen sollten als eigener Workers-Workload kalkuliert werden.

2.2 Cloudflare Workers: leichte Functions mit Request- und CPU-Grenzen

Workers ist Cloudflares Laufzeit für leichte APIs, Edge-Logik und Tool-Backends. Die aktuellen Grenzen umfassen:

• 100.000 Requests pro Tag im Free-Tarif.
• 10 ms CPU pro HTTP-Request im Free-Tarif; Wartezeit auf Netzwerk-I/O zählt nicht als CPU-Zeit.
• 5 US-Dollar monatliche Subscription für Workers Paid.
• 10 Millionen Requests pro Monat inklusive im Standard-Modell.
• 30 Millionen CPU-Millisekunden pro Monat inklusive.
• 128 MB Speicher pro Isolate in Free und Paid.

Geeignete Aufgaben:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

• Leichte APIs für Authentifizierung, Abfragen und einfache Geschäftslogik.
• Pages Functions für Kommentare oder Suche.
• API-Proxys für Cache, Routing und Autorisierung.

Ungeeignete Aufgaben:

• Lange Berichte und Batch-Verarbeitung.
• Schwere Berechnungen, große Datenmengen im Speicher oder ML-Inferenz.
• Klassische Connection Pools, die nicht zum Isolate-Modell passen.

Workers eignet sich für kleine Tool-Backends. Wachstum sollte in Requests und CPU geplant werden; dauerhafte Prozesse und ressourcenintensive Jobs benötigen eine andere Laufzeit.

2.3 Vercel: stark für Next.js, aber mehr als ein Sitz auf der Rechnung

Vercel integriert Next.js und Preview Deployments besonders eng. Hobby enthält Function-Ressourcen, andere Nutzung wird getrennt betrachtet:

• 4 Stunden Active CPU.
• 360 GB-Stunden Provisioned Memory.
• 1 Million Function Invocations.
• 0,0035 US-Dollar pro Build-CPU-Minute bei On-demand Concurrency oder Elastic Build Machines.
• 20 US-Dollar pro zusätzlichem bezahlten Team-Sitz.
• 100 Deployments pro Tag in Free und 6.000 in Pro.
• 5.000 Uploads pro Tag in Free und 40.000 in Pro.

Die Rechnung kann mehrere Kategorien enthalten:

• Functions: CPU, Speicher und Invocations.
• Images: Transformationen sowie Cache Reads und Writes.
• Builds: CPU unter kostenpflichtigen Build-Konfigurationen.
• Analytics: Web Analytics und Speed Insights.
• Observability: ereignisbasierte Überwachung und Add-ons.

Wichtige Warnzeichen:

• Viele Previews erhöhen Build-Nutzung und Deployment-Zahl; kostenpflichtige Machines oder Concurrency erzeugen Zusatzkosten.
• Image Optimization hat eigene Inklusivmengen und On-demand-Preise.
• Analytics und Observability werden ebenfalls separat bewertet.

Vercel ist ein sinnvoller Start für ein Full-Stack-Next.js-Produkt. Tarifpreis, Nutzungskategorien und Team-Sitze müssen jedoch einzeln kontrolliert werden.

2.4 Railway: Container-Laufzeit mit Ressourcenabrechnung

Railway ist eine PaaS für Dienste, Worker und Datenbanken. Subscription und Ressourcennutzung werden getrennt abgerechnet:

• Hobby kostet 5 US-Dollar, Pro 20 US-Dollar pro Monat.
• Hobby enthält 5 US-Dollar Ressourcennutzung.
• Pro enthält 20 US-Dollar Ressourcennutzung.
• RAM kostet 10 US-Dollar pro GB-Monat.
• CPU kostet 20 US-Dollar pro vCPU-Monat.
• Network Egress kostet 0,05 US-Dollar pro GB.
• Volume Storage kostet 0,15 US-Dollar pro GB-Monat.
• Free erlaubt standardmäßig bis zu 0,5 GB RAM, 1 vCPU und 0,5 GB Volume pro Dienst.

Betriebsentscheidungen bleiben notwendig:

• Tatsächliche Nutzung von RAM, CPU, Egress und Volumes überwachen.
• Ressourcen- und Log-Warnungen konfigurieren.
• Image-Retention-Zeiträume für Rollback und Rebuild kennen.
• Health Checks, Neustartverhalten und Backups definieren.

Kostenschwellen:

• Nutzung über 5 beziehungsweise 20 US-Dollar Guthaben wird als Differenz berechnet.
• Laufende Dienste verbrauchen weiter RAM, CPU und Storage.
• Egress und persistente Volumes wachsen unabhängig voneinander.

Railway passt zu Node-Diensten, Background-Jobs und Datenbanken. Es reduziert Infrastrukturarbeit, entfernt aber nicht die Verantwortung für den Dienst.

3. Entscheidungstabelle: Workload zu Plattform

3.1 Content-Sites und Dokumentation

Content-Sites bestehen überwiegend aus statischen Assets und wenigen dynamischen Funktionen.

Für Astro oder Hugo bietet Pages globale Auslieferung mit meist ausreichenden Startlimits. Mehr Details liefern die Cloudflare-Pages-Anleitung und die Cloudflare-Free-Limits.

Bei Next.js SSG sollte die aktuelle Framework-Unterstützung geprüft werden. Vercel bietet den nativen Workflow; Cloudflare bleibt für überwiegend statische Ausgabe interessant.

Kommentare und Suche können Pages Functions nutzen, gehören bei Requests und CPU aber zu Workers. Statische Auslieferung und dynamische Ausführung sind getrennte Kostenmodelle.

3.2 Statische und dynamische Tools

Generatoren und Converter können vollständig im Browser laufen; Anmeldung und persistente Daten machen daraus ein dynamisches Produkt.

Ein Browser-Tool passt zu Pages. Eine kleine API passt zu Workers, solange Requests leicht bleiben und zum Isolate-Modell passen.

Ein Full-Stack-Next.js-Tool profitiert von Vercel, verlangt aber getrennte Budgets für Previews, Images, Function-Laufzeit und Monitoring.

3.3 SaaS-Dashboards

Ein SaaS-Dashboard benötigt Anwendungslogik, Autorisierung, Datenzugriff und oft Zusammenarbeit.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Für ein Next.js-Dashboard ist Vercel der direkte Start. Function-Ausführung, Images, Preview Builds, Analytics, Observability und Sitze sind getrennt zu prüfen. Der Cloudflare-Preisvergleich ergänzt den Kontext.

Bei anderen Frameworks entscheiden aktuelle Adapter und Runtime-Funktionen. Workers passt zu Edge-Logik, Vercel zu unterstützten Serverless-Frameworks.

Datenbankhosting ist eine eigene Entscheidung. Supabase, Managed Postgres, D1 und Railway Volumes haben eigene Kosten- und Zuverlässigkeitsgrenzen.

3.4 Lange Jobs und Container-Dienste

Berichte, Dateiverarbeitung, Queue Consumer und dauerhafte APIs brauchen eine andere Laufzeit als kurze Functions.

Railway kann dauerhafte Node-Prozesse in einer vollständigen Laufzeit ausführen. Dafür müssen Limits, Logs, Health Checks, Neustarts und Backups verwaltet werden.

Ein Railway Volume speichert Daten persistent, doch Preis allein ersetzt keinen Datenbankplan. Backups und Restore-Tests bleiben nötig.

Für geplante Jobs sollten Warnung und maximales Ressourcenprofil feststehen. Ein dauerhaft laufender oder speicherintensiver Worker kann das Hobby-Guthaben überschreiten.

4. Kostenmodelle und Warnschwellen

4.1 Kostenmodell von Cloudflare

Cloudflare trennt statische Pages-Auslieferung und dynamische Workers-Ausführung.

Statische Pages-Assets:

• Statische Assets werden innerhalb der Produktlimits ohne nutzungsabhängige Transferkosten ausgeliefert.
• Nahe 500 Builds pro Monat sollten unnötige Deployments reduziert werden.
• Nahe 20.000 Dateien gehören große Assets in Object Storage.
• Pages Functions verwenden Workers-Kontingente statt eines separaten unbegrenzten Dynamic-Tarifs.

Workers-Ausführung:

• Free enthält 100.000 Requests pro Tag und 10 ms CPU pro HTTP-Request.
• Workers Paid beginnt mit 5 US-Dollar monatlicher Subscription.
• Standard enthält 10 Millionen Requests pro Monat.
• Standard enthält 30 Millionen CPU-Millisekunden pro Monat.

Warnschwellen:

• Harte Pages-Limits können weitere Builds blockieren.
• Steigende Requests oder CPU erfordern den Wechsel von Workers Free zu Paid.
• Kostenlose statische Pages-Auslieferung bedeutet nicht unbegrenzte Pages Functions.

Ein typischer Start ist Pages plus Workers Free. Der Auslöser für Paid sollte feststehen, bevor Traffic oder CPU zum Problem werden.

4.2 Kostenmodell von Vercel

Vercel trennt mehrere Infrastruktur- und Entwicklerressourcen.

Hobby-Function-Ressourcen:

• 4 Stunden Active CPU.
• 360 GB-Stunden Provisioned Memory.
• 1 Million Invocations.
• 0,0035 US-Dollar pro Build-CPU-Minute bei On-demand Concurrency oder Elastic Build Machines.

Nutzungskategorien:

• Functions: Active CPU, Provisioned Memory und Invocations.
• Images: Transformationen, Cache Reads und Cache Writes.
• Builds: Preview und Production unter kostenpflichtigen Konfigurationen.
• Analytics: Web Analytics und Speed Insights.
• Observability: Events und Monitoring.

Team-Sitze:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

• Jeder zusätzliche bezahlte Sitz kostet 20 US-Dollar pro Monat.
• Sitzkosten decken keine anderen Infrastruktur- oder Add-on-Überschreitungen.

Warnschwellen:

• Viele Previews erhöhen Build-Nutzung und Deployment-Zahlen.
• Bildverarbeitung hat eigene Inklusivmengen und Preise.
• Analytics und Observability sind separat zu prüfen.
• Function-CPU, Speicher und Invocations müssen mit dem aktuellen Tarif verglichen werden.

Die Usage-Seite sollte Kategorie für Kategorie gelesen werden. Ein effizienter Next.js-Workflow kann trotzdem eine mehrteilige Rechnung erzeugen.

4.3 Kostenmodell von Railway

Railway kombiniert Subscription und gemessene Ressourcennutzung.

Tarife und enthaltene Nutzung:

• Hobby kostet 5 US-Dollar und enthält 5 US-Dollar Nutzung.
• Pro kostet 20 US-Dollar und enthält 20 US-Dollar Nutzung.
• Free bietet pro Dienst bis zu 0,5 GB RAM, 1 vCPU, 0,5 GB Volume und ein kleines Monatsguthaben.

Ressourcenpreise:

• RAM kostet 10 US-Dollar pro GB-Monat.
• CPU kostet 20 US-Dollar pro vCPU-Monat.
• Network Egress kostet 0,05 US-Dollar pro GB.
• Volume Storage kostet 0,15 US-Dollar pro GB-Monat.
• Gelöschte Deployment-Images bleiben nur im Retention-Fenster des Tarifs verfügbar.

Warnschwellen:

• Nutzung über dem Guthaben wird als Differenz berechnet.
• Ein nicht gestoppter Dienst verbraucht weiter RAM, CPU und Storage.
• Egress und Volumes können unabhängig vom Tarif wachsen.

Railway spart VPS-Einrichtung, nicht Ressourcenüberwachung. Vor Production müssen Warnungen und Rollback-Fenster bekannt sein.

5. Wartung: Deployment-Häufigkeit, Logs, Rollback und Zusammenarbeit

Bei häufigen Änderungen werden Build- und Deployment-Quoten relevant. Zusammenarbeit bringt Sitze und Rechteverwaltung hinzu.

Deployment- und Build-Häufigkeit

• Cloudflare Pages Free erlaubt 500 Builds pro Monat und einen gleichzeitigen Build; Git-basierte Preview Builds zählen mit.
• Vercel erlaubt 100 Deployments pro Tag in Free und 6.000 in Pro; viele Previews erhöhen auch die Build-Nutzung.
• Railway veröffentlicht hier keinen gleichen Deployment-Zähler, gelöschte Images bleiben aber nur im tarifabhängigen Rollback-Fenster erhalten.

Pages-Builds und Vercel-Deployments sollten beobachtet werden, bevor sie Iterationen stoppen. Bei Vercel ist außerdem zu prüfen, ob Build Machine oder Concurrency kostenpflichtig sind.

Logs, Rollback und Team-Zugriff

• Cloudflare Pages bietet Build-Logs, Deployment-Historie und Rollbacks; aktuelle Konten- und Rechtebedingungen sind zu prüfen.
• Vercel bietet Previews, Historie, Logs, Analytics und bezahlte Sitze; zusätzliche Sitze kosten 20 US-Dollar monatlich.
• Railway bietet Logs und Metriken; Health Checks, Neustartregeln, Backups und Workspace-Zusammenarbeit müssen bewusst konfiguriert werden.

Wähle den Workflow, der wiederkehrende Arbeit am wichtigsten Dienst reduziert. Bei Next.js zählt oft Preview-Komfort, bei einer Content-Site ein vorhersehbarer statischer Build.

6. Als Nächstes: Datenbanken, Storage und CI/CD

Eine Deployment-Plattform ist nur eine Schicht des Stacks. Datenbank, Storage, CI/CD, Monitoring und Warnungen benötigen eigene Entscheidungen. Der nächste Beitrag vergleicht Supabase, Postgres, Railway Volumes und Object Storage.

Das Ziel ist nicht, möglichst wenige Anbieterlogos zu haben. Jeder Workload gehört in eine Laufzeit, deren Limits, Rechnung und Betriebsverantwortung vor wachsendem Traffic erklärbar sind.