TanStack Start Overview
Purpose and Scope
TanStack Start is the full-stack framework layer for Router-first applications. In the official product framing, Start keeps TanStack Router as the application contract: routes, typed URL state, loaders, links, route matching, and prefetching remain the way the app is authored. Start then adds the server responsibilities that a client router should not own by itself, including full-document server-side rendering, streaming, server functions, server routes, and deployable build output for the runtime target. This page orients Router users to that relationship and explains which Router primitives continue to matter when an app becomes full-stack.
Sources: docs/router/api/router.md
The important architectural idea is that Start does not replace the route tree. A Start app still depends on the same route creation and navigation concepts exposed by the Router API surface, including file routes, root routes, route masks, redirects, not-found handling, links, outlets, and loader data access. The difference is where the work can execute. During an initial request, Start can match a route tree, run server-side work, stream a document, and later reuse the same typed route contract during client-side navigation.
Relevant Source Files
- docs/router/api/router.md — The Router API index used to identify the route, navigation, data, error, component, hook, and type primitives that Start builds on rather than replacing.
Router Primitives Start Builds On
Start is best understood by first naming the Router primitives that form its base. The Router API index lists route creation functions such as createFileRoute, createLazyFileRoute, createRootRoute, createRootRouteWithContext, createRoute, createLazyRoute, and createRouter. Those names define the authoring model: applications declare a route tree, optionally generated from files, and attach behavior such as loaders, context, search validation, components, and navigation targets. Start adds server execution around this model, but the route tree remains the durable contract between URL, data, UI, and types.
Sources: docs/router/api/router.md
The component and hook APIs show the same continuity. Router exposes components such as Await, CatchBoundary, CatchNotFound, ClientOnly, Link, MatchRoute, Navigate, NotFoundComponent, and Outlet, plus hooks such as useLoaderData, useLocation, useMatch, useNavigate, useParams, useRouteContext, useRouterState, and useSearch. In a Start application, these are still the reader-facing tools for rendering route UI and reading route state. The full-stack layer changes when data and markup are produced, not the vocabulary used by route modules and components.
System-to-Code Mapping
| Start concern | Router API foundation | Why it matters |
|---|---|---|
| Route-authored app contract | createFileRoute, createRoute, createRootRoute, createRouter | Start can run server work around the same typed route tree used by client navigation. |
| Streaming and deferred UI | defer, Await, useAwaited, useLoaderData | Route data can be represented as pending or resolved UI while preserving route-level data access. |
| Navigation and prefetching | Link, Navigate, linkOptions, useNavigate, useMatchRoute | Server-rendered pages still hydrate into a navigable Router app with typed links and imperative navigation. |
| Errors and redirects | notFound, redirect, isNotFound, isRedirect, CatchBoundary, CatchNotFound | Server and client transitions need a shared language for redirects, not-found states, and route errors. |
| Typed state | RouterOptions, RouterState, ParsedLocation, RouteMatch, RouteOptions | Start relies on Router’s typed location, match, state, and route option model as its application boundary. |
Sources: docs/router/api/router.md
This mapping is useful because Start features can otherwise sound like a separate framework vocabulary. Full-document SSR means the server can return the whole HTML document for a matched route. Streaming means the response can begin before all data is complete, allowing useful shell and pending UI to reach the browser earlier. Server functions and server routes provide explicit server boundaries for database, authentication, environment, or API work. All of those features are layered around Router’s route, loader, navigation, and error contracts rather than inventing a second routing system.
Request and Rendering Flow
A typical Start request begins with the URL. Router narrows the route match, params, search, route context, loader dependencies, and link targets through the route tree. Start can then execute the server portions of that request: running loaders during the initial request, invoking server functions behind an explicit server boundary, producing head tags and route data, and streaming the document response. Once the browser hydrates, client navigation continues through Router APIs such as Link, Navigate, useNavigate, useSearch, useParams, and useLoaderData.
Sources: docs/router/api/router.md
The official Start examples emphasize this split with route modules that look like Router route modules plus server-aware code. A route can validate search, load data through context, and render UI through the route component, while server functions keep privileged work behind a server-only execution boundary. That separation is important for application design: route modules describe the user-visible URL contract, while server functions and server routes describe operational boundaries such as database access, authentication checks, secrets, or host-specific runtime behavior.
API Components to Recognize
When reading Start code, expect to see familiar Router APIs in places that may initially feel server-oriented. File routes and root routes define the tree. Outlet composes parent and child layouts. Link and Navigate express route-aware transitions. Await and deferred data APIs support pending data UI. CatchBoundary, CatchNotFound, notFound, redirect, isNotFound, and isRedirect provide a shared model for exceptional control flow. Hooks such as useRouter, useRouterState, useMatches, useMatch, useLoaderData, useRouteContext, useSearch, and useParams connect rendered components back to the current route match.
Sources: docs/router/api/router.md
The type entries in the Router API index are also part of the Start mental model. Types such as RouterOptions, RouterState, RouterEvents, RouteOptions, RouteMatch, RouteApi, LinkOptions, NavigateOptions, ParsedLocation, HistoryState, Redirect, and NotFoundError describe the shape of configured router instances, navigation inputs, parsed locations, and route outcomes. Start adds full-stack packaging and runtime behavior, but these types explain why the route tree can remain a precise contract across server rendering, streaming, hydration, and later client transitions.
Next Steps
Use this overview as the bridge between Router documentation and Start-specific guides. If you are new to the stack, first learn the Router route tree, file-based route creation, loaders, search params, links, outlets, and error boundaries. Then move to Start topics for client and server entry points, server functions, middleware, rendering and hydration, deployment targets, and operational concerns. Keeping those layers separate makes the framework easier to reason about: Router defines what the app is, while Start defines how that app runs across server and client runtimes.