We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2

TL;DR Highlight

This is a practical experience of Railway migrating its production frontend from Next.js to Vite + TanStack Start, reducing build times from over 10 minutes to under 2 minutes. Teams that deploy multiple times a day can feel how build time directly affects development speed.

Who Should Read

Frontend developers who are operating client-centric dashboards or SPAs with Next.js and are experiencing increasing build times or feel it doesn't align with a server-first paradigm. Especially for teams that deploy multiple times a day and want to resolve build bottlenecks.

Core Mechanics

Railway's production frontend (dashboard, canvas, entire railway.com) has been fully transitioned from Next.js to Vite + TanStack Router, completing the migration without downtime in just two PRs.
Existing Next.js builds took over 10 minutes, with 6 minutes being Next.js's own processing time, especially stuck in the 'finalizing page optimization' stage for nearly half the time. For teams deploying multiple times a day, this wasn't just an inconvenience but a heavy tax on each iteration.
Railway apps have a rich state-based interface for the dashboard and a real-time, WebSocket-heavy structure for the canvas, fundamentally incompatible with Next.js's server-first design approach.
Trying to handle layout sharing while maintaining the Pages Router led to adding custom abstractions on top of the framework, with all layout patterns being workarounds rather than framework features. Switching to the App Router would solve some problems, but it would enforce a server-first paradigm, which also didn't fit.
The reasons for choosing TanStack Start + Vite are fourfold: type-safe routing with automatic inference of route and search parameters, Pathless Layout Route supporting layouts as a first-class concept, a fast development loop with virtually no feedback loop due to instant HMR, and the flexibility to apply SSR selectively where needed, such as on marketing pages.
The migration was divided into two stages. PR 1 replaced Next.js dependencies such as next/image, next/head, and next/router with native browser APIs or framework-agnostic alternatives without touching the framework itself. PR 2 actually migrated over 200 routes.
Added Nitro as the server layer and replaced next.config.js with Nitro configuration. Integrated over 500 redirects, security headers, and caching rules in one place. Also, replaced Node.js APIs (Buffer, url.parse, etc.) that Next.js polyfilled with browser-native alternatives, resulting in cleaner code.

Evidence

There was a case sharing from a team that experienced a similar migration. Integrating a Next.js landing page and a TanStack Router SPA into a single Vite + TanStack Start app reduced build time from 12 minutes to under 2 minutes, and it no longer made sense to fight Next.js's server-first assumptions in a client-centric, real-time state app.
There were reports that Next.js builds were particularly slow on the Railway platform. Railway is container-based, so a 2-minute build on Vercel takes 12 minutes on Railway, while direct VPS deployment takes about 20 seconds. This adds context to Railway's migration decision.
There was concern that developers using AI coding tools would be more strongly drawn to Next.js/Vercel, given that LLMs are very familiar with Next.js and the Vercel ecosystem and Vercel is aggressively investing in LLM tool integration.
There was also critical feedback that 2 minutes is still too long. There were comments like 'a 2-minute build is still ridiculous' and a cynical response like 'amazing that 10 minutes was normal. How far we've fallen'.
It was pointed out that the original article did not mention which version of Next.js was being used or whether Turbopack was enabled. Since build times could change if Turbopack was enabled, the point of comparison is unclear.

How to Apply

If your current Next.js app is client-centric (SPA, dashboard, real-time features-focused) and builds take 5 minutes or more, you can refer to the method of migrating in two PRs. Replacing Next.js-specific APIs such as next/image, next/head, and next/router with framework-agnostic alternatives in the first PR, and then replacing the framework itself in the second PR can reduce risk.
If you are managing over 500 redirects, security headers, and caching rules in next.config.js, you can move them to a Nitro server layer and integrate them into a single file. Like Railway's case, you can achieve both configuration file unification and code cleanup.
If you are implementing layouts on top of the Pages Router with custom abstractions, TanStack Router's Pathless Layout Route can replace those workarounds. You can also automatically obtain file system-based route generation and type-safe routing.
If you need image optimization without next/image, you can use edge image optimization from a CDN like Fastly, as Railway did, or leverage external services like Cloudflare Image Resizing to achieve the same effect without framework dependency.

Terminology

TanStack StartA fullstack framework based on TanStack Router (a type-safe client routing library). It uses Vite as a build tool and aims for a client-first approach.

NitroA universal server engine that can be deployed to various environments such as serverless, edge, and Node.js. It can replace Next.js's server functionality or be used independently.

HMRAbbreviation for Hot Module Replacement. A feature that replaces only the changed modules in real-time without refreshing the entire browser when modifying code. It significantly increases feedback speed during development.

Pathless Layout RouteA feature of TanStack Router that allows you to share layouts (headers, sidebars, etc.) across multiple routes without affecting the URL path. It replaces workarounds that were previously used to forcibly implement layouts in the Pages Router.

Pages RouterAn older routing method in Next.js. The structure is such that files in the pages/ folder directly become URLs. It has limitations in layout sharing and often requires custom abstractions.

PolyfillCode that mimics the same functionality as the latest browser APIs or Node.js APIs in environments that do not support them. Replacing Next.js's Node.js polyfills such as Buffer and url.parse with browser-native APIs is an example of this.