What's New in Next.js 15.3: Turbopack, RSpack, Adapters

TL;DR

Next.js 15.3 brings Turbopack builds in alpha, delivering 28% faster builds on 4 cores, 60% on 16 cores, and 83% on 30 cores because Turbopack is written in Rust and uses multi-threading. It also adds official community support for RSpack as a Webpack alternative and introduces a deployment adapters API, signaling a shift toward a more modular, deploy-anywhere philosophy at Vercel.

Transcript

I need to be real with y'all. It's been pretty hard to defend Nex.js over the last 2 years. There's a lot I love about it, but there have been a lot of things that rightfully people have been upset about. There's even a few that I'm personally very burned about. Don't get me started on the Turbo Pack stuff. It's it's been a lot. That said, there's ... Read More

Key Insights

• Turbopack now supports builds in alpha in Next.js 15.3, a milestone because build tooling was historically tied directly to Next.js. It shouldn't be used for production yet, though Vercel is already using it in production internally.
• Turbopack build speed scales with CPU threads because it is written in Rust: 4 cores gives a 28% improvement, 16 cores gives 60%, and a 30-core cloud machine gives 83% faster builds. This threading fundamentally changes expected build performance.
• Over half of dev sessions on Next 15 already use Turbopack, which has had dev support for a while. It cuts dev environment startup from minutes to seconds with hot reloading under 100 milliseconds most of the time.
• Vercel's 'are we turbo yet' page now defaults to production, where Turbopack must pass 8,095 tests. It is very close with only 57 tests left, meaning most projects should already be able to build using it.
• Next.js 15.3 adds official community support for RSpack as a Webpack alternative. Vercel directly reached out to the RSpack team, breaking the historically deep tie between Next.js and Webpack or Turbopack for the first time.
• The deployment adapters API aims to let Next.js deploy anywhere, including serverless platforms with custom requirements. It makes it easier for platforms like Netlify to support Next.js despite their different infrastructure needs.
• Next.js works well on Vercel not because it was built to resist other hosts, but because Vercel's infrastructure splits Next into separate environments: compute for APIs and page gen, a CDN for static assets, and edge compute for middleware redirects.
• The deployment adapters proposal is an RFC because Vercel wants community input to get it right, learning lessons from projects like Open Next so limitations come from the target environment itself, not from the Next-to-environment integration.

Questions & Answers

Q: What is the biggest change in Next.js 15.3?

The biggest change is that Turbopack now supports builds in alpha, which is significant because build tooling has historically been part of Next.js directly. While it shouldn't be used for production just yet, Vercel has already been using it in production internally. This brings faster build times because Turbopack, written in Rust, can take advantage of multi-core and multi-threading on your processor.

Q: How much faster are Turbopack builds compared to before?

Turbopack build speed scales with the number of CPU threads because it was written in Rust to use processors better. On four cores you'll see a 28% speed improvement, on 16 cores you'll see 60%, and on a 30-core machine, likely a cloud worker rather than a desktop, you'll see 83% faster builds. This threading scaling fundamentally changes the build performance developers should expect.

Q: Is Turbopack ready for production builds in Next.js 15.3?

Not fully yet. Because builds are in alpha, you probably shouldn't use it for production, though Vercel is already using it in production internally. Vercel's 'are we turbo yet' page now defaults to production, where Turbopack must pass 8,095 tests. It is very close, with only 57 tests left, so most projects should at least be able to build using it.

Q: What is RSpack and why does its Next.js support matter?

RSpack is an alternative to Webpack, and as of the Next.js 15.3 release there is now official community support for using RSpack instead. This matters because it breaks the historically deep tie between Next.js and Webpack or Turbopack, letting developers use options outside the Vercel ecosystem. Vercel directly reached out to the RSpack team, showing a shift in the Next team's philosophy toward modularity.

Q: What is the Next.js deployment adapters API?

The deployment adapters API is designed to allow Next.js to be deployed anywhere, including serverless platforms with custom requirements. Although not technically part of the 15.3 release, it was clearly meant to align with it. The goal is to make it easier for other platforms like Netlify to support deploying Next.js despite their different infrastructure expectations, so limitations come from the environment itself rather than the integration.

Q: Why does Next.js work so well on Vercel specifically?

Next.js works well on Vercel because Vercel built powerful infrastructure that splits different parts of Next into different environments: compute for API calls and page generation, a CDN for static assets, and edge compute for middleware that redirects requests. That separation is hard to build yourself and is deeply baked into Vercel. It's not that Next was built to resist other hosts; it's that Vercel enables this level of integration.

Q: Can you deploy Next.js somewhere other than Vercel?

Yes, you can absolutely deploy Next.js wherever you want, and it runs on a dedicated server with no issues. The catch is that without these new changes you can mostly only deploy it in a Docker container, since that's how Node applications run. Features like incremental static revalidation, caching, and middleware rewrites were not trivial to implement in serverless environments, which the deployment adapters API aims to address.

Q: Why is the deployment adapters proposal an RFC?

It is a request for comments because the Vercel team, and Lee in particular, really want to hear from the community to make sure they get it right if they do this. They want to learn lessons from projects like Open Next to ensure Next.js can be deployed well regardless of the target environment, so that any limitations come from the environment itself rather than from the integration between Next and that environment.

Summary & Key Takeaways

• After two years where Next.js drew justified criticism, the video argues Vercel has made a significant course correction that becomes visible in Next.js 15.3. The release bundles useful changes both inside the version and in surrounding announcements, framed as relevant even to non-Next developers watching market direction.

• The headline change is Turbopack builds in alpha. Written in Rust for multi-threading, it delivers 28% faster builds on 4 cores up to 83% on 30 cores. Vercel's 'are we turbo yet' page, now defaulting to production, has just 57 of 8,095 tests remaining.

• Beyond builds, Next.js 15.3 adds official community support for RSpack alongside Webpack, and a separate deployment adapters API RFC aims to let Next.js deploy well on any platform, reflecting a more modular philosophy where parts can come from Vercel or third parties.