Next.js 16.3'te runtime='edge' Bitti: Node'a Dönüş

Next.js 16.3 ile birlikte route ve sayfa seviyesinde runtime = 'edge' ayarı artık desteklenmiyor — Vercel'in resmi dokümantasyonu bunu net şekilde söylüyor: bu yapılandırmayı kullanan her route ve sayfa, Node.js runtime'ında çalışıyor. Eğer projende hâlâ export const runtime = 'edge' satırları varsa, bu makale sana nerede arayacağını, Node'a geçerken nelerin kırılabileceğini ve proxy.ts'in bu değişiklikten neden etkilenmediğini gösteriyor.

💡 Pro Tip: runtime = 'edge' satırını route/page dosyalarından silmek çoğu zaman hiçbir şeyi bozmaz — çünkü Node.js zaten varsayılan runtime; runtime = 'edge' yüzünden fs, native modül veya tam Node.js API yüzeyinden vazgeçmek zorunda kaldıysan, satırı silince o kodu geri getirebilirsin.

İçindekiler

• Ne değişti, tek cümlede
• İki doküman iki şey söylüyor gibi — gerçek ayrım (route/sayfa vs proxy.ts)
• runtime='edge' kullanan yerleri bulma
• Node'a taşırken kırılanlar: fs, native modül, süre limitleri
• Artık kullanabileceğin API'ler
• proxy.ts Node'da kalıyor, edge yalnız eski middleware.ts'te: sınırlar
• Fluid compute + Active CPU'nun fatura etkisi
• Kendi sunucusunda çalışanlar için anlamı
• SSS
• Next.js 16.3'te runtime = 'edge' neden çalışmıyor?
• Edge runtime tamamen kaldırıldı mı, proxy.ts'te duruyor mu?
• Edge runtime'dan Node.js runtime'a nasıl geçilir?
• Edge kalkınca cold start ve maliyet ne oluyor?
• proxy.ts'te runtime = 'edge' yazarsam ne olur?
• Sonuç
• Kaynaklar

Ne değişti, tek cümlede

Vercel'in resmi runtime dokümantasyonu şunu söylüyor: "Starting in Next.js 16.3, setting runtime = 'edge' is no longer supported. Routes and pages run on Node.js." Yani route handler'larda (route.ts), sayfalarda (page.tsx) ve layout'larda kullanılan export const runtime = 'edge' satırı artık bir etki yaratmıyor — ya da tamamen kaldırılması bekleniyor. Next.js'in kendi route-segment-config referansı da aynı yönde: runtime seçeneğinin 'edge' değeri artık "deprecated" olarak işaretli, 'nodejs' ise varsayılan ve önerilen değer.

Bunun pratik anlamı basit: 16.3 öncesinde edge runtime'ı bilinçli olarak seçmiş bir proje varsa, o kod artık (görünürde aynı davranışla) Node.js üzerinde çalışıyor. Next.js'in kendi deprecation mesaj sayfası bu geçişi şöyle özetliyor: "The Node.js runtime is the default, so no replacement is needed" — yani aksiyon genelde satırı silmekten ibaret.

Dikkat edilmesi gereken nokta şu: bu değişiklik Next.js'in 16.3 sürüm duyurusunda (blog.next-16-3) ayrı bir madde olarak öne çıkmıyor; kaldırım bilgisi Vercel'in platform dokümantasyonunda ve Next.js'in referans/mesaj sayfalarında yer alıyor. Yani bunu "Next.js resmen duyurdu" değil, "Next.js'in kendi dokümantasyonu ve Vercel'in platform dokümantasyonu sessizce güncellendi" olarak okumak daha doğru.

İki doküman iki şey söylüyor gibi — gerçek ayrım (route/sayfa vs proxy.ts)

Next.js'in kendi dokümantasyonunu taradığında kafa karıştırıcı bir çelişkiyle karşılaşabilirsin. Edge Runtime referans sayfası (/docs/app/api-reference/edge), Edge Runtime'ın kullanıldığı yer olarak Proxy'yi gösteriyor gibi bir ifade taşıyor. Ama aynı anda route-segment-config referansı ve Proxy dosya-konvansiyonu sayfası tam tersini söylüyor: "This option cannot be used in Proxy" ve "Proxy defaults to using the Node.js runtime. The runtime config option is not available in Proxy files. Setting the runtime config option in Proxy will throw an error."

Bu iki ifade birbiriyle gerçekten çelişiyor — ve bu, dokümantasyonun güncellenmemiş bir kalıntısı gibi duruyor, senin kodunda bir belirsizlik değil. Gerçek davranış nettir: proxy.ts dosyası hiçbir zaman `runtime = 'edge'` set edilmesine izin vermiyor, varsayılan olarak Node.js runtime'ında çalışıyor ve bu ayarı denersen hata alırsın. Route/page seviyesindeki runtime = 'edge' ise ayrı bir hikaye: 16.3'e kadar "deprecated ama çalışır" durumdaydı, 16.3'te resmen desteklenmez oldu.

Burada asıl karışan nokta zaman çizelgesi. Proxy'nin Node.js runtime'ını varsayılan yapması ve runtime config'ini reddetmesi 16.0.0 sürümünde geldi (middleware'in Proxy olarak yeniden adlandırılmasıyla birlikte) — 16.3'te değil. 16.3'te değişen şey Proxy değil, route ve sayfa segment'lerindeki runtime = 'edge' desteğinin tamamen kalkması. Bu iki farklı sürümü, iki farklı mekanizmayı birbirine karıştırmamak, bu makalenin en kritik noktası.

runtime='edge' kullanan yerleri bulma

Migrasyona başlamadan önce projende runtime = 'edge' export'u kullanan tüm dosyaları bulman gerekiyor. Bu satır yalnızca route handler'larda, sayfalarda ve layout'larda geçerli bir segment config'tir — proxy.ts'te zaten kullanılamıyor, o yüzden aramanı app/ dizinindeki route/page/layout dosyalarına odaklayabilirsin.

1grep -rn "runtime.*=.*['\"]edge['\"]" app/ --include="*.ts" --include="*.tsx"

Bulduğun her satır adayı için üç soru sor: (1) Bu satır gerçekten gerekli mi, yoksa eski bir kopyala-yapıştır mı? (2) İçindeki kod fs, native bir Node.js modülü veya edge'in desteklemediği bir API mi kullanıyor? (3) Kaldırdığında route hâlâ derleniyor mu? Next.js'in kendi deprecation mesajı da aynı yaklaşımı öneriyor: satırı sil, çünkü Node.js zaten varsayılan runtime ve genelde başka bir değişiklik gerekmiyor.

Bir route dosyasının önceki ve sonraki hâli şöyle görünür:

1// Önce (16.3 öncesi, artık desteklenmiyor)
2export const runtime = "edge";
3 
4export async function GET(request: Request) {
5  return new Response("ok");
6}

1// Sonra (Node.js varsayılan, satır tamamen kaldırıldı)
2export async function GET(request: Request) {
3  return new Response("ok");
4}

Next.js'in route-segment-config referansı bu iki değeri şöyle özetliyor: 'nodejs' (varsayılan) ve 'edge' (deprecated). Yani runtime export'unu tamamen silmek, onu açıkça 'nodejs' yazmakla aynı sonucu veriyor — ama satırı silmek daha temiz, çünkü gelecekte tekrar "edge mi kullanıyordum?" diye sormana gerek kalmıyor.

Aramanı genişletirken karışabilecek iki yanlış-pozitif var: runtime kelimesi geçen ama alakasız olan satırlar (ör. bir değişken adı olarak runtimeConfig) ve proxy.ts içindeki eski runtime referansları (ki zaten orada bu config kabul edilmiyor, dolayısıyla bulursan muhtemelen ölü kod ya da yorum satırıdır). Regex'i app/ dizinine ve .ts/.tsx uzantılarına sınırlamak, node_modules ve build çıktısındaki (.next/) sahte eşleşmeleri de otomatik eliyor.

Node'a taşırken kırılanlar: fs, native modül, süre limitleri

Edge runtime'ın en büyük kısıtı, Node.js API'lerinin büyük bölümüne erişememesiydi. Vercel'in dokümantasyonu bunu net tarif ediyor: Edge Runtime, V8 motoru üzerine kurulu ve yalnızca fetch, Request, Response gibi bir Web API alt kümesi sunuyor — fs modülü, native Node.js eklentileri veya tam Node.js API yüzeyi bu alt kümenin dışında kalıyor. Node.js runtime'ına geçtiğinde bu kısıtlar ortadan kalkıyor: dosya sistemine erişebilirsin, native modülleri (ör. görüntü işleme, kriptografi kütüphaneleri) kullanabilirsin.

Süre limitleri tarafında da fark var. Vercel'in Edge Function'ları için resmi limit şöyle: yanıt göndermeye 25 saniye içinde başlaman gerekiyor, streaming ise en fazla 300 saniye sürebiliyor. Node.js runtime'ına geçtiğinde bu, Vercel'in Node.js fonksiyon limitlerine ve Fluid Compute'un kendi kurallarına tabi oluyor — yani "süre limiti kalktı" demek yanlış olur, limit modeli değişiyor.

ISR (Incremental Static Regeneration) tarafında ise Next.js'in Edge Runtime referansı durumu açıkça yazıyor: "The Edge Runtime does not support Incremental Static Regeneration (ISR)." Yani ISR kullanan bir sayfa zaten edge'de çalışamıyordu; runtime = 'edge' kaldırımı bu sayfalar için bir davranış değişikliği yaratmıyor.

Artık kullanabileceğin API'ler

Edge'de çalışmayan ama Node.js'te sorunsuz çalışan bir route handler örneği şöyle görünür — mesela build zamanı üretilmiş bir statik dosyayı okuyup önbelleklemek istediğinde:

1import { readFile } from "node:fs/promises";
2import { join } from "node:path";
3 
4export async function GET() {
5  // Edge runtime'da node:fs desteklenmiyor — dosya sistemine
6  // okuma/yazma yapamıyorsun; Node.js runtime'ında bu çağrı normal çalışıyor.
7  const filePath = join(process.cwd(), "data", "config.json");
8  const contents = await readFile(filePath, "utf-8");
9 
10  return Response.json(JSON.parse(contents));
11}

Bu tür bir route'u 16.3 öncesinde runtime = 'edge' ile işaretlemiş olsaydın çalışmazdı: Next.js'in Edge Runtime referansı bunu net söylüyor — "Native Node.js APIs are not supported. For example, you can't read or write to the filesystem." Edge Runtime, Vercel'in dokümantasyonuna göre yalnızca fetch, Request, Response, crypto/SubtleCrypto, ReadableStream/WritableStream/TransformStream, TextEncoder/TextDecoder gibi bir Web API alt kümesi sağlıyor — node:fs bu listede yok. Node.js runtime'ında ise bu çağrı normal bir Node.js API'si gibi çalışıyor.

proxy.ts Node'da kalıyor, edge yalnız eski middleware.ts'te: sınırlar

proxy.ts (eski adıyla middleware.ts) Next.js'in istek tamamlanmadan önce sunucuda kod çalıştırmana izin veren dosya konvansiyonu. Resmi tanım şöyle: "The proxy.js|ts file is used to write Proxy and run code on the server before a request is completed... Proxy executes before routes are rendered." Yanıtı rewrite, redirect, header değiştirme veya doğrudan yanıt üretme yollarıyla değiştirebiliyorsun.

Ama Proxy'nin kendine has, resmi olarak belirtilmiş sınırları var — ve bu sınırlar runtime = 'edge' kaldırımından bağımsız, her zaman geçerli kurallar:

• Yavaş veri çekme için değil: "Proxy is not intended for slow data fetching... it should not be used as a full session management or authorization solution." Proxy'yi ağır bir DB sorgusu veya yavaş bir üçüncü parti API çağrısı için kullanmak önerilmiyor.
• fetch cache seçenekleri etkisiz: fetch'in cache, revalidate, tags seçeneklerinin Proxy içinde hiçbir etkisi yok.
• matcher olmadan her istekte çalışır: Matcher tanımlamazsan Proxy, _next/static, _next/image ve public/ klasöründeki statik dosyalar dahil her istekte çalışıyor. Auth mantığını Proxy'ye koyduysan ve matcher unuttuysan, yanlışlıkla CSS/JS/görselleri bile bu kod yoluna sokmuş olabilirsin.

1// proxy.ts — matcher ile gereksiz çalışmayı önleme
2export const config = {
3  matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"],
4};

Resmi upgrade rehberi bu konuda net ve aksiyon alınabilir bir talimat veriyor: "The edge runtime is NOT supported in proxy. The proxy runtime is nodejs, and it cannot be configured. If you want to continue using the edge runtime, keep using middleware." Yani edge runtime proxy'de desteklenmiyor, proxy'nin runtime'ı nodejs ve yapılandırılamıyor; edge'e devam etmen gerekiyorsa middleware dosyasında kalman söyleniyor. Rehber hemen ardından ilerideki bir minor sürümde ek edge yönergeleri geleceğini de belirtiyor: "We will follow up on a minor release with further edge runtime instructions."

Bunun bir maliyeti var: Next.js 16 duyurusu middleware.ts'in ömrünü açıkça sınırlı ilan ediyor — "The middleware.ts file is still available for Edge runtime use cases, but it is deprecated and will be removed in a future version." Yani edge için middleware dosyasında kalmak geçerli ama kalıcı bir çözüm değil; deprecated bir dosya konvansiyonunda beklemek anlamına geliyor.

Fluid compute + Active CPU'nun fatura etkisi

Vercel'in Fluid Compute modeli, 23 Nisan 2025'ten beri yeni projelerde varsayılan olarak etkin. Fluid Compute, serverless'ın esnekliğiyle sunucu-benzeri yetenekleri (çoklu isteklerin tek bir instance'ta paylaşılması, waitUntil ile arka plan işleme, otomatik cold-start optimizasyonu) birleştiriyor.

Faturalama tarafında en önemli fark Active CPU kavramı: kod yalnızca fiilen çalıştığı milisaniyeler için faturalandırılıyor. Bir veritabanı sorgusu veya bir AI model çağrısı beklerken (I/O bekleme süresi) CPU faturalaması duruyor — ama Provisioned Memory faturalaması bu bekleme sırasında da devam ediyor. Resmi dokümantasyon bunu şöyle özetliyor: "You are only billed during actual code execution and not during I/O operations" (CPU için) ve memory için "Continues billing while handling requests, even during I/O operations."

Bölgesel fiyat farkları da var — örneğin Frankfurt (fra1) bölgesinde Active CPU $0.184/saat, Provisioned Memory $0.0152/GB-saat iken Washington D.C. (iad1) bölgesinde Active CPU $0.128/saat. Node.js runtime'ına geçiş, bu faturalama modelini değiştirmiyor; hem edge hem Node.js fonksiyonları artık aynı Fluid Compute + Active CPU çerçevesinde çalışıyor. Vercel, Node.js'e geçişi "improved performance and reliability" gerekçesiyle öneriyor; sayısal bir cold-start veya maliyet kıyası yayımlamıyor.

Kendi sunucusunda çalışanlar için anlamı

Eğer projen Vercel'de değil de kendi VPS'inde, bir Node.js standalone server ve systemd servisi olarak çalışıyorsa (bu sitenin portfolio-ssr.service kurulumu gibi), bu değişiklik senin için pratikte bir davranış kırılması yaratmıyor. runtime = 'edge' zaten Vercel'in Edge Function altyapısına özgü bir optimizasyon seçeneğiydi — Edge Runtime'ın V8-izole, container gerektirmeyen çalışma modeli, kendi sunucunda zaten anlamsız bir kavram, çünkü tüm process zaten tek bir Node.js runtime'ında çalışıyor.

Bunun tek somut etkisi şu: projende hâlâ runtime = 'edge' export'u varsa, bunu kaldırman gerekiyor — aksi halde build zamanında deprecation uyarısı alırsın. Fluid Compute ve Active CPU faturalama modeli tamamen Vercel'in platformuna özgü; kendi sunucunda bunun hiçbir karşılığı yok, çünkü zaten sabit bir process için sabit bir kaynak ayırmışsındır (systemd servis + sabit RAM/CPU).

Migrasyon adımlarını tek bir kontrol listesinde toplarsak:

• Ara: grep -rn "runtime.*edge" app/ ile tüm adayları listele.
• Kaldır: Her route/page dosyasından export const runtime = 'edge' satırını sil (Node.js zaten varsayılan).
• Derle: next build çalıştır, deprecation uyarısı kalmadığını doğrula.
• Proxy'yi ayrı tut: proxy.ts dosyalarına runtime config'i ekleme — zaten kabul edilmiyor ve hata fırlatıyor.
• Matcher kontrol et: Proxy'nin gereksiz yere statik dosyalarda çalışmadığından emin ol.
• fs/native modül testi: Edge'de çalışmayan ama artık kullanmak istediğin Node.js API'lerini (dosya sistemi, native kripto) route'lara ekle ve test et.

SSS

Next.js 16.3'te runtime = 'edge' neden çalışmıyor?

Vercel'in resmi dokümantasyonu bunu doğrudan söylüyor: "Starting in Next.js 16.3, setting runtime = 'edge' is no longer supported. Routes and pages run on Node.js." Next.js'in kendi route-segment-config referansı da edge değerini deprecated olarak işaretliyor ve nodejs'i tek önerilen değer olarak gösteriyor. Yani bu bir hata değil, framework'ün Node.js'i tek standart runtime hâline getirme yönündeki bilinçli kararı.

Edge runtime tamamen kaldırıldı mı, proxy.ts'te duruyor mu?

Aslında ikisi de tam doğru değil. proxy.ts (eski middleware.ts) zaten Next.js 16.0.0'dan beri runtime config'ini kabul etmiyor ve varsayılan olarak Node.js'te çalışıyor — bu 16.3'ün değil, 16.0'ın getirdiği bir kural. 16.3'te değişen, route ve sayfa seviyesindeki runtime = 'edge' desteğinin kalkması. Resmi upgrade rehberi edge'in nerede yaşadığını da söylüyor: "If you want to continue using the edge runtime, keep using middleware." Yani edge yalnızca deprecated middleware.ts dosya konvansiyonunda kalıyor. Next.js'in Edge Runtime API referans sayfası hâlâ Edge'i Proxy'yle ilişkilendiren eski bir ifade taşıyor, ama bu resmi upgrade rehberiyle ve proxy dosya-konvansiyonu sayfasıyla çelişen, güncellenmemiş bir satır gibi görünüyor.

Edge runtime'dan Node.js runtime'a nasıl geçilir?

Route/page dosyalarındaki export const runtime = 'edge' satırını tamamen silmen yeterli — Node.js zaten varsayılan runtime olduğu için başka bir değişikliğe gerek kalmıyor. Silmeden önce grep -rn "runtime.*edge" app/ ile tüm adayları listelemen, sonra her birinde edge'in desteklemediği bir API'ye (fs, native modül) ihtiyaç olup olmadığını kontrol etmen öneriliyor.

Edge kalkınca cold start ve maliyet ne oluyor?

Bu soruya kesin bir rakamla cevap vermek şu an mümkün değil — Next.js'in 16.3 sürüm duyurusu bu konudan hiç bahsetmiyor, Vercel'in genel dokümantasyonu da yalnızca Node.js'e geçişi "improved performance and reliability" için önerdiğini söylüyor, somut bir cold-start veya maliyet kıyası yayımlamıyor. Bilinen tek şey, hem edge hem Node.js fonksiyonlarının artık aynı Fluid Compute + Active CPU faturalama modeli altında çalıştığı — Active CPU yalnızca kodun fiilen çalıştığı süre için ücretlendiriyor, I/O bekleme sırasında CPU faturalaması duruyor ama memory faturalaması devam ediyor.

proxy.ts'te runtime = 'edge' yazarsam ne olur?

Hata alırsın. Proxy dosya-konvansiyonu referansı net: "The runtime config option is not available in Proxy files. Setting the runtime config option in Proxy will throw an error." Bu, route/page'lerdeki deprecation uyarısından farklı — Proxy'de bu ayarı denemek doğrudan build/runtime hatasıyla sonuçlanıyor.

Sonuç

Next.js 16.3'ün runtime = 'edge' kaldırımı, kod tabanının çoğu için tek satırlık bir temizlik: route ve sayfalardaki bu export'u silmek, Node.js zaten varsayılan olduğu için genelde başka hiçbir şeyi bozmuyor. Asıl dikkat etmen gereken nokta, bunun proxy.ts'teki (16.0'dan beri zaten Node.js'e bağlı) davranıştan tamamen ayrı bir değişiklik olması — iki farklı sürüm, iki farklı mekanizma.

Backend tarafında edge/serverless ekosistemiyle daha fazla ilgileniyorsan Supabase Edge Functions ve Deno runtime yazısı, edge-native bir alternatifin nasıl çalıştığını gösteriyor; Drizzle ORM + Turso ile edge SQLite pattern'i ise edge runtime kısıtlarına uygun veritabanı erişimini ele alıyor. Serverless framework tarafını karşılaştırmak istersen Hono.js production rehberi faydalı bir referans. CI/CD pipeline'ına bu tür deprecation kontrollerini eklemek istersen iOS CI/CD Pipeline: GitHub Actions ve Fastlane yazısındaki pipeline mantığı platform bağımsız olarak uyarlanabilir. Production-ready bir API katmanı kurarken dikkat edilmesi gerekenler için Network Layer Optimization rehberi de bu makaleyle aynı disiplini paylaşıyor: varsayımla değil, kaynakla ilerlemek.

Kaynaklar

• Vercel Edge Runtime Dokümantasyonu — runtime = 'edge' desteğinin 16.3'te kalktığını ve Edge Runtime'ın V8 tabanlı Web API alt kümesini belgeliyor.
• Next.js Route Segment Config Referansı — runtime — nodejs (varsayılan) ve edge (deprecated) değerlerini ve Proxy'de kullanılamadığını belgeliyor.
• Next.js Edge Runtime Deprecated Mesaj Sayfası — "Why This Warning Occurred" başlığı altında migrasyon talimatını ("no replacement is needed") veriyor.
• Next.js 16 Upgrade Rehberi — edge runtime'ın proxy'de desteklenmediğini ve edge gerekiyorsa middleware'de kalınması gerektiğini belgeliyor.
• Next.js 16 Sürüm Duyurusu — proxy.ts'in Node.js runtime'ında çalıştığını ve middleware.ts'in deprecated olduğunu belgeliyor.
• Next.js Proxy Dosya Konvansiyonu Referansı — Proxy'nin Node.js varsayılanını, matcher davranışını ve runtime config kısıtını belgeliyor.
• Next.js Proxy Kavramsal Rehberi — middleware'den proxy'ye geçişi ve Proxy'nin kullanım sınırlarını (yavaş veri çekme, fetch cache etkisizliği) açıklıyor.
• Next.js 16.3 Sürüm Duyurusu — 16.3'ün genel iyileştirmelerini (TypeScript 7, bellek kullanımı, native stream) belgeliyor.
• Vercel Fluid Compute Dokümantasyonu — Fluid Compute'un varsayılan etkinleştirilme tarihini ve çalışma modelini belgeliyor.
• Vercel Functions Usage and Pricing — Active CPU ve Provisioned Memory faturalama mekaniğini ve bölgesel fiyatlandırmayı belgeliyor.