April 8, 2026
Two-minute builds, ten-minute comment war
We moved Railway's frontend off Next.js. Builds went from 10+ mins to under two
Railway breaks up with Next.js: 10‑min builds to 2, and the internet has opinions
TLDR: Railway ditched Next.js for Vite + TanStack Router and cut build times to under two minutes. Commenters are split between cheering the speed and calling out web tooling bloat, with a side of Vercel-versus-Railway rivalry—highlighting how teams pick tools that fit their app, not hype.
Railway just pulled a dramatic tech breakup: ditching Next.js for Vite + TanStack Router and slashing build times from 10+ minutes to under two. The company says its app is mostly client-side (think real-time dashboards), so server-first features weren’t helping—and the team shipped the migration in just two pull requests with no downtime. Cue the comments section lighting up.
The hottest take? One user pointed out that Next.js is made by Vercel, a rival to Railway—so yeah, the rivalry subplot is strong. Others mocked the 10-minute builds, joking it now takes longer to build a website than to compile the Linux kernel. Old-school devs called it a “how did we regress this far” moment, while frustrated Next.js users vented that speeding up builds feels impossible.
But not everyone came to roast. A few chimed in with “we did the same thing” stories, saying Vite’s instant reloads and TanStack’s type-safe routes feel like a joyride compared to the slow grind. Railway kept server-side rendering (SSR) only for marketing pages and went all-in on client-side for the app—simple, fast, and fun. TL;DR: it’s breakup energy meets pit crew efficiency, and commenters can’t stop arguing whether this is freedom… or just another framework fling.
Key Points
- •Railway migrated its production frontend from Next.js to Vite + TanStack Router, reducing build times from over 10 minutes to under two.
- •The app’s client-first, real-time nature conflicted with Next.js’s server-first patterns and Pages Router layout limitations; App Router was not adopted.
- •Migration occurred in two PRs: first removing Next-specific dependencies, then swapping frameworks and migrating 200+ routes, with zero downtime.
- •Nitro replaced next.config.js as the server layer, consolidating 500+ redirects, security headers, and caching; Node.js polyfills were replaced with browser-native APIs.
- •Trade-offs included losing Next.js’s built-in image optimization, replaced with standard <img> tags and Fastly edge optimization; the new stack offers type-safe routing, first-class layouts, and instant HMR.