Full-Stack Deployment auf Cloudflare: Der komplette…

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe seit 2023 12+ Full-Stack-Anwendungen mit TanStack Start auf Cloudflare Workers veröffentlicht – Auth, Billing, transaktionale E-Mails, Hintergrundjobs, WebSockets, alle laufen auf der Edge-Runtime. Das bedeutet, dass ich auch jeden schmerzhaften Teil der Pipeline debuggt habe: eine D1-Migration, die Schreibvorgänge während des Checkouts blockierte, eine Preview-Umgebung, die Produktions-Secrets leakte, ein Rollback einer Workers-Version, das die API für neun Minuten offline nahm, sowie eine Custom Domain, die die Routenkonfiguration stillschweigend umging. Jede untenstehende Config entspricht genau dem, was ich in der Produktion verwende. Jedes Limit ist mit der offiziellen Cloudflare-Dokumentation verlinkt und nicht nur behauptet, und auf jedes dieser Muster vertraue ich persönlich genug, um ein kostenpflichtiges Produkt darauf aufzubauen. TanStack Ship ist mein kommerzielles Produkt; ich benenne diesen Bias von Anfang an.

Verifizierte Quellen: Cloudflare Workers docs · Wrangler configuration · Workers environments · D1 migrations · Workers Builds (CI/CD) · Cloudflare Secrets Store · R2

Zuletzt aktualisiert: 3. Juli 2026 · Changelog

TL;DR: Ein Full-Stack-App-Deployment auf Cloudflare Workers im Jahr 2026 besteht aus einer wrangler.jsonc-Datei, einem Build-Befehl und einer CI-Pipeline, die den Unterschied zwischen Preview und Produktion kennt. Wenn Sie diese drei richtig verbinden – Multi-Environment-Config, Preview-Deployments pro Pull Request, isolierte Secrets pro Umgebung – fügt sich der Rest der Plattform von selbst ein: D1 für relationale Daten, R2 für Object Storage mit null Egress-Kosten, Queues für asynchrone Arbeit, Durable Objects für zustandsbehaftete Koordination, Workers AI für Inference. Die eigentliche Hürde ist nicht die Runtime; es ist die operative Disziplin rund um Datenbankmigrationen, Secret-Rotation, Rollbacks und Observability. Dieser Leitfaden behandelt jede Schicht an einem Ort: die Runtime, das Framework, die Config, die Pipeline, die Secrets, die Migrationen, das Rollback und die Kostenkalkulation, und schließt mit der ehrlichen Entscheidung, ob Sie die Pipeline selbst bauen oder mit einem vorgefertigten Template starten sollten.

Warum Full-Stack auf Cloudflare im Jahr 2026 bereitstellen

Noch vor drei Jahren bedeutete das Deployment einer React-App mit SSR einen Node.js-Server in einer Region, einen Load Balancer, ein CDN und eine Datenbank. Dieser Stack funktioniert immer noch und bleibt für einige Teams die richtige Antwort. Für einen Solo-Entwickler, der im Jahr 2026 SaaS ausliefert, haben sich die wirtschaftlichen Rahmenbedingungen jedoch verschoben.

Die Edge von Cloudflare führt Ihren Code in V8 isolates innerhalb der workerd-Runtime aus, und das in über 330 Städten. Es muss kein Container hochgefahren werden, keine feste Region gewählt und es gibt keine Grundkosten für Leerlauf-Instanzen. Der Cold Start liegt bei den von mir überwachten TanStack Ship-Deployments unter 50 ms. Die Plattform ist produktionsreif für die volle Bandbreite an SaaS-Lösungen – D1, R2, KV, Queues, Durable Objects, Workers AI. Die Einschränkungen liegen nicht in der Leistung, sondern in der operativen Disziplin rund um Migrationen, Secrets und Rollbacks – genau das wird in diesem Leitfaden behandelt.

Die allgemeinen Gründe für "Warum Workers" finden Sie im Cloudflare Workers Complete Production Guide. Für die Wahl des Frameworks über der Runtime lesen Sie How to Choose Your SaaS Tech Stack in 2026. Im weiteren Verlauf wird davon ausgegangen, dass Sie sich für Workers und TanStack Start entschieden haben, und es wird erklärt, wie Sie diese produktiv ausliefern.

