TanStack Start 1.0 Is Stable: When It Beats Next.js, When It Doesn't

The React framework conversation has had one default answer for years. TanStack Start 1.0 is the first credible stable alternative that does not ask you to adopt Server Components as the center of your app. That is its pitch, and also the right lens for deciding whether to move.

What 1.0 actually commits to

Tanner Linsley announced TanStack Start 1.0 on 13 October 2026, calling it "ready for production" after a release-candidate period in which, he notes, many teams already ran it in production. The post frames 1.0 as a commitment to the current application model rather than a feature drop.

The core pieces, as the announcement describes them:

• Routing from TanStack Router. Routes know their paths, params, search params, loader data and context, and type errors surface downstream when one changes.
• Selective SSR. A route can render on the server, load data on the server without rendering the component, or render only on the client.
• Typed server functions. createServerFn defines server code you call from loaders or event handlers.
• Full-stack middleware that composes around server function calls on both client and server, with context typed across the boundary.
• Environment functions. createIsomorphicFn holds a server and a client implementation side by side, and Start strips the unused one from each bundle.

Two smaller signals are worth noting. Start now supports Solid as well as React, and the post describes that work as a test of which code still assumed React. The team has also added TanStack Intent and skills shipped inside npm packages to guide coding agents working on Start and Router apps, while cautioning that types help agents make consistent multi-file changes but do not replace checking that the right thing was built.

What the post does not include is just as important: no formal semver or support-window policy, no deployment matrix and no benchmark methodology for its roughly 5.5x SSR throughput claim. Treat "stable" as a strong statement of intent, not an LTS contract. By contrast, the Next.js support policy keeps each major in Maintenance LTS for two years after its release (see our note on Next.js 15 maintenance and EOL).

The real difference: who owns the rendering model

Next.js treats Server Components as the foundation. TanStack's own framework comparison lists RSC in Start as "Experimental, opt-in," and the 1.0 post says the team stopped using RSC on tanstack.com because it became hard to reason about what ships where. That is an opinion, but it tells you where the framework will invest.

The table comes from TanStack's comparison page, which is unusually fair for a vendor doc. It says outright that existing team experience and integrations can make staying on Next.js the better choice, and that comparing a router's bundle size against a full framework "is not a valid application benchmark." Our Next.js vs TanStack Start comparison tracks the same trade-offs.

Deployment without adapters

One quiet change is how Start reaches hosts. The 1.0 post says the team stopped maintaining per-host deployment adapters and leans on Vite and Nitro instead. Named partners include Cloudflare Workers, Netlify, Railway, Render and Vercel.

That cuts both ways. You avoid a framework-specific adapter lagging behind your host, but behavior like ISR now depends on the provider. The comparison page warns that "a CDN honoring stale-while-revalidate is not proof of identical ISR behavior across providers." If your SEO depends on long-tail pages being regenerated on a schedule, test that on your actual host before you commit. A generated sitemap.xml and spot checks of response headers will tell you more than any framework doc.

Because Start runs on Vite, the Vite 8 and Rolldown changes are now part of your framework upgrade path too.

What a Next.js migration really involves

TanStack publishes a migration guide from Next.js, and its first piece of advice is the right one: you do not need to remove Next.js before testing Start. Remove it only after the migrated behavior and a rollback plan are verified.

The mechanical part is a file mapping. app/layout.tsx becomes src/routes/__root.tsx, app/posts/[slug]/page.tsx becomes src/routes/posts.$slug.tsx, and route handlers become server handlers in route files. The guide warns that layouts, route groups, parallel routes and intercepting routes need to be mapped one by one, not renamed.

The non-mechanical parts are where the time goes:

• Server Actions. They become createServerFn functions called through useServerFn, followed by router.invalidate(). The guide says plainly not to treat createServerFn as a drop-in replacement for the React form Action protocol, and that invalidation does not clear CDN or database caches.
• Metadata. generateMetadata becomes head configuration derived from loader data, and app/sitemap.ts becomes a server route at /sitemap.xml. Re-check titles, canonicals and Open Graph tags after the move; our meta tag generator and canonical tag generator are handy for diffing output.
• Images and fonts. "Start does not automatically provide the Next.js image optimizer." You need an image service and a font strategy such as self-hosted files.
• Environment variables. Move server-only variables into the server runtime and audit public prefixes instead of copying the old environment wholesale.

If your app leans on Next.js caching semantics, read our breakdown of Next.js 16 explicit caching first. Every revalidatePath and tag needs a new owner.

Who should switch, and who shouldn't

Good fits for Start

• Dashboards and internal tools where URL search state, typed params and client data caching (Start pairs router loader caching with TanStack Query) do the heavy lifting.
• Teams already on TanStack Router or Query, where Start is mostly adding a server.
• Apps that want SSR on some routes and a plain SPA on others without restructuring components.

Stay on Next.js for now

• Apps built around Server Components and Server Actions, where Start's RSC support is still labeled experimental.
• Content sites that rely on next/image, next/font and ISR working the same way everywhere.
• Teams that need a published support window for compliance or procurement.

For a new project, the decision is closer than it has ever been. Use our guide to comparing developer tools and score both on your own app's top three routes, not on benchmarks. You can also browse alternatives like Next.js vs Remix.

FAQ

Is TanStack Start production-ready?

TanStack says yes. The 1.0 announcement on 13 October 2026 calls Start stable and ready for production, though it does not publish a formal semver or support-window policy.

Does TanStack Start support React Server Components?

Yes, as an opt-in. TanStack's comparison page lists RSC in Start as experimental and opt-in, and the 1.0 post says you can opt in or out without changing the rest of the app.

Can I migrate from Next.js to TanStack Start incrementally?

TanStack's migration guide says you do not need to remove Next.js, its configuration or its CSS tooling before testing Start, and recommends removing Next.js only after migrated behavior and a rollback plan are verified.

Does TanStack Start have an equivalent of next/image?

No. The migration guide states that Start does not automatically provide the Next.js image optimizer. Plain img tags work for preprocessed assets, and transformations need a compatible image service.

Which hosts can run TanStack Start?

The 1.0 post says Start relies on Vite and Nitro instead of per-host adapters, and names Cloudflare Workers, Netlify, Railway, Render and Vercel as deployment partners.

Start did not win by copying Next.js. It won a seat by betting on routing and types instead. Pick the bet that matches your app.