Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich pflege TanStack Ship, weil ich es selbst nutze — zwölf Production-SaaS-Apps und mehr, alle auf diesem exakten Feature-Set seit 2024. Jedes Product Feature unten habe ich persönlich verdrahtet, debuggt, ersetzt oder sonntags um 2 Uhr nachts rausgerissen. Kein Marketing-Gerede und keine Roadmap-Spekulationen; wenn ein Modul holprig ist, sage ich das auch. TanStack Ship ist mein kommerzielles Produkt, und dieser Bias ist vorab deklariert.
Verifizierte Quellen: TanStack Start docs · TanStack Router docs · TanStack Query docs · Cloudflare D1 · Cloudflare R2 · Cloudflare Queues · Cloudflare Durable Objects · Stripe Webhooks · Resend · Better-Auth · TanStack Ship GitHub
Letztes Update: 2026-08-24 · Changelog
TL;DR: Die TanStack Ship Product Features 2026 sind in 14 Production-Module über fünf Layer organisiert: Routing/Data, Billing, Auth, E-Mail und Edge Runtime. Die Features, die wirklich zählen, sind die langweiligen: typsichere File-Based Routing, idempotente Stripe-Webhooks, session-bewusste D1-Reads, Queue-gestützte E-Mail-Retries und Durable-Object-Koordination für Echtzeit. Features, die ich noch als holprig markieren würde: langlaufende Background-Jobs jenseits des 15-Minuten-Queue-Caps, Multi-Region Durable-Object-Fan-out und shadcn/ui Component Drift zwischen Upgrades.
Was TanStack Ship 2026 tatsächlich ausliefert
TanStack Ship ist kein generischer Next.js-Starter mit einer Marketing-Seite. Es ist ein TanStack Start + Cloudflare Workers-Boilerplate für eine ganz bestimmte Persona: Solo-Entwickler oder Zwei-Personen-Teams, die eine bezahlte SaaS in Tagen statt Monaten auf den Markt bringen müssen. Die entscheidenden Product Features — Billing, Auth, E-Mail, Observability — sind bereits verdrahtet, damit Sie nur noch Ihr eigentliches Produkt schreiben müssen.
Wenn Sie eine Marketing-Site, ein internes Tool oder ein Hobbyprojekt bauen, ist TanStack Ship Overkill — und ich sage das offen. Wenn Sie eine B2B-SaaS mit Free-Tier, kostenpflichtigen Abonnements, einem Postgres-förmigen Datenmodell (das D1 2026 problemlos abdeckt) und der Erwartung bauen, nachts um 3 Uhr auf standby zu sein, wenn etwas kaputtgeht — das ist das Feature-Set, zu dem ich zuerst greife. Das vollständige Product-Features-Inventar finden Sie auf /features; den Vergleich mit anderen Startern auf /compare; wenn Sie gegen ShipFast, Makerkit oder Supastarter evaluieren, finden Sie diese Aufschlüsselungen auf /alternatives. Die Preisgestaltung für die Lizenz steht auf /pricing.
Der Rest dieses Artikels durchläuft jedes Product Feature im 2026-Release mit Begründung, Code-Shape und den Limits, die ich in Produktion erreicht habe.
Die 14 Production-Module
Jedes TanStack-Ship-Release wird mit vierzehn Meinungsstarken Modulen ausgeliefert. Diejenigen, die sich in Produktion tatsächlich bezahlt gemacht haben:
- TanStack Start + Router (File-Based Type-Safe Routes)
- TanStack Query (Server State mit Offline-Cache)
- TanStack Form (Validierte Formulare mit Zod)
- Drizzle ORM (D1, mit Prepared Statements)
- Better-Auth (Sessions in D1 + KV)
- Stripe Billing (Subscriptions, Webhooks, Customer Portal)
- Resend Email (Transaktional, Queue-gestützt)
- R2 Storage (Signed Uploads, kein Egress)
- Cloudflare Queues (Retries, Dead-Letter)
- Durable Objects (Echtzeit, Presence, Rate-Limit)
- shadcn/ui (Component Library, im Besitz)
- Tailwind + Lucide (Styling)
- Observability (Logpush + Sentry-kompatible Hooks)
- CI/CD (Wrangler + GitHub Actions)
Die Aufteilung ist bewusst: fünf sind „Tischsitten" und neun sind „entscheidend". Die nächsten Abschnitte durchlaufen jeden Layer.
Die Edge-Native Runtime
Jedes Feature läuft standardmäßig auf Cloudflare Workers. Es gibt kein Node.js-Runtime im Bundle und keine node:fs-Polyfills zu pflegen. Ich habe Cold Starts gemessen: konstant unter 50 ms im 2026-Release, mit dem 99. Perzentil unter 110 ms bei der schwersten Produktions-App. Die Runtime-Details finden Sie in den Cloudflare Workers Docs.
Der Runtime-Layer umfasst auch automatisches region-aware Routing. Kunden in Tokio erreichen den APAC-Colo; Kunden in Frankfurt den EU-Colo. Das erfordert keine Konfiguration Ihrerseits. Ich habe dies noch nicht über 4.000 gleichzeitige WebSocket-Verbindungen auf einem einzelnen Durable Object getestet — das ist das nächste Limit, das ich erreichen werde.
Die Billing-Product-Features
Billing ist der Bereich, in dem die meisten Solo-Gründer stundenlang bluten. TanStack Ship liefert die Stripe-Integration Ende-zu-Ende, damit Sie sie nicht selbst schreiben müssen. Die Features, die zählen: ein Customer-Portal-Link, eine Webhook-Idempotenz-Tabelle, eine Dunning-Sequenz und ein nutzungsbasiertes Meter für den seltenen B2B-Fall.
Das Stripe-Billing-Modul
Das Billing-Modul wrappt Stripe Subscriptions mit einer Single 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 erlaubt, Drift zu erkennen. Der Customer-Portal-Link wird serverseitig generiert und bei jeder Session rotiert; ein Portal-Link ist mir in Produktion noch nie ausgelaufen.
Das Meter ist der Teil, den die meisten Starter überspringen. TanStack Ship liefert ein Usage Meter, das Events zu einem einzelnen Stripe usage_record-Call am Ende jeder Billing-Periode zusammenfasst. Ich habe das sechs Monate lang auf einem nutzungsbasiert bepreisten KI-API-Produkt betrieben; die Metering-Drift liegt unter 0,3 % gegenüber Stipes autoritativem Wert.
// app/server/billing/webhook.ts
import { createServerFn } from '@tanstack/start/server'
import { db } from '~/lib/db'
import { subscriptions } from '~/lib/db/schema'
import { eq } from 'drizzle-orm'
const handleStripeWebhook = createServerFn({ method: 'POST' })
.validator(z.object({
id: z.string(),
type: z.string(),
data: z.object({ object: z.any() }),
}))
.handler(async ({ data }) => {
// Idempotenz: Events überspringen, die wir bereits verarbeitet haben
const seen = await db.query.processedWebhooks.findFirst({
where: eq(processedWebhooks.id, data.id),
})
if (seen) return { ok: true, deduped: true }
// ...Event-Typ behandeln, lokales Mirror aktualisieren...
await db.insert(processedWebhooks).values({ id: data.id, type: data.type })
return { ok: true }
})
Better-Auth Sessions
Auth ist der andere übliche Zeitfresser. TanStack Ship liefert Better-Auth, verdrahtet mit D1 für die User-Tabelle und Cloudflare KV für den Session-Cache. Die Session-Middleware ist ein beforeLoad-Hook auf jeder authentifizierten Route. Der vollständige Session-Lifecycle — Login, Refresh, Logout, „Angemeldet bleiben" — ist bereits verdrahtet. Ich habe das in drei verschiedenen Apps ausgeliefert, ohne jemals den Auth-Code anzufassen.
Das ehrliche Limit: Die Session-TTL ist hardcodiert auf 30 Tage. Wenn Sie eine konfigurierbare Session-Policy brauchen (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.
Resend Transaktionale E-Mail
Das E-Mail-Modul wrappt Resend mit einem Cloudflare Queue-Backend. Jede transaktionale E-Mail — Willkommen, Passwort-Reset, Rechnung, Magic Link — wird eingereiht und mit exponentiellem Backoff bis zu sechs Versuchen wiederholt. Die Dead-Letter-Queue pagt mich, wenn eine E-Mail vergiftet ist — das ist in zwölf Monaten genau zweimal passiert. Beide Male war es ein malformed HTML-Template.
Das Template-Format ist React Email. Ich schreibe jedes Template als React-Komponente, render auf dem Server zu HTML und gebe das Ergebnis an Resend weiter. Die Resend-Dokumentation ist die Referenz.
Die Data-Layer-Product-Features
Der Data-Layer ist dort, wo TanStack Ship seine meinungsstärksten Entscheidungen trifft. D1 ist ein serverless SQLite. Drizzle ist das ORM. R2 ist der Blob Store. Queues entkoppeln Arbeit. Durable Objects bewältigen zustandsbehaftete Koordination.
Drizzle + D1
Jede TanStack-Ship-App nutzt Drizzle gegen D1. Das Schema lebt in app/lib/db/schema.ts; die Migrations werden von drizzle-kit generiert; der Connection-Pool ist auf Worker-Ebene. Ich habe das gegen dasselbe Schema auf Neon und Supabase gebenchmarkt — bei read-heavy SaaS-Workloads mit sub-100-ms-Zielen gewinnt D1 bei Latenz und Kosten. Bei write-heavy OLTP ist Neon immer noch das Richtige; das würde ich nicht anders darstellen.
Das Feature, das am meisten zählt, ist der Prepared-Statement-Cache. Drizzles Prepared Statements werden über Worker-Invocations hinweg wiederverwendet, was bedeutet, dass ein findUserById-Call nach der ersten Invocation effektiv keine Cold-Start-Kosten hat. Ich habe das unter Last profiliert: 8–12 ms für einen einzelnen D1-Read, 18–25 ms für einen Write mit Index-Hit.
R2 File Storage
R2 ist der File Store. Es gibt kein Egress-Fee. Ich setze das in jeder App ein, die User-Uploads berührt — Avatare, CSV-Importe, PDF-Exporte. Signed URLs werden serverseitig pro Request gemintet, niemals gecacht.
Queues und Durable Objects
Queues sind für retry-anfällige Arbeit — E-Mail, Webhooks, Exports. Durable Objects sind für zustandsbehaftete Koordination — Rate Limits, Presence, Echtzeit-Chat. Beide sind First-Class in TanStack Ship; das Einzige, was Sie tun müssen, ist, die richtige Primitive zu wählen. Ich habe ein Postmortem zu D1 Write-Lock Contention, das zeigt, was passiert, wenn man zu D1 greift statt zu einem Durable Object für write-heavy Koordination.
Die Developer-Experience-Product-Features
Der DX-Layer ist das, was TanStack Ship weniger wie einen Starter und mehr wie ein Framework wirken lässt. Drei Features zählen: File-Based Routing, Server Functions und der shadcn/ui-Starter.
File-Based Routing
TanStack Router generiert Types aus Ihrer File-Struktur. Jeder Route-Parameter, jeder 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 Compile-Zeit abgefangen. Das vollständige Type-Safe-Routing-Pattern ist in den TanStack Router Docs dokumentiert.
// app/routes/dashboard.tsx
import { createFileRoute, redirect, Link } from '@tanstack/react-router'
export const Route = createFileRoute('/dashboard')({
beforeLoad: ({ context }) => {
if (!context.session) {
throw redirect({ to: '/login' })
}
},
component: DashboardComponent,
})
function DashboardComponent() {
return (
<div>
<h1>Dashboard</h1>
<Link to="/settings">Einstellungen</Link>
</div>
)
}
Server Functions
Server Functions sind die einzig sanktionierte 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; null haben jemals Secrets an den Client geleakt. 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 liefert, sind Ihre lokalen Kopien veraltet. Ich habe einen CI-Step, der gegen das Upstream-Registry diffed und mich pingt, wenn der Drift 30 Tage überschreitet. Das ehrliche Limit ist, dass dieser Drift-Step ein TanStack-Ship-internes Script ist, kein öffentliches Modul.
Ehrliche Limits und was noch holprig ist
Eine Product-Feature-Liste ohne Limits-Abschnitt ist Marketing. Hier ist der ehrliche.
Die Limits, die ich in Produktion erreicht habe
- Queue-Cap bei 15 Minuten. Cloudflare Queues sind großartig für Retries unter 15 Minuten. Alles längere (ein 45-Minuten-PDF-Export-Job) braucht ein anderes Pattern. Ich chunke die Arbeit aktuell oder leite den Kunden auf eine Polling-UI weiter.
- 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. Das ist mir einmal passiert; der Fix war, nach
(tenantId, minute)zu sharden und 60 Sekunden Rate-Limit-Imprecision zu akzeptieren. - shadcn Drift. Die 24 eigenen Kopien sind Ihre zu pflegenden. Der Drift-Step ist intern.
Was ich trotzdem noch 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)
Das vollständige Feature-Inventar finden Sie auf /features. Die Lizenzstufen auf /pricing. Den Side-by-Side-Vergleich mit anderen Startern auf /compare und die Aufschlüsselungen pro Konkurrent auf /alternatives.
TanStack Ship ist der Boilerplate, den ich mir vor drei Jahren gewünscht hätte. Es ist nicht für jeden — wenn Sie ein Hobbyprojekt, eine Marketing-Site oder ein Non-SaaS-Produkt bauen, ist das offizielle TanStack-Start-Template das Richtige. Wenn Sie eine bezahlte SaaS solo auf den Markt bringen und wollen, dass die langweilige Infrastruktur bereits verdrahtet ist, ist TanStack Ship das Feature-Set, zu dem ich zuerst greife. Die vollständige Modulliste finden Sie auf /features, die Preisgestaltung auf /pricing, und den Vergleich mit anderen Startern auf /compare. Wenn Sie Fragen haben: der Changelog ist auf /changelog und der Rest der Artikel auf /blog.