Der Deployment-Stack – Was Sie eigentlich ausliefern

Ein Full-Stack-Cloudflare-Deployment besteht aus drei übereinanderliegenden Schichten. Zu wissen, welche Schicht was tut, macht den Unterschied aus, ob man einen zehnminütigen Ausfall in fünf Minuten oder einen sechsstündigen Ausfall in sechs Stunden debuggt.

Die Runtime-Schicht – workerd und V8 Isolates

Die unterste Schicht ist workerd, die Open-Source-Runtime auf Basis von V8. Ihr Code läuft innerhalb eines Isolates – einer leichtgewichtigen Sandbox mit geteilter Runtime –, weshalb sich der Cold Start im einstelligen Millisekundenbereich statt auf 300 ms bis 1,2 s wie bei einer containerbasierten Funktion beläuft. Das Isolate-Modell erklärt auch, was Sie nicht bekommen: kein Dateisystem, kein reines TCP, keine nativen Node-Addons. Alles, was diese Dinge benötigt, muss über ein Binding oder einen HTTP-Transport erreicht werden.

Die Framework-Schicht – TanStack Start, Vinxi, React

Die mittlere Schicht ist Ihr Framework. TanStack Start ist ein Full-Stack-React-Framework, das auf Vinxi basiert und Ihnen SSR, Streaming, dateibasiertes Routing, typsichere Server-Funktionen sowie einen Deployment-Adapter bietet, der zu einem einzigen Worker-Entrypunkt kompiliert. Wenn Sie pnpm build ausführen, erzeugt Vinxi eine dist/worker.js, die von Wrangler bereitgestellt wird. Das Framework ist verantwortlich für Routing, Loader-Funktionen, die Hydration-Boundary und den Server-Entrypunkt. Die Runtime übernimmt alles andere.

Die Binding-Schicht – D1, R2, KV, Queues, Durable Objects, AI

Die oberste Schicht sind die in Ihrer wrangler.jsonc deklarierten Bindings – sie legen fest, wie Ihr Worker auf Daten zugreift, ohne Connection-Strings verwalten zu müssen. D1 ist SQLite an der Edge. R2 ist S3-kompatibler Speicher mit null Egress-Kosten. KV ist eine eventuell konsistente, leseoptimierte globale Konfiguration. Queues entkoppeln langsame Prozesse. Durable Objects bieten Ihnen einen Single-Threaded zustandsbehafteten Actor mit transaktionalem Speicher und WebSocket-Hibernation. Workers AI führt Inference auf Cloudflare-GPUs aus, ganz ohne Schlüsselverwaltung. Jedes Binding ist ein Config-Block und ein getypter Schlüssel im Objekt env.

wrangler.jsonc – Die Single Source of Truth für Ihr Deployment

Jeder von mir bereitgestellte Produktiv-Worker wird über eine wrangler.jsonc gesteuert, die drei Umgebungen – dev, preview und production – unterstützt und isolierte Bindings sowie Secrets pro Umgebung bietet. Dies ist die absolut wichtigste Datei im Deployment und diejenige, die am ehesten als „nur eine Konfiguration“ unterschätzt wird.

Multi-Environment-Layout

Die unten stehende Struktur ist genau die, die ich in der Praxis verwende. Die Umgebung dev kommuniziert mit einer lokalen D1 und einem lokalen R2-Stub; preview wird bei jedem Pull Request erstellt; production ist die Umgebung, auf die Ihre zahlenden Kunden zugreifen.

jsonc

// wrangler.jsonc
{
  "$schema": "https://raw.githubusercontent.com/cloudflare/workers-sdk/main/packages/wrangler/config-schema.json",
  "name": "ship-app",
  "main": "./dist/worker.js",
  "compatibility_date": "2026-07-01",
  "compatibility_flags": ["nodejs_compat"],
  "observability": { "enabled": true },

  "vars": {
    "APP_VERSION": "1.0.0"
  },

  "d1_databases": [
    { "binding": "DB", "database_name": "ship-dev", "database_id": "<dev-uuid>" }
  ],
  "r2_buckets": [
    { "binding": "UPLOADS", "bucket_name": "ship-uploads-dev" }
  ],

  "env": {
    "preview": {
      "name": "ship-app-preview",
      "routes": [
        { "pattern": "preview.ship-app.dev", "custom_domain": true }
      ],
      "d1_databases": [
        { "binding": "DB", "database_name": "ship-preview", "database_id": "<preview-uuid>" }
      ],
      "vars": { "APP_VERSION": "preview" }
    },
    "production": {
      "name": "ship-app-prod",
      "routes": [
        { "pattern": "ship-app.com", "custom_domain": true },
        { "pattern": "www.ship-app.com", "custom_domain": true }
      ],
      "d1_databases": [
        { "binding": "DB", "database_name": "ship-prod", "database_id": "<prod-uuid>" }
      ],
      "r2_buckets": [
        { "binding": "UPLOADS", "bucket_name": "ship-uploads-prod" }
      ],
      "vars": { "APP_VERSION": "1.0.0" }
    }
  }
}

Zwei Details fallen dabei stärker ins Gewicht, als es den Anschein hat. Das Feld compatibility_date heftet Runtime-Semantiken an – behandeln Sie Änderungen daran wie bewusste Migrationen; es hochzusetzen, kann das Verhalten verändern. Das Setzen von observability.enabled aktiviert die Logs, die Sie sofort bei Ihrem ersten Vorfall benötigen; aktivieren Sie es an Tag eins und nicht erst, wenn Sie bereits alarmiert wurden. Die Wrangler configuration reference ist hier maßgeblich.

Bindings, Secrets und die Regel der pro-Environment-Isolation

Jedes Binding kann pro Umgebung überschrieben werden, und jedes Binding sollte das auch. Preview D1 sollte niemals das Produktions-D1 sein; das Stripe Webhook-Secret für die Preview darf niemals echte Ereignisse validieren. Die obige Config gibt Ihnen genau das. Die operative Disziplin besteht darin, diesen Schritt niemals zu überspringen.

Secrets sind von den vars getrennt. Die vars werden in der Versionsverwaltung eingecheckt und sind im Bundle sichtbar – nutzen Sie sie nur für nicht-sensitive Konfigurationen. Alles Kritische durchläuft Wrangler secrets, welche at-rest verschlüsselt und zur Laufzeit injiziert werden. Legen Sie sie pro Umgebung mit wrangler secret put NAME --env production fest.

Die Build-Pipeline – Vom pnpm Build zur Cloudflare Edge

Die Deployment-Pipeline hat drei Aufgaben: das Bundle bauen, Migrationen durchführen, falls sich das Schema geändert hat, und es in der richtigen Umgebung bereitstellen. Jede dieser Aufgaben beinhaltet einen Entscheidungspunkt, der, wenn er falsch getroffen wird, Sie einen ganzen Abend kosten kann.

Parität in der lokalen Entwicklung

wrangler dev führt Ihren Worker lokal gegen Miniflare aus, dem lokalen Laufzeitsimulator von Cloudflare. Dieser unterstützt D1, R2, KV, Queues und Durable Objects lokal mit --local-Flags. Das Ziel: Die Entwicklungsumgebung (dev) verhält sich so nah wie möglich an der Produktion – identische Bindings, das gleiche Routing-Modell, dieselben Env-Vars. Wenn Ihr lokales D1-Schema sechs Migrationen hinter der Produktion zurückliegt, werden Sie dies zur Deployment-Zeit und nicht erst beim Code-Review erfahren. Führen Sie Migrationen zuerst immer gegen das lokale D1 aus, um dann zu pushen.

CI/CD mit GitHub Actions und Workers Builds

Für Solo-Entwickler, die schnell liefern wollen, besteht die einfachste Pipeline aus zwei Workflows: einer für Pull Requests, der baut und ein Deploy in die Preview-Umgebung macht, und einer für den main-Branch, der baut, Migrationen durchführt und in die Produktion bereitstellt. Die Workers Builds documentation geht auf die plattformnative Option ein; das unten gezeigte Muster mit GitHub Actions gibt Ihnen mehr Kontrolle über den Migrationsschritt.

yaml

# .github/workflows/deploy.yml
name: Deploy
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  preview:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    environment:
      url: https://preview.ship-app.dev
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - run: pnpm wrangler deploy --env preview
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CF_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CF_ACCOUNT_ID }}

  production:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with: { node-version: 22 }
      - run: pnpm install --frozen-lockfile
      - run: pnpm build
      - run: pnpm wrangler d1 migrations apply ship-prod --env production --remote
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CF_API_TOKEN }}
      - run: pnpm wrangler deploy --env production
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CF_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CF_ACCOUNT_ID }}

Preview-Deployments pro Pull Request

Jeder PR erhält eine einzigartige Preview-Umgebung unter preview.ship-app.dev mit eigenen Bindings und Secrets. Reviewer klicken auf den Link, prüfen das Feature gegen echte Cloudflare-Infrastruktur (kein Stub), und die URL wird beim Schließen des PRs abgebaut. Dies ist die weitreichendste Änderung in meiner Deployment-Pipeline; sie deckt Ungereimtheiten bei Bindings und D1-Abfragefehler auf, noch bevor sie die Produktion erreichen. Wenn Sie nur ein Stück operativer Disziplin aus diesem Leitfaden übernehmen, dann dieses hier.

Secrets, Config und die Disziplin der Rotation

Secrets bei Workers sind ein Runtime-Primitiv, keine Konfigurationsdatei. Die Plattform verschlüsselt sie at-rest, injiziert sie nur in env und protokolliert sie standardmäßig niemals in Logs.

Das Wrangler-Secret-Muster

bash

# Einmaliges Setup, pro Umgebung
pnpm wrangler secret put STRIPE_SECRET_KEY --env production
pnpm wrangler secret put STRIPE_WEBHOOK_SECRET --env production
pnpm wrangler secret put STRIPE_SECRET_KEY --env preview
pnpm wrangler secret put STRIPE_WEBHOOK_SECRET --env preview

Die Preview-Umgebung bekommt eigene Stripe-Schlüssel im Test-Modus. Ein Preview-Deployment gegen Webhooks in der Produktion zu validieren, ist ein sicherer Weg, um echte Kundenzahlungen beim Testen zu verlieren.

Secret-Rotation ohne Downtime

Cloudflare-Secrets sind versioniert. Wenn Sie wrangler secret put aufrufen, wird der neue Wert für neue Requests aktiv; der bisherige Wert wird für laufende (in-flight) Anfragen beibehalten, bis sie abgeschlossen sind. Um diese Rotation ohne Ausfallzeit durchzuführen, stellen Sie das neue Secret bereit, warten Sie eine Minute, damit der in-flight Traffic abfließen kann, und entfernen Sie dann das alte Secret aus allen Drittanbieter-Dashboards. Ein häufiger Fehler: das Secret im Module Scope auszulesen. Die Rotation erfordert dann ein Deployment – Workers laden diese nicht per Hot-Reload nach. Lesen Sie Secrets immer innerhalb des Handlers aus.

Datenbankmigrationen und Schemaänderungen ohne Downtime

Bei D1-Migrationen stoßen Cloudflare-Neulinge meist gegen eine Wand. Die Plattform behandelt Migrationen als ausdrücklichen Schritt, der vor dem Deployment ausgeführt wird – nicht als Teil davon –, und ohne automatisches Rollback. Sie tragen die Verantwortung für beide Richtungen.

D1-Migrationsworkflow

D1 migrations sind SQL-Dateien in einem Ordner migrations/, die fortlaufend durchnummeriert werden. Das Muster ist:

Die nächste Migration generieren: pnpm wrangler d1 migrations generate ship-prod "add_subscription_tier"
Den generierten SQL-Code bearbeiten.
Lokal anwenden: pnpm wrangler d1 migrations apply ship-prod --local
Die Integration-Test-Suite laufen lassen.
In der Produktion anwenden: pnpm wrangler d1 migrations apply ship-prod --env production --remote

Der vorgestellte CI-Workflow integriert Schritt 5 direkt in den Produktions-Deploy-Job. Schlägt die Migration fehl, schlägt auch das Deployment fehl, und die vorherige Workers-Version empfängt weiterhin den Traffic, da noch nichts ausgerollt wurde.

Das Muster für Zero-Downtime-Schemaänderungen

Jede D1-Datenbank ist Single-Writer-fähig. Eine Migration, deren Anwendung viel Zeit in Anspruch nimmt, wird Schreibvorgänge im Apply-Fenster blockieren. Bei einem mandantenfähigen SaaS (Multi-Tenant) entspricht das einem Checkout-Ausfall. Das von mir verwendete Muster bedient sich der gleichen Herangehensweise, die Postgres-Teams seit zehn Jahren anwenden: Expand, Migrate, Contract.

Expand: Fügen Sie die neue Spalte als nullable hinzu. Keine Defaults, keine Constraints, kein Backfill.
Deploy: Stellen Sie Code bereit, der bei jedem Schreibvorgang gleichermaßen alte wie neue Spalten befüllt.
Backfill: Führen Sie ein einmaliges Skript aus, um Werte existierender Zeilen von der alten Spalte in die neue zu kopieren.
Switch: Liefern Sie Code aus, der Werte aus der neuen Spalte liest.
Contract: Entfernen Sie die alte Spalte in einer späteren Migration.

Jeder dieser Schritte erfordert ein eigenes Deployment, jedes Deployment kann unabhängig zurückgerollt werden und zu keinem Zeitpunkt wird die Datenbank gesperrt oder der Lesepfad inkonsistent. Einen tieferen Einblick in das Thema D1 in der Produktion – Replicas, Query-Optimization, Full-Text-Search – finden Sie im Cloudflare D1 Complete Production Guide.

Haben Sie die falsche Migration ausgeführt, löschen Sie nicht einfach die Datei und deployen neu. Migrationen sind auf D1 strikt append-only; das Löschen entsynchronisiert Ihre lokale Version von der Produktion. Führen Sie lieber eine Folge-Migration durch, die den entstandenen Schaden rückgängig macht, und arbeiten Sie von dort weiter. Um Code auf App-Level wiederherzustellen, greifen Sie auf Workers-Versionen zurück.

Observability, Rollbacks und der Alarm um 2 Uhr morgens

Das Deployment ist nicht beendet, wenn die URL grünes Licht gibt. Es ist erst erledigt, wenn Sie drei Fragen in unter einer Minute beantworten können: Wer hat es kaputt gemacht, was hat sich geändert, und wie kann ich ein Rollback durchführen?

Logs, Traces und die Analytics Engine

Setzen Sie observability.enabled in der wrangler.jsonc, um Workers Logs und die Tail Sessions anzuschalten – jeder Request erhält eine strukturierte Log-Datei; beim Aufruf jedes Bindings wird auf Traces reagiert. Nutzen Sie das Analytics Engine Binding für eigene Analysen – Seitenaufruf-Zähler, Conversion-Events, Darstellungen von Feature-Flags. Diese verhalten sich append-only, lassen sich im Dashboard auslesen und sind kostengünstig genug, um sie einzuschalten, bevor man sie dringend braucht.

Es gibt drei Hebel für Rollbacks, und Sie wollen, dass diese alle einwandfrei funktionieren, bevor Sie einen davon dringend benötigen.

Workers-Versionen: Jedes Deployment erzeugt eine neue Version. Befördern Sie eine frühere Version im Dashboard oder API in wenigen Sekunden ohne ein erneutes Redeploy. Das ist der Hebel, zu dem Sie zuerst greifen.
Wrangler-Rollback: Mit pnpm wrangler rollback --env production kehren Sie zum vorigen Deployment zurück. Sie verwenden diesen Befehl über CI idealerweise, wenn ein Post-Deploy Health-Check versagt.
D1 Migration Follow-up: Implementieren Sie eine korrigierende Migration. Es gibt keine automatischen D1-Rollbacks und genau das sollte auch so sein – destruktive Rollbacks richten mehr Schäden an als der Bug, dem Sie zu entfliehen versuchen.

Der Zwischenfall, der mich das gelehrt hat, zeigte sich anhand eines Rollbacks einer Workers-Version, der die API für neun Minuten offline nahm, weil ich in der Rollback-Version compatibility_date hochgesetzt hatte. Handhaben Sie daher bei Konfigurationen jedes einzelne Feld als tragend.

Kosten, Limits und die ehrliche Entscheidung

Die Kalkulation bei Workers erweist sich für I/O-lastiges SaaS als vorteilhaft und es lohnt sich, das Ganze nachzurechnen, anstatt blind auf das Marketing zu vertrauen.

Wo Workers punkten

Sie zahlen pro eine Million Requests und pro eine Million CPU-Millisekunden, plus der Nutzung der jeweiligen Bindings. Ein typischer SaaS-Endpoint, der 40 ms für I/O und 4 ms für Compute benötigt, kostet 4 ms CPU-Zeit und nicht 44 ms Ausführungsdauer – bei I/O-lastiger Arbeit ist das ungefähr eine Größenordnung günstiger als Plattformen mit dauerbasierter Abrechnung. R2 hat null Egress-Kosten, was bei Produkten, die von Nutzern hochgeladene Medien bereitstellen, den Unterschied zwischen tragfähigen und nicht tragfähigen Stückkosten (Unit Economics) ausmacht. Keine Grundkosten für Leerlauf-Instanzen, kein NAT-Gateway. Die pricing page ist hierbei maßgeblich.

Wo Workers die falsche Antwort ist

Workers ist nicht universell. Überspringen Sie es, wenn Sie rechenintensive (long-running) Compute-Prozesse pro Request benötigen (Video-Transcoding, Training großer Modelle), einen Legacy-Treiber über rohes TCP betreiben müssen, der nicht über Hyperdrive abgedeckt werden kann, operatives Muscle-Memory haben, das ausschließlich auf Kubernetes geprägt ist, oder wenn der Schreib-Durchsatz auf einer einzelnen relationalen DB das Single-Writer-Modell von D1 übersteigt. Im letztgenannten Fall lautet die ehrliche Antwort: Postgres hinter Hyperdrive. Der Filter-Ansatz mit fünf Fragen im Workers complete guide bietet Ihnen dabei einen noch detaillierteren Rahmen zur Entscheidungsfindung.

Fazit – Vorgefertigte Pipeline oder DIY

Ein Full-Stack-Cloudflare-Deployment für die Produktion umfasst grob 2.400 Zeilen Pipeline-Glue-Code: Multi-Environment-Wrangler-Config, GitHub-Actions-Workflows, den Runner für D1-Migrationen, Skripte zur Secret-Rotation, das Rollback-Playbook, die Integration der Analytics Engine und das Observability-Dashboard. Erstes Deployment: etwa 18 Stunden. Die nächsten elf Apps dauerten immer weniger lange – weshalb ich dieses Muster in ein Paket geschnürt habe.

Setzen Sie die gleiche Struktur anhand der obigen Konfigurationen selbst um; die Wrangler configuration docs und die D1 migrations docs sind dabei die Referenzen, auf die Sie immer wieder zurückkommen werden. Oder Sie starten mit einer produktionsfertigen Basis und verbringen Ihr Wochenende mit genau dem Teil Ihres Produkts, den sonst niemand bauen kann – sehen Sie sich die 14 Module von TanStack Ship an oder die Preisübersicht. Einmalkauf, lebenslange Updates, 14-tägiges Rückgaberecht.

Dies ist ganz bewusst ein umfassender Artikel und keine sechs Fragmente. Die Runtime, das Framework, die Bindings, die Wrangler-Config, CI/CD, Secrets, Migrationen, das Rollback und die Kostenkalkulation – all das finden Sie hier. Für einen tieferen Einblick in D1 lesen Sie den D1 production guide. Für die weitreichenden Grundlagen zu Workers siehe den Workers complete production guide. Was die Framework-Konfiguration betrifft, die innerhalb des Workers ausgeliefert wird, werfen Sie einen Blick auf den TanStack Start deployment guide.

Schreiben Sie die Pipeline selbst, wenn Sie das Muscle-Memory aufbauen wollen. Kaufen Sie sich die Zeit zurück, wenn Sie lieber sofort ausliefern möchten.

Weiterführende Literatur: