Next.js'in Adapter API'si: Vercel dışında çalıştırmanın resmî yolu

Sorun neydi?

Bir Next.js uygulamasını tek bir sunucuda next start ile çalıştırmak her zaman mümkündü. Next.js belgelerine göre bu şekilde bütün özellikler çalışıyor. Zorluk, uygulamayı büyütünce başlıyor. Birden fazla sunucu kopyası çalıştırdığında önbelleğin kopyalar arasında senkron kalması, bir sayfayı yenile dediğinde (revalidation) bunun hepsine ulaşması, akışın (streaming) bozulmaması gerekiyor.

Vercel bunları kendi altyapısında çözüyordu. Diğer platformlarsa Next.js’in derleme çıktısını tersine çözmek zorundaydı. Çünkü çıktının biçimi belgelenmemişti ve her sürümde değişebiliyordu. Bu açığı 2023’te başlayan topluluk projesi OpenNext dolduruyordu: Next.js çıktısını AWS, Cloudflare ve Netlify’ın anlayacağı parçalara çeviriyordu.

Adapter API ne getiriyor?

Mart 2026’da çıkan Next.js 16.2 ile Adapter API kararlı hâle geldi. Bu API, OpenNext, Netlify, Cloudflare, AWS Amplify ve Google Cloud mühendisleriyle yaklaşık bir yıl boyunca birlikte tasarlandı.

Fikir basit: Derleme bittiğinde Next.js uygulamanın tipli, sürümlü bir tarifini çıkarıyor. İçinde rotalar, önceden üretilen sayfalar, statik dosyalar, hangi kodun hangi ortamda çalışacağı, önbellek kuralları ve yönlendirme kararları var. Adaptör bu tarifi okuyup platformun kendi parçalarına dönüştürüyor. İki kancası (hook) var: modifyConfig ayarlar yüklenirken, onBuildComplete derleme bittiğinde çalışıyor. Adaptörü next.config.js içinde adapterPath ile gösteriyorsun. Sözleşmeyi bozan bir değişiklik ancak yeni bir ana sürümle gelebiliyor.

Güven veren kısım şu: Vercel’in kendi adaptörü de aynı açık API’yi kullanıyor. Gizli bir kanal yok ve adaptörün kodu açık.

Doğrulanmış adaptörler

Next.js ekibi kendi test paketini adaptör yazarlarına açtı. Akış, önbellek, sayfa geçişleri ve uç durumları kapsıyor. Her özellik için “geçti” ya da “kalmadı” cevabı veriyor. Bir adaptörün doğrulanmış sayılması için iki şart var: açık kaynak olması ve bu paketin tamamını çalıştırması.

Belgeler iki seviyeyi ayırıyor. İşlevsel doğruluk testlerle ölçülüyor: Bir özellik ya çalışıyor ya çalışmıyor. Performans ise platformdan platforma değişiyor. Örneğin sayfanın statik kabuğu CDN’den mi geliyor, yoksa ana sunucudan mı? Platformlar bu noktada yarışacak.

API ilk çıktığında hazır iki adaptör vardı: Vercel ve Bun. Bölümde Jimmy Lai, Bun adaptörünün önbellek için Bun’ın yerleşik SQLite’ını kullandığını anlattı. Cloudflare, Netlify ve AWS adaptörlerinin OpenNext üzerinden yıl içinde gelmesi bekleniyordu.

Neden Vite değil?

Syntax’ta Tim Neutkens’a Next.js’in neden Vite’a geçmediği de soruldu. Cevabı, Webpack’in büyük uygulamalarda yavaşladığı ve Server Components ile sunucu ve tarayıcı derlemelerini birlikte yönetmenin zorlaştığıydı. Bu yüzden kendi derleyicileri Turbopack’i yazdılar. Videoya göre Next.js 16’da geliştirme oturumlarının yüzde 92’si artık Turbopack’le çalışıyor. Vite tarafında giden yolu ise Cloudflare açtı: vinext yazımızda Next.js API’sini Vite üzerinde yeniden yazan projeyi anlattık.

Sonra ne oldu?

Next.js belgelerinin Ağustos 2026 hâlinde doğrulanmış adaptör listesinde hâlâ sadece Vercel ve Bun var. Cloudflare ve Netlify, Adapter API üzerine kurulu doğrulanmış adaptörler üzerinde çalışıyor. O zamana kadar kendi entegrasyonlarını sunuyorlar. Next.js’in GitHub organizasyonunda bir de Kubernetes adaptörü deposu açıldı.

Düşün

• Kendi sunucunda tek kopya Next.js çalıştırıyorsan, ikinci kopyayı eklediğinde önbellek ve revalidation nasıl davranacak?
• Bir barındırma hizmeti seçerken “destekliyoruz” demesine mi, yayımlanmış test sonuçlarına mı güvenirsin?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.