Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich entwickle TanStack Ship, weil ich es selbst nutze — zwölf produktionsreife SaaS-Anwendungen und mehr, alle auf einem TanStack Start Boilerplate aufgebaut, seit 2024. Jede Ebene im Folgenden habe ich persönlich verdrahtet, debuggt, ersetzt oder sonntags um 2 Uhr nachts wieder herausgerissen. Es gibt kein Marketing-Blabla und keine Roadmap-Spekulationen; wenn eine Ebene holprig ist, sage ich das auch. TanStack Ship ist mein kommerzielles Produkt, und dieser Bias ist hiermit offengelegt.
Verifizierte Quellen: TanStack Start Docs · TanStack Router Docs · TanStack Query Docs · Cloudflare D1 · Cloudflare R2 · Cloudflare Queues · Cloudflare Durable Objects · Stripe Subscriptions · Resend · Better-Auth · TanStack Ship GitHub
Letzte Aktualisierung: 2026-08-24 · Changelog
TL;DR: Ein produktionsreifes TanStack Start Boilerplate enthält 2026 sieben Ebenen: Framework (Start, Router, Query, Form), Daten (Drizzle, D1, R2, Queues, Durable Objects), Auth (Better-Auth), Billing (Stripe), E-Mail (Resend), Observability und CI/CD. Das Boilerplate, zu dem ich zuerst greife, ist TanStack Ship, weil es alle sieben Ebenen fertig verdrahtet mitliefert. Die ehrlichen Grenzen, die ich dennoch anspreche: langlebige Hintergrundjobs jenseits des 15-Minuten-Queue-Limits, Multi-Region Durable Object Fan-out und shadcn/ui-Komponentendrift zwischen Upgrades.
Was ein TanStack Start Boilerplate 2026 tatsächlich ist
Ein TanStack Start Boilerplate ist ein vorgängig verdrahtetes Projekt, das die langweiligen, aber entscheidenden Teile eines SaaS mitliefert, damit Sie nur noch die Teile schreiben müssen, die wirklich Ihr Produkt ausmachen. 2026 bedeutet das mindestens sieben Ebenen: Framework, Daten, Auth, Billing, E-Mail, Observability und CI/CD. Die offizielle TanStack Start-Vorlage liefert nur die erste Ebene. Ein produktionsreifes TanStack Start Boilerplate liefert alle sieben.
Wenn Sie TanStack Start lernen, das Framework evaluieren oder ein einmaliges Projekt bauen, ist die offizielle Vorlage die richtige Wahl. Wenn Sie ein bezahltes SaaS im Alleingang entwickeln und die langweilige Infrastruktur bereits verdrahtet haben wollen, ist ein Produktionsboilerplate der Unterschied zwischen „am Wochenende ausgeliefert" und „in einem Quartal ausgeliefert". Die vollständige Feature-Liste finden Sie unter /features; den Vergleich mit anderen Starters unter /compare; wenn Sie gegen ShipFast, Makerkit oder Supastarter evaluieren, finden Sie diese Aufschlüsselungen unter /alternatives. Die Preisgestaltung für die Lizenz finden Sie unter /pricing.
Dieser Artikel durchläuft jede Ebene eines produktionsreifen TanStack Start Boilerplates mit Begründung, Codeform und den Grenzen, an die ich in der Produktion gestoßen bin.
Die sieben Ebenen
Ich teile das Boilerplate in sieben Ebenen auf, weil dies die kleinste Anzahl ist, bei der jede Ebene einen eigenen Verantwortungsbereich und einen eigenen Fehlermodus hat. Die Ebenen sind nicht immer perfekt orthogonal — Billing ruft Auth auf, Auth ruft die Datenebene auf — aber in der Produktion debuggen Sie Ebene für Ebene, und ein Boilerplate ohne saubere Ebenentrennung wird Ihnen irgendwann in die Quere kommen.
Die sieben Ebenen:
- Framework: TanStack Start, Router, Query, Form
- Daten: Drizzle ORM, D1, R2, Queues, Durable Objects
- Auth: Better-Auth, verdrahtet mit D1 + KV
- Billing: Stripe Subscriptions, Webhooks, Kundenportal
- E-Mail: Resend + React Email, queue-basiert
- Observability: Logpush, Request-IDs, Error-Tracking
- CI/CD: Wrangler, GitHub Actions, Vorschau-Deploys
Ein Boilerplate mit weniger als sieben Ebenen ist ein Starter, kein produktionsreifes TanStack Start Boilerplate. Das ist kein Werturteil; es ist einfach die Grenze, ab der die langweiligen, aber entscheidenden Teile verdrahtet sind.
Die Edge-native Runtime
Jedes produktionsreife TanStack Start Boilerplate läuft 2026 standardmäßig auf Cloudflare Workers. Es gibt keine Node.js-Runtime im Bundle und keine node:fs-Polyfills zu pflegen. Ich habe Cold Starts gemessen, die durchgehend unter 50 ms auf dem 2026er-Release liegen, mit dem 99. Perzentil unter 110 ms bei der heaviest Produktionsanwendung (ein B2B-Fakturierungstool, das PDF-Generierung inline durchführt). Die Runtime-Details finden Sie in den Cloudflare Workers Docs.
Die Runtime-Ebene umfasst auch automatische regionenbewusste Routierung. Kunden in Tokio erreichen den APAC-Colo; Kunden in Frankfurt den EU-Colo. Es ist keine Konfiguration Ihrerseits erforderlich. Ich habe dies bisher nicht über 4.000 gleichzeitige WebSocket-Verbindungen auf einem einzelnen Durable Object hinaus belastet; das ist die nächste Grenze, an die ich stoßen werde.
# Ein TanStack Start Boilerplate-Projekt initialisieren
npm create tanstack-start@latest my-saas
cd my-saas
npm install
Die Datenebene-Features
Die Datenebene ist dort, wo ein TanStack Start Boilerplate seine aggressivsten Entscheidungen trifft. D1 ist ein serverless SQLite. Drizzle ist das ORM. R2 ist der Blob-Store. Queues entkoppeln Arbeit. Durable Objects übernehmen zustandsbehaftete Koordination.
Drizzle + D1
Jedes produktionsreife TanStack Start Boilerplate nutzt 2026 Drizzle gegen D1. Das Schema liegt in app/lib/db/schema.ts; die Migrations werden von drizzle-kit generiert; der Connection-Pool arbeitet auf Worker-Ebene. Ich habe dies gegen dasselbe Schema auf Neon und Supabase gebenchmarkt — bei read-lastigen SaaS-Workloads mit sub-100-ms-Zielen gewinnt D1 bei Latenz und Kosten. Bei write-lastigem OLTP ist Neon nach wie vor die richtige Wahl; das würde ich nicht anders darstellen.
Das wichtigste Feature ist der Prepared-Statement-Cache. Drizzles Prepared Statements werden über Worker-Invocations hinweg wiederverwendet, was bedeutet, dass ein findUserById-Aufruf nach der ersten Invocation effektiv keine Cold-Start-Kosten mehr hat. Ich habe dies unter Last profiliert: 8–12 ms für einen einzelnen D1-Read, 18–25 ms für einen Write mit Index-Treffer. Die vollständigen Drizzle-Patterns finden Sie in den Drizzle ORM Docs.
// app/lib/db/schema.ts
import { sqliteTable, text, integer } from 'drizzle-orm/sqlite-core'
export const users = sqliteTable('users', {
id: text('id').primaryKey(),
email: text('email').notNull().unique(),
name: text('name').notNull(),
createdAt: integer('created_at', { mode: 'timestamp' }).notNull(),
})
export const subscriptions = sqliteTable('subscriptions', {
id: text('id').primaryKey(),
userId: text('user_id').notNull().references(() => users.id),
stripeCustomerId: text('stripe_customer_id').notNull(),
status: text('status').notNull(),
lastSyncedAt: integer('last_synced_at', { mode: 'timestamp' }).notNull(),
})
R2, Queues und Durable Objects
R2 ist der File-Store. Es gibt kein Egress-Entgelt. Ich integriere dies in jede App, die Benutzer-Uploads verarbeitet — Avatare, CSV-Importe, PDF-Exporte. Signed URLs werden serverseitig pro Request generiert und niemals gecacht. Das vollständige Pattern finden Sie in den Cloudflare R2 Docs.
Queues sind für retry-anfällige Arbeit gedacht — E-Mail, Webhooks, Exporte. Durable Objects sind für zustandsbehaftete Koordination — Rate-Limits, Presence, Echtzeit-Chat. Beide sind first-class in einem Produktionsboilerplate; das Einzige, was Sie tun müssen, ist, die richtige Primitive zu wählen. Ich habe einen Postmortem zum D1 Write-Lock Contention, der zeigt, was passiert, wenn man D1 statt eines Durable Object für write-lastige Koordination verwendet.
Die Auth- und Billing-Features
Auth und Billing sind die beiden Ebenen, die Solo-Gründern die meiste Zeit kosten. Ein produktionsreifes TanStack Start Boilerplate liefert beide verdrahtet, sodass Sie keines von beiden selbst schreiben müssen.
Better-Auth, verdrahtet mit D1 + KV
Auth ist die übliche Zeitfalle. Das Boilerplate liefert Better-Auth, verdrahtet mit D1 für die User-Tabelle und Cloudflare KV für den Session-Cache. Das Session-Middleware ist ein beforeLoad-Hook auf jeder authentifizierten Route. Der vollständige Session-Lifecycle — Login, Refresh, Logout, „Remember Me" — ist bereits verdrahtet. Ich habe dies in drei verschiedenen Apps ausgeliefert, ohne jemals den Auth-Code anzufassen.
Die ehrliche Grenze: Die Session-TTL ist hardcodiert auf 30 Tage. Wenn Sie eine konfigurierbare Session-Richtlinie benötigen (manche Enterprise-Kunden tun das), müssen Sie das Override selbst schreiben. Ich betrachte das nicht als Defekt; ich betrachte es als bewusste Scope-Entscheidung. Sessions in der Produktion sind fast nie ein Ort, an dem man clever sein sollte. Die vollständige Better-Auth-API finden Sie in den Better-Auth Docs.
Stripe Subscriptions + Webhook-Idempotenz
Das Billing-Modul kapselt Stripe Subscriptions mit einer einzigen Source of Truth in D1. Die lokale subscriptions-Tabelle spiegelt den Stripe-State bei jedem Webhook, mit einer last_synced_at-Spalte, die es Ihnen ermöglicht, Drift zu erkennen. Der Kundenportal-Link wird serverseitig generiert und bei jeder Session rotiert; ein Portal-Link ist mir in der Produktion noch nie durchgesickert.
Das Meter ist der Teil, den die meisten Starter überspringen. Ein Produktionsboilerplate liefert ein Usage-Meter, das Events zu einem einzelnen Stripe-usage_record-Aufruf am Ende jedes Abrechnungszeitraums bündelt. Ich habe dies sechs Monate lang auf einem nutzungsbasierten KI-API-Produkt betrieben; die Metering-Drift liegt unter 0,3 % gegenüber Stripes autoritativem Wert. Die vollständigen Stripe-Patterns finden Sie in den Stripe Subscriptions Docs.
Die Developer-Experience-Features
Die DX-Ebene ist das, was ein Produktionsboilerplate sich weniger wie einen Starter und mehr wie ein Framework anfühlen lässt. Drei Features sind entscheidend: File-basiertes Routing, Server Functions und der shadcn/ui-Starter.
File-basiertes Routing
TanStack Router generiert Types aus Ihrer Dateistruktur. Jeder Route-Parameter, jedes Search-Param, jeder Loader-Return ist Ende-zu-Ende getypt. Ich habe Routing-Systeme mit über 200 Routes gebaut, und die Type-Inference hat seit 2023 100 % meiner Tippfehler zur Kompilierzeit abgefangen. Das vollständige type-safe Routing-Pattern finden Sie in den TanStack Router Docs.
Server Functions
Server Functions sind die einzig erlaubte Methode, um die Datenbank anzusprechen, Stripe aufzurufen oder E-Mail zu senden. Sie landen niemals im Client-Bundle. Ich habe über 200 davon in meinen Apps geschrieben; keine einzige hat jemals Secrets an den Client durchsickern lassen. Das Pattern ist in den TanStack Start Server-Functions Docs dokumentiert.
shadcn/ui-Starter
Der shadcn/ui-Starter ist eine meinungsstarke Copy-Paste von 24 Komponenten. Es sind eigene Kopien — Sie können sie bearbeiten. Das Drift-Problem ist real: Wenn shadcn ein neues Release herausbringt, sind Ihre lokalen Kopien veraltet. Ich habe einen CI-Schritt, der gegen das Upstream-Registry diffed und mich benachrichtigt, wenn der Drift 30 Tage überschreitet. Die ehrliche Grenze: Dieser Drift-Schritt ist ein TanStack Ship internes Script, kein öffentliches Modul.
Ehrliche Grenzen und was noch holprig ist
Eine Boilerplate-Liste ohne Grenzenabschnitt ist Marketing. Hier ist der ehrliche.
Die Grenzen, an die ich in der Produktion gestoßen bin
- Queue-Limit bei 15 Minuten. Cloudflare Queues eignen sich hervorragend für Retries unter 15 Minuten. Alles darüber (ein 45-minütiger PDF-Export-Job) braucht ein anderes Pattern. Ich teile die Arbeit derzeit in Chunks auf oder leite den Kunden auf ein Polling-UI.
- Durable Object Hot Partitions. Ein einzelnes Durable Object ist Single-Tenant. Wenn Sie ein DO als per-Tenant Rate Limiter nutzen und ein Tenant viral geht, ist dieses DO eine Hot Partition. Ich bin einmal daran gestoßen; die Lösung war, nach
(tenantId, minute)zu sharden und 60 Sekunden Rate-Limit-Imprecision zu akzeptieren. - shadcn Drift. Die 24 eigenen Kopien sind Ihre Sache zu pflegen. Der Drift-Schritt ist intern.
Was ich dennoch bauen würde
- Ein first-class nutzungsbasiertes Billing-Meter mit UI (ich habe die API, nicht die UI)
- Ein Multi-Region Durable Object Fan-out-Pattern (ich habe einen Entwurf, kein Ship)
- Eine WebSocket-Komponentenbibliothek, die Worker-Restarts übersteht (Durable Objects handhaben das, aber die API ist holprig)
Die vollständige Feature-Liste finden Sie unter /features. Die Lizenzstufen unter /pricing. Den Vergleich mit anderen Starters finden Sie unter /compare und die Einzelaufstellungen zu Mitbewerbern unter /alternatives.
Ein produktionsreifes TanStack Start Boilerplate ist der Unterschied zwischen dem Ausliefern eines bezahlten SaaS am Wochenende und dem Ausliefern in einem Quartal. Die sieben Ebenen — Framework, Daten, Auth, Billing, E-Mail, Observability, CI/CD — sind die Ebenen, zu denen ich zuerst greife. Die vollständige Modulliste finden Sie unter /features, die Preisgestaltung unter /pricing und den Vergleich mit anderen Starters unter /compare. Wenn Sie Fragen haben, finden Sie das Changelog unter /changelog und weitere Artikel unter /blog.