For years, deploying full-stack Next.js applications outside of Vercel has meant navigating a complex landscape of internal, undocumented APIs. To support features like Incremental Static Regeneration (ISR) or Middleware, hosting providers like Firebase had to rely on experimental workarounds. While we found some success with our early integrations, these solutions were often fragile—better left to the adventurous than to production-critical apps. After all, even a minor framework update could break those reverse-engineered “black-box” solutions.

As a member of the Next.js Deployment Adapters Working Group, I’ve been working alongside fellow Firebasers and stakeholders from Vercel, Netlify, Cloudflare, and AWS to build a better way.

With the release of Next.js 16.2, we are excited to share the first major milestone of this collaboration: the stable Deployment Adapter API.

Why this is a win for you

The Deployment Adapter API creates a first-class contract between the Next.js framework and the hosting provider. Instead of “hacking” the framework to fit our infrastructure, Next.js now provides an official, documented path for Firebase to plug in our capabilities natively.

• First-class experience: This API is the bedrock for the next generation of adapters for Firebase App Hosting. By influencing the internals of the framework, we can better optimize how Next.js interacts with Google Cloud’s global infrastructure, ensuring that functionality and performance is predictable.
• Long-term support (LTS): Because we’re building on stable APIs, we can finally offer true support across majors, rather than cautiously one minor at a time. You can upgrade with confidence, knowing that the “glue code” between Next.js and Firebase is now a part of the framework’s own test suite.
• Security through Standardization: Standardized interfaces mean a smaller surface area for bugs. When a security vulnerability is patched in the framework, we no longer have to worry that the fix will break a reverse-engineered API we were relying on. This allows us to ship critical security updates to your hosting environment faster than ever before.

The “starting line” for framework portability

As our peers at Netlify have noted, this is a major milestone, but it’s just the beginning.

While the Adapter API is now stable, existing advanced features like Cache Components (formerly PPR) and the Proxy (formerly Middleware) still present architectural hurdles for providers. These features require novel edge routing capabilities—like stitching static shells with dynamic streams in front of the CDN layer—that the working group is still standardizing.

This update doesn’t mean every Next.js feature is available or behaves identically across every provider yet, but it does mean we finally have a shared foundation to solve these challenges openly and collaboratively moving forward. I’m excited that Firebase will be at the forefront, representing Google Cloud, in the new Next.js Ecosystem Working Group.

Time to migrate: from experiment to production

If you’ve been using the “Web Frameworks experiment” in Firebase Hosting, now is the perfect time to plan your move to App Hosting. While that experiment paved the way, Firebase App Hosting is where we are doubling down. It’s built from the ground up on top of Google Cloud Run and will leverage these new industry standards, offering the stability, performance, and deep integrations (like Cloud Secret Manager and VPC support) that production apps require.

See Get started with App Hosting for a quickstart.

Check out what our fellow working group members are saying:

• Next.js: Next.js Across Platforms: Adapters, OpenNext, and Our Commitments
• Netlify: The Next.js Adapter API just shipped, here’s what comes next
• OpenNext: 3 Years of OpenNext

Next.js 16.2 is our new baseline for stability. We can’t wait to see what you build on the new, open foundations of Firebase App Hosting.