Next.js 15'in desteği 21 Ekim 2026'da sona eriyor. Bu tarihten sonra 15.x üzerindeki bir uygulama kritik hata düzeltmelerini ve güvenlik yamalarını düzenli olarak almayacak; 2026 da bu yamaların ne kadar sık gerektiğini gösterdi. Bu rehberde uygulamaları Azure App Service üzerinde Next.js 16.4 ve Node 24'e taşımak için bir plan öneriyoruz: tek seferde değil, iki sürümde. Zorunlu kısım küçük bir deploy ile çıkıyor, opsiyonel kısım daha sakin bir sprint'i bekliyor.

Next.js 15 destek sonu neden 21 Ekim?

Next.js destek politikasına göre yeni bir major sürüm çıktığında bir önceki sürüm Maintenance LTS aşamasına geçiyor. Bu aşamada yalnızca kritik hata düzeltmeleri ve zorunlu güvenlik güncellemeleri yayınlanıyor ve her major sürüm ilk çıkışından itibaren iki yıl destekleniyor. Next.js 15, 21 Ekim 2024'te yayınlandı; dolayısıyla pencere 21 Ekim 2026'da kapanıyor. Politika sayfası tarihi açıkça yazmıyor, kuralı belirtiyor. Ama Next.js 14'ün desteğini 26 Ekim 2025'te bitiren hesap da aynıydı.

Destek bittikten sonra Vercel, desteklenmeyen bir sürümü ancak nadir durumlarda ve açığın ciddiyetine göre yamalayabileceğini söylüyor. Bu bir ihtimal; production'ı üzerine kurabileceğiniz bir plan değil.

2026'nın güvenlik takvimi durumu net özetliyor:

  • Temmuz: 16.2.11 ve 15.5.21, dört yüksek ve beş orta önem dereceli açığı kapattı.
  • Ağustos: 16.3.3 ve 15.5.24, iki kritik açığı kapattı.
  • 30 Eylül: 16.3.8 ve 15.5.27 bir yüksek, beş orta ve bir düşük önem dereceli açığı kapattı. Bir kritik ve bir yüksek açığın düzeltmesi ise upstream bağımlılıklardaki gecikmeler yüzünden ertelendi.
  • 14 Ekim: 16.4.1 ve 15.5.28 ile çıkan plan dışı güncelleme, ertelenen iki düzeltmeyi bir kritik düzeltmeyle birlikte yayınladı: toplamda iki kritik ve bir yüksek önem dereceli açık.

15.5.28, 15.x hattının en son yaması; 21 Ekim'den sonra 15.x için yeni yama garanti değil. Hâlâ 15.x kullanıyorsanız bugün 15.5.28'e güncelleyin ve 16'ya geçişi planlayın. 16.4.0 6 Ekim'de yayınlandı; bu yazının yazıldığı tarihte güncel kararlı sürüm 16.4.2.

Plan: tek değil, iki sürüm

Next.js 16, zorunlu breaking change'leri yeni ve opt-in bir cache modeliyle birlikte getiriyor. İkisini aynı deploy'a koyarsanız bir regresyonun hangi değişiklikten geldiğini ayırt etmek zorlaşır. İşi şöyle bölün:

1. sürüm (şimdi) 2. sürüm (sonraki sprint)
Hedef Desteklenen sürüme geçmek Yeni cache modelini benimsemek
Runtime Her yerde Node 24 Değişiklik yok
Bundler Turbopack, gerekirse --webpack webpack config'i taşı, flag'i kaldır
Middleware Gerçekten Edge gerekmiyorsa proxy'ye çevir Kalan Edge middleware'i yeniden değerlendir
Cache Components Kapalı Route route aç
  1. sürümün amacı en küçük diff ile desteğe kavuşmak. 2. sürüm ise 16.x'in sunduklarından gerçekten faydalandığınız aşama.

1. sürüm: Node ve Next.js geçişi adım adım

Adım 1: Her yerde Node 24'e geçin

Önce runtime'ı, ayrı bir commit'te değiştirin; böylece bir Node sorunu Next.js sorunu gibi görünmez. Sürümün tanımlı olduğu her yeri güncelleyin: geliştirici makineleri, Dockerfile, CI ve App Service.

# Geliştirici makineleri
echo "24" > .nvmrc

# Azure App Service (Linux)
az webapp config set --resource-group <rg> --name <app> --linux-fx-version "NODE|24-lts"

FROM node:24-alpine

# GitHub Actions
- uses: actions/setup-node@v4
  with:
    node-version: 24

Microsoft Learn'e göre bu App Service ayarı Node.js sürümünü hem runtime'da hem de Kudu'daki otomatik paket kurulumunda belirliyor; yani build ve çalışma ortamı aynı sürümde kalıyor.

Neden 22 değil de 24? Node 22'nin desteği 30 Nisan 2027'de bitiyor; Microsoft da Azure Functions'ta Node 22 için aynı tarihi veriyor. Node 24 ise 30 Nisan 2028'e kadar destekleniyor. Altı ay içinde runtime'ı iki kez yükseltmek boşa emek. Azure tarafında iki ayrıntı var:

  • Yalnızca major sürümü hedefleyin. Microsoft Learn, App Service'te belirli bir minor ya da patch sürüme sabitlemeyi önermiyor; bu sürümlerin erişilebilir kalması garanti değil.
  • Microsoft'un Azure Functions dokümanına göre Linux Consumption planında desteklenen son Node.js sürümü Node 22; Node 24 isteyen Functions uygulamalarının Flex Consumption'a geçmesi gerekiyor. Bunu bu sürümün parçası değil, ayrı bir iş olarak planlayın.

Adım 2: Resmi codemod'u çalıştırın

npx @next/codemod@canary upgrade latest

Codemod; sürüm yükseltmesini, Turbopack config'inin taşınmasını, next lint'ten ESLint'e geçişi, middleware'in proxy olarak yeniden adlandırılmasını ve unstable_ öneklerinin kaldırılmasını üstleniyor. 16.4 ile gelen next upgrade --agent komutu da kod asistanlarına sürüme özel yükseltme rehberliği veriyor. İkisini de ilk geçiş olarak görün ve diff'i her pull request gibi inceleyin.

Adım 3: Yalnızca kırılanı düzeltin

next build çalıştırın ve hataları tek tek çözün. En sık karşılaşılanlar:

  • Senkron request API'leri. cookies(), headers(), params ya da searchParams değerlerini senkron okumak 15'te sadece uyarı veriyordu; 16'da doğrudan hata veriyor.
import { cookies } from 'next/headers'

export default async function Page({
  params,
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params
  const theme = (await cookies()).get('theme')?.value
  // ...
}
  • Özel webpack config'i. Turbopack artık production build'lerde varsayılan ve özel webpack yapılandırması olan bir proje bilinçli olarak build hatası veriyor. Bu config'i son gün baskısıyla taşımaya çalışmayın. "build": "next build --webpack" tanımlayın, taşımayı 2. sürüme bırakın.
  • Middleware. Yeni proxy.ts, Node.js runtime'ında çalışıyor ve proxy adlı bir fonksiyon export ediyor. Resmi rehber, Edge middleware'in körü körüne yeniden adlandırılmaması konusunda uyarıyor. Sizinki gerçekten Edge'e bağımlıysa şimdilik middleware.ts'yi koruyun: deprecated ve ileride kaldırılacak, ama hâlâ çalışıyor.
  • Kaldırılan özellikler: AMP, next lint, serverRuntimeConfig/publicRuntimeConfig, devIndicators seçenekleri, experimental.ppr, dynamicIO ve useCache flag'leri ile unstable_rootParams. Parallel route slot'ları artık default.js istiyor.
  • revalidateTag artık bir cache profilini belirten ikinci bir argüman bekliyor.
revalidateTag('products', 'max') // ikinci argüman: cache profili

Canlıya çıkmadan önce minimum Node.js, TypeScript ve tarayıcı sürümleri için resmi yükseltme rehberini kontrol edin.

Adım 4: Sessiz değişiklikleri staging'de test edin

Bazı değişiklikler hiç hata fırlatmıyor; olaylara asıl yol açanlar da bunlar:

  • Görsel cache TTL'i. images.minimumCacheTTL varsayılanı 60 saniyeden 14400'e (dört saat) çıktı. CMS'iniz görselleri aynı URL altında değiştiriyorsa editörler eski görselleri görür. Eski davranışa ihtiyacınız varsa değeri açıkça verin:
// next.config.js
module.exports = {
  images: { minimumCacheTTL: 60 },
}
  • Lint artık build'de çalışmıyor. next build lint adımını atlıyor; CI'a açık bir eslint . (ya da Biome) adımı ekleyin, yoksa lint hataları fark edilmeden main'e ulaşır.
  • Request anında render. Vercel'in açıklamasına göre cache artık opt-in ve page, layout ve API route'lardaki dinamik kod varsayılan olarak request anında çalışıyor. Deploy sonrasında App Service'te CPU ve yanıt sürelerini izleyin.
  • Güvenlik düzeltmeleri. 14 Ekim düzeltmelerini içermesi için 16.4.1 ya da daha yeni bir sürüm deploy edin ve daha yeni bir advisory olup olmadığını kontrol edin.

2. sürüm: Cache Components'ı route route benimseyin

  1. sürüm production'da oturduktan sonra yeni özellikler için ayrı bir sprint planlayın: Cache Components, Partial Prefetching ve ensureStatic. 16.4 duyurusuna göre bu sürüm ayrıca geliştirme ortamında daha az bellek ve disk kullanımı, daha kısa derleme süreleri, daha küçük production bundle'ları ve React 19.3 getiriyor.

create-next-app ile oluşturulan yeni projelerde Cache Components artık varsayılan olarak açık; 16.4 duyurusu bunun Next.js 17'de varsayılan olacağını söylüyor. Vercel 17 için bir tarih vermedi; bunu bir son tarih değil, gidişatın yönü olarak okuyun. Şimdiden kademeli geçmek, 17'nin ikinci büyük bir göç projesine dönüşmesini önler.

Pratik bir sıralama:

  1. Pazarlama ve SEO sayfalarıyla başlayın. Statik kalması gereken bir route'a dinamik içerik sızarsa build'i durduran ensureStatic'i ekleyin.
  2. Okuma ağırlıklı ürün sayfalarına geçin, Cache Components'ı orada açın ve öncesi/sonrası sunucu yükünü ölçün.
  3. Özel webpack config'ini Turbopack'e taşıyın ve --webpack flag'ini kaldırın.
  4. Kalan Edge middleware'leri gözden geçirin, proxy.ts'ye dönüşüp dönüşemeyeceklerine karar verin.

Yama almayı aylık bir rutine çevirin

2026'nın asıl dersi ritim. Next.js Temmuz'dan beri önceden duyurulan bir güvenlik yaması modeli kullanıyor; yaklaşan yamalar ekiplerin plan yapabilmesi için önceden ilan ediliyor. Bundan faydalanın:

  • Ekibi Next.js güvenlik duyurularına abone edin ve duyuruları ortak bir kanala yönlendirin.
  • App Service için Azure Service Health uyarıları kurun; runtime emeklilik bildirimleri uygulamanın sahiplerine ulaşsın.
  • Her ay sabit bir yama zamanı ayırın. Yükseltme yolu tek bir patch sürümü kadar kısa olduğunda kritik bir düzeltme, hafta sonu telaşı değil sıradan bir deploy olur.

Öne çıkanlar

  • Next.js 15, 21 Ekim 2026'da Maintenance LTS'ten çıkıyor; en son yaması 15.5.28 ve sonrası garanti değil.
    1. sürümü hemen çıkarın: her yerde Node 24, resmi codemod ve yalnızca build'in zorunlu kıldığı düzeltmeler.
  • --webpack flag'ini ve Edge'e bağımlı middleware'i geçici olarak koruyun; ikisi de son tarihi riske atmamalı.
  • Sessiz değişiklikleri staging'de test edin: görsel cache TTL'i, build'den çıkan lint ve request anında render yükü.
  • Cache Components, Partial Prefetching ve ensureStatic'i sonraki bir sprint'te route route benimseyin.
  • Güvenlik duyuruları ve Azure Service Health uyarılarıyla yama almayı aylık rutine dönüştürün.