Next.js'i Kendi Sunucunda Çalıştır: systemd + nginx

Next.js kendi sunucuda barındırma standalone çıktısıyla başlar: output: 'standalone' ayarını açtığında Next.js, üretim için gerekli dosyaları ve node_modules içindeki seçili paketleri tek bir klasörde toplar; böylece Vercel dışında herhangi bir VPS'te de çalıştırabilirsin. Bu rehberde bu klasörü systemd altında root olmayan bir kullanıcıyla nasıl ayağa kaldıracağını, nginx'in önüne nasıl koyacağını ve build sırasında siteyi düşürmeden nasıl deploy edeceğini adım adım göreceksin.

💡 Pro Tip: Standalone çıktısı public/ ve .next/static/ klasörlerini otomatik kopyalamaz — bunları deploy script'ine dahil etmezsen site ayakta kalır ama tüm CSS/JS 404 döner.

İçindekiler

• `output: 'standalone'` gerçekte ne üretir
• Dosya yerleşimi ve public/.next/static senkronu (klasik 404 tuzağı)
• Non-root systemd unit + hardening
• nginx reverse proxy, brotli ve immutable asset header'ları
• Build-lock ve sıfır-kesinti deploy
• ISR / 'use cache' self-host'ta nasıl davranır
• CDN (Cloudflare) önünde purge stratejisi
• İzleme ve otomatik rollback
• SSS
• Next.js standalone build kendi sunucumda nasıl çalıştırılır?
• Next.js için systemd servis dosyası nasıl yazılır?
• nginx arkasında Next.js'te static dosyalar neden 404 veriyor?
• Self-host Next.js'te ISR ve cache nasıl çalışır?
• Standalone build ile normal `next build` arasındaki fark nedir?
• Neden Next.js server'ının önüne reverse proxy koymalıyım?
• Kaç release dizinini sunucuda tutmalıyım?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

`output: 'standalone'` gerçekte ne üretir

next.config.js içine output: 'standalone' yazdığında Next.js, resmi dokümana göre "üretim deploy'u için gerekli dosyaları, node_modules içindeki seçili dosyalar dahil olmak üzere" otomatik olarak .next/standalone klasörüne kopyalayan bir standalone klasörü oluşturabilir. Bu klasörün içinde minimal bir server.js de üretilir; bu dosya next start komutunun yerini alır ve tek başına, next CLI'ına ya da tüm proje node_modules'ına ihtiyaç duymadan çalışır.

Pratikte bu, deploy paketinin boyutunu ciddi biçimde küçültür: .next/standalone klasörünü VPS'e kopyalayıp doğrudan çalıştırabilirsin, tüm package.json bağımlılıklarını sunucuda npm install etmen gerekmez.

Standalone çalıştırmak için:

1PORT=3000 HOSTNAME=127.0.0.1 node server.js

Bu iki ortam değişkeninin işlevini doküman şöyle tarif eder: "If your project needs to listen to a specific port or hostname, you can define PORT or HOSTNAME environment variables before running server.js." Yani bunlar dinlenecek port ve adresi seçmek içindir. Server'ı bir reverse proxy'nin arkasına koyacaksan HOSTNAME'i 127.0.0.1 vermen, Node sürecinin yalnız yerel arayüzü dinlemesini ve doğrudan internete açılmamasını sağlar.

Standalone modun asıl kazancı, sunucuda npm install adımını tamamen ortadan kaldırmasıdır. Klasik bir deploy akışında build makinesi ile çalışma makinesi aynı node_modules ağacını paylaşmak zorundadır; standalone modda ise bu ağaç zaten build sırasında elenip yalnız gerçekten require edilen paketler taşınır. Bu da hem deploy paketinin boyutunu küçültür hem de sunucuda ayrı bir bağımlılık kurulum adımının başarısız olma riskini (ağ, kayıt sunucusu, sürüm uyuşmazlığı gibi) devre dışı bırakır — sunucuda tek gereken çalışan bir Node.js runtime'ıdır, bir paket yöneticisi değil.

Dosya yerleşimi ve public/.next/static senkronu (klasik 404 tuzağı)

Standalone çıktısıyla ilgili en sık düşülen tuzak burada: minimal server.js, public/ klasörünü ve .next/static/ klasörünü otomatik kopyalamaz. Next.js dokümanı bunu açıkça belirtir — bu iki klasörü CDN üzerinden servis etmek istersen elle kopyalamalısın, istemezsen de deploy script'ine dahil etmen gerekir.

Sonuç: build başarılı olur, node server.js sorunsuz açılır, ana sayfa bile render olur — ama tüm /_next/static/* istekleri ve public/ altındaki favicon, resim, font dosyaları 404 döner. Bu genellikle "build çalıştı ama site bozuk görünüyor" şikayetinin kök nedenidir.

Doğru dizin yerleşimi şöyle görünmelidir:

1# next build sonrası, standalone klasörünü tamamlamak için:
2cp -r public .next/standalone/ && cp -r .next/static .next/standalone/.next/

Dokümanın verdiği bu formu build script'ine eklemeden .next/standalone klasörünü olduğu gibi taşımak, üretimde en yaygın 404 nedenidir.

Non-root systemd unit + hardening

Standalone server.js'i root kullanıcısıyla çalıştırmak gereksiz bir risktir — süreç ele geçirilirse saldırgan doğrudan root yetkisi kazanır. Genel ilke olarak, uygulamayı sistemde ayrı, giriş yapamayan (nologin) bir servis kullanıcısıyla çalıştırıp systemd unit dosyasında birkaç sertleştirme (hardening) direktifi eklemek yaygın bir üretim pratiğidir.

1[Unit]
2Description=Next.js standalone app
3After=network.target
4 
5[Service]
6Type=simple
7User=webapp
8Group=webapp
9WorkingDirectory=/opt/myapp/current
10Environment=PORT=3000
11Environment=HOSTNAME=127.0.0.1
12ExecStart=/usr/bin/node server.js
13Restart=on-failure
14RestartSec=5
15NoNewPrivileges=true
16ProtectSystem=full
17ProtectHome=true
18PrivateTmp=true
19 
20[Install]
21WantedBy=multi-user.target

Bu direktifler sistemin genel systemd yeteneğidir, Next.js'e özgü değildir; her VPS dağıtımında (Ubuntu, Debian, vb.) aynı şekilde çalışır. Kendi ortamına göre WorkingDirectory ve port değerini değiştirmen yeterli.

Servis kullanıcısını oluşturmak da tek satırlık bir iştir:

1useradd --system --no-create-home --shell /usr/sbin/nologin webapp
2chown -R webapp:webapp /opt/myapp

--no-create-home ve --shell /usr/sbin/nologin bayrakları, bu kullanıcının interaktif olarak sunucuya giriş yapamayacağını, yalnızca systemd tarafından süreç başlatmak için kullanılabileceğini garanti eder. ProtectSystem=full ve ProtectHome=true gibi direktifleri ProtectSystem=strict gibi daha agresif ayarlara çekmeden önce dikkatli ol: bazı Node.js sürümleri V8 JIT için yazılabilir+çalıştırılabilir bellek sayfalarına ihtiyaç duyar, aşırı kısıtlayıcı bir MemoryDenyWriteExecute=true ayarı çalışma zamanında beklenmedik çökmelere yol açabilir — bu direktifi eklemeden önce üretim dışı bir ortamda test etmen önerilir.

nginx reverse proxy, brotli ve immutable asset header'ları

Next.js'in kendi self-hosting rehberi, Node sürecini doğrudan internete açmak yerine önüne bir reverse proxy (nginx gibi) koymayı önerir.

1server {
2    listen 80;
3    server_name _;
4 
5    location /_next/static/ {
6        alias /opt/myapp/current/.next/static/;
7        add_header Cache-Control "public, max-age=31536000, immutable";
8    }
9 
10    location / {
11        proxy_pass http://127.0.0.1:3000;
12        proxy_http_version 1.1;
13        proxy_set_header Upgrade $http_upgrade;
14        proxy_set_header Connection "upgrade";
15        proxy_set_header Host $host;
16        proxy_set_header X-Real-IP $remote_addr;
17        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
18        proxy_set_header X-Forwarded-Proto $scheme;
19        proxy_buffering off;
20    }
21}

_next/static/ altındaki dosyalar içerik hash'i taşıdığı için değişmez (immutable) kabul edilebilir; rehbere göre Next.js, gerçekten değişmez (truly immutable) asset'lere Cache-Control: public, max-age=31536000, immutable header'ını kendisi basar ve bu header override edilemez — nginx tarafında aynı header'ı vermek CDN/proxy katmanında tutarlılık sağlar.

Üç not daha:

• Streaming: aynı rehber, nginx ya da benzeri bir proxy kullanıyorsan streaming'in çalışması için buffering'i kapatman gerektiğini söyler; rehberin gösterdiği yol next.config.js içinden X-Accel-Buffering: no header'ı basmaktır. Yukarıdaki blokta aynı davranışı nginx tarafında proxy_buffering off; ile açıkça kapattım; X-Forwarded-For ve X-Forwarded-Proto ise uygulamanın istemcinin gerçek IP'sini ve şemasını görmesi için gerekir.

• Brotli: nginx çekirdeğinde brotli desteği yoktur — `ngx_brotli`, Google'ın sağladığı üçüncü parti bir modüldür (filter + static alt modülleri) ve nginx'i bu modülle yeniden derlemen gerekir.
• Precompressed gzip serve: nginx'in kendi ön-sıkıştırılmış dosya servis özelliği de core dışıdır; `ngx_http_gzip_static_module` için nginx'i --with-http_gzip_static_module bayrağıyla derlemen gerekir.

Her iki modül de nginx'in resmi paketinde varsayılan olarak gelmez; Ubuntu/Debian gibi dağıtımlarda ya kaynaktan derlemen ya da bu modülleri içeren bir üçüncü parti paket deposu (örneğin dağıtımın kendi nginx-extras benzeri paketi) kullanman gerekir. Her iki modülü de eklediğinde nginx, istemcinin Accept-Encoding header'ına göre önce brotli'yi, brotli desteklenmiyorsa gzip'i tercih edecek şekilde yapılandırılabilir — bu da eski tarayıcılarla yeni tarayıcılar arasında otomatik bir geri düşüş sağlar.

Build-lock ve sıfır-kesinti deploy

Standalone deploy'da en sık görülen kesinti nedeni, eski build hâlâ trafiği servis ederken yeni bir next build'in aynı dizinin üzerine yazmasıdır — çalışan process'in okuduğu dosyalar build sırasında değişir ve MODULE_NOT_FOUND benzeri hatalarla süreç çöker. Genel ilke olarak buna karşı üç adım işe yarar: eşzamanlı build'i engelleyen bir kilit dosyası, build'i ayrı bir "release" dizinine alıp bittiğinde bir symlink ile atomik olarak değiştirme, ve restart sonrası birkaç kez health-check deneyip başarısızsa symlink'i önceki release'e geri çevirip eski build'i servis etmeye devam etme.

1#!/usr/bin/env bash
2set -e
3 
4LOCK=/tmp/nextjs-build.lock
5exec 9>"$LOCK"
6flock -n 9 || { echo "Build zaten calisiyor, cikiliyor"; exit 1; }
7 
8RELEASE_DIR="/opt/myapp/releases/$(date +%s)"
9mkdir -p "$RELEASE_DIR"
10 
11npm run build
12cp -r .next/standalone/. "$RELEASE_DIR"/
13cp -r public "$RELEASE_DIR"/ && cp -r .next/static "$RELEASE_DIR"/.next/
14 
15PREV=$(readlink /opt/myapp/current || true)
16 
17ln -sfn "$RELEASE_DIR" /opt/myapp/current.tmp
18mv -T /opt/myapp/current.tmp /opt/myapp/current
19 
20systemctl restart myapp
21 
22for i in 1 2 3; do
23    sleep $((i * 3))
24    curl -sf http://127.0.0.1:3000/ && { echo STANDALONE_OK; exit 0; }
25done
26 
27if [ -n "$PREV" ]; then
28    echo "Health-check basarisiz, onceki release'e donuluyor"
29    ln -sfn "$PREV" /opt/myapp/current.tmp
30    mv -T /opt/myapp/current.tmp /opt/myapp/current
31    systemctl restart myapp
32else
33    echo "Onceki release yok, geri alinamiyor"
34fi
35exit 1

Bu, dağıtım aracından bağımsız genel bir deploy prensibidir: build başarısız veya health-check geçmezse yeni release'de ısrar etme, symlink'i bir önceki release'e geri çevir ve eski sürümün trafiği servis etmeye devam etmesine izin ver.

Release dizinlerini süresiz biriktirmemek için, deploy script'inin sonuna eski release'leri temizleyen bir adım eklemek de yaygın bir tercihtir — örneğin en güncel üç release'i sabit tutup daha eskilerini silmek, hem disk alanını korur hem de hızlı bir geri alma (rollback) imkânı bırakır. Geri alma o zaman tek bir komuta iner: symlink'i bir önceki release dizinine çevirip servisi yeniden başlatmak.

ISR / 'use cache' self-host'ta nasıl davranır

Self-host senaryosunda Incremental Static Regeneration, kalıcı yerel diski olan tek bir sunucu process'inde ekstra bir yapılandırma gerektirmeden otomatik olarak çalışır. Buna kendi pratik notumu ekleyeyim: birden fazla instance çalıştırdığın ya da önüne bir CDN/reverse proxy koyduğun kurulumda cache davranışını ayrıca planlaman gerekir.

Next.js 16 genel kullanıma açılırken (Ekim 2025 civarı) `"use cache"` direktifi ve Cache Components tanıtıldı, experimental.ppr bayrağı da kaldırıldı. Bu, hangi bileşenlerin/fonksiyonların cache'leneceğini kod içinde açıkça işaretlemeni sağlayan yeni bir model.

Tek sunucu senaryosunda bu diskteki cache sorunsuz çalışır. Ancak yatay ölçeklendirip birden fazla server.js process'i (farklı makinelerde veya aynı makinede birden fazla instance) çalıştırırsan, her instance kendi yerel disk cache'ine sahip olur — bu durumda cache tutarlılığı için paylaşımlı bir depolama katmanı (örneğin ağ üzerinden erişilen ortak bir dizin) düşünmen gerekir; bu senaryo tek-sunucu VPS kurulumunun kapsamı dışındadır.

Release-dizini deseniyle çalışırken dikkat etmen gereken bir ayrıntı da şudur: her deploy'da yeni bir release dizini açtığın için, önceki release'in diskteki ISR cache'i yeni release'e otomatik taşınmaz. Yeni release ilk isteklerde cache'i sıfırdan doldurur; bu genelde sorun yaratmaz ama çok sık deploy yapan bir kurulumda, cache'in her seferinde ısınmasını beklemek trafiği yoğun sayfalarda kısa süreli gecikmelere yol açabilir. Bu maliyeti azaltmak istersen, ISR cache dizinini release'ler arasında paylaşılan sabit bir yola (symlink'in dışında, ayrı bir dizine) yönlendirmeyi değerlendirebilirsin.

CDN (Cloudflare) önünde purge stratejisi

nginx'in önüne bir CDN (örneğin Cloudflare) koyduğunda, deploy sonrası değişen sayfaların edge cache'te bayatlamasını önlemen gerekir. Cloudflare'in kendi dokümanına göre tekil-URL purge (purge by single file/URL), tercih edilen (önerilen) yöntemdir — tüm zone'u toptan temizlemek yerine yalnızca değişen sayfaları hedeflemek edge cache'in geri kalanını korur.

Pratik ayrım şu şekilde kurulabilir:

• /_next/static/* altındaki dosyalar içerik-hash'li ve immutable olduğu için hiç purge gerektirmez — dosya adı değiştiği için eski sürüm zaten adresine erişilemez hâle gelir.
• HTML sayfaları (/, /blog/* gibi) her deploy'da değişebileceğinden, deploy script'inin son adımında değişen URL'lerin tekil purge çağrısını yapması gerekir.

Bu ayrımı otomatikleştirmenin pratik bir yolu, deploy script'inin hangi sayfaların içeriğinin gerçekten değiştiğini bilmesidir — örneğin bir blog yazısı güncellendiğinde yalnız o yazının URL'sini purge etmek, tüm siteyi toptan purge etmekten çok daha ucuzdur ve edge cache'in geri kalanının sıcak kalmasını sağlar. Toptan (zone-wide) purge, genellikle yalnızca yapılandırma değişikliği gibi nadir ve geniş kapsamlı durumlar için saklanmalıdır.

İzleme ve otomatik rollback

Deploy'un son halkası izlemedir: restart sonrası servisin gerçekten ayağa kalktığını doğrulamadan "deploy tamam" dememelisin. Genel ilke olarak, health-check endpoint'ine (basitçe ana sayfa da olabilir) birkaç kez, artan aralıklarla istek atıp yanıt alamazsan symlink'i önceki release'e geri çevirip servisi o sürümle yeniden başlatmak, restart döngüsüne (crash-loop) girmekten daha güvenlidir.

Bu üç davranışı birlikte düşün: (1) build-lock aynı anda iki build'i engeller, (2) release-dizini + symlink deploy'u atomik yapar, (3) health-retry + rollback, kötü bir build'in siteyi düşürmesini engeller. Üçü birlikte, tek makinelik bir VPS'te "sıfır kesinti" hedefine en yakın pratik kurulumdur.

Günlük izleme için systemd'in kendi log toplayıcısını kullanman yeterlidir; ayrı bir log-shipping aracı kurmadan önce genellikle journalctl -u <servis-adı> -n 200 --no-pager ile son satırları görebilir, journalctl -u <servis-adı> -f ile canlı takip yapabilirsin. Deploy script'inin başarısız health-check'i tespit ettiği anı de bu loglara ayrı bir satırla yazdırmak, hangi deploy'un hangi saatte geri alındığını sonradan araştırmayı kolaylaştırır.

SSS

Next.js standalone build kendi sunucumda nasıl çalıştırılır?

next.config.js içine output: 'standalone' ekleyip next build çalıştırdıktan sonra oluşan .next/standalone klasörünü VPS'e kopyala, public/ ve .next/static/ klasörlerini bu klasörün içine ekle, ardından PORT=3000 HOSTNAME=127.0.0.1 node server.js komutuyla başlat (reverse proxy arkasında yerel arayüzü dinlemesi yeterlidir). Bu minimal server.js, next start'ın yerini alır ve tüm proje node_modules'ına ihtiyaç duymaz.

Next.js için systemd servis dosyası nasıl yazılır?

/etc/systemd/system/ altına bir .service dosyası oluşturup ExecStart=/usr/bin/node server.js, WorkingDirectory olarak standalone klasörünün yolunu, User/Group olarak root dışında bir servis kullanıcısını tanımlarsın. NoNewPrivileges=true ve ProtectSystem=full gibi direktifler ekstra sertleştirme sağlar. systemctl enable --now <servis-adı> ile başlatıp önyükleme sırasında otomatik açılmasını sağlayabilirsin.

nginx arkasında Next.js'te static dosyalar neden 404 veriyor?

En yaygın neden, standalone server.js'in public/ ve .next/static/ klasörlerini otomatik kopyalamamasıdır — bu davranış Next.js dokümanında açıkça belirtilir. Bu klasörleri build script'inde standalone dizinine kopyalamazsan, sayfa HTML'i render olur ama CSS/JS/resim dosyaları 404 döner. İkinci yaygın neden, nginx'teki location /_next/static/ bloğunun alias yolunun yanlış dizini göstermesidir.

Self-host Next.js'te ISR ve cache nasıl çalışır?

Next.js'in self-hosting rehberine göre ISR, kalıcı yerel diski olan tek bir self-host next start instance'ında otomatik çalışır; rehber, birden fazla instance çalıştıran ya da önüne CDN/reverse proxy koyan kurulumlarda cache yapılandırmasını ayrıca gözden geçirmeni söyler. Bu yazıdaki tek sunucu kurulumunda otomatik davranış sorunsuz işler. Next.js 16 ile gelen "use cache" direktifi, hangi verinin/bileşenin cache'leneceğini kod içinde açıkça belirtmeni sağlar. Birden fazla process/instance çalıştırırsan, her birinin kendi yerel cache'i olacağından paylaşımlı bir depolama katmanı gerekebilir.

Standalone build ile normal `next build` arasındaki fark nedir?

Normal next build, next start ile çalıştırmak için sunucuda tüm node_modules'ı gerektirir. output: 'standalone' ise yalnızca gerekli dosyaları ve seçili bağımlılıkları tek bir taşınabilir klasöre toplar, minimal bir server.js üretir ve deploy paketinin boyutunu küçültür.

Neden Next.js server'ının önüne reverse proxy koymalıyım?

Next.js'in kendi self-hosting rehberi, Node sürecini doğrudan internete açmak yerine nginx gibi bir reverse proxy'nin arkasına koymayı önerir. Bu sayede TLS sonlandırma, sıkıştırma (gzip/brotli), statik dosya cache header'ları ve rate limiting gibi işleri Next.js process'inin dışında, ayrı bir katmanda yönetebilirsin.

Kaç release dizinini sunucuda tutmalıyım?

Sabit bir kural yok; genel pratik, en güncel iki veya üç release'i saklayıp daha eskilerini silmektir. Bu sayı disk alanına ve geri alma sıklığına göre değişir — daha sık deploy yapan bir ekip, sorunlu bir sürüme geri dönmek için genellikle son birkaç release'in yeterli olduğunu görür.

Güncelleme (Eylül 2026)

Bu rehberin gövdesi 2025-12-16 tarihindeki Next.js sürümüyle yazıldı. O tarihten bu yana birkaç değişiklik oldu:

• Next.js 16.3 GA (2026 yazı civarında) yayınlandı. Resmi blog yazısına göre, App Router artık SSR'de web stream yerine native Node.js stream kullanıyor; bu değişiklik kod tarafında herhangi bir değişiklik gerektirmeden, yük altında %22'ye varan oranda daha fazla istek karşılanabilmesini sağlıyor (ilgili PR).
• Immutable static asset'ler artık deploy'lar arası paylaşılabiliyor: dokümana göre (son güncelleme 2026-07-20), config.supportsImmutableAssets ile içerik-adresli /_next/static/immutable/* dosyalar deploy'lar arasında "skew" riski taşımadan yeniden kullanılabiliyor. Bu, yukarıdaki release-dizini + symlink desenini kullanan kurulumlar için ilgi çekici bir gelişme; ancak release-dizini yaklaşımıyla cache paylaşımının nasıl davranacağı bu yazı itibarıyla net değil, devreye almadan önce kendi ortamında test etmen gerekir.
• Turbopack dosya sistemi cache'i next build'te varsayılan olarak açık: aynı blog yazısına göre bazı projelerde tekrar build süresini 5,5 kata kadar hızlandırabiliyor.
• Node.js sürüm hattı: 2026-09-24 itibarıyla Node.js indirme sayfasına göre Node 26.x hattı "Current" olarak listeleniyor; LTS hattı ise Node 24.x. Standalone server'ı üretimde çalıştırırken Current hattına geçme, LTS hattında kalmaya devam et.

Sonuç

Standalone çıktısını doğru dizin yerleşimiyle, root olmayan bir systemd servisiyle, nginx reverse proxy'siyle ve build-lock'lu bir deploy script'iyle birleştirdiğinde, kendi VPS'inde Vercel'e yakın bir güvenilirlikte Next.js çalıştırabilirsin. Bu playbook'u mobil tarafındaki iOS CI/CD Pipeline: GitHub Actions ve Fastlane rehberiyle birlikte okumanı öneririm — orada anlatılan build-lock ve health-check felsefesi burada anlattığımız sunucu tarafı deploy deseniyle aynı köke dayanır. Daha geniş bir DevOps bakışı için Mobile DevOps Best Practices yazısına, backend tarafında hafif bir alternatif arıyorsan Hono.js: Serverless Web Framework Production Rehberi yazısına, API katmanını sağlamlaştırmak için Network Layer Optimization rehberine ve sunucu tarafında Swift kullanıyorsan Server-Side Swift Ekosistemi yazısına göz atabilirsin.

Kaynaklar

• Next.js `output` config referansı — standalone çıktısının ne kopyaladığını ve server.js'in nasıl çalıştığını anlatan resmi doküman.
• Next.js Self-Hosting rehberi — reverse proxy önerisi, cache davranışı ve immutable header tavsiyesinin güncel hâli.
• Next.js 16 duyuru yazısı — "use cache"/Cache Components ve experimental.ppr'ın kaldırılması.
• Cloudflare cache purge dokümanı — tekil-URL purge'ün önerilen yöntem olduğu resmi rehber.
• ngx_brotli (GitHub) — nginx için üçüncü parti brotli sıkıştırma modülü.
• nginx `gzip_static` modülü dokümanı — ön-sıkıştırılmış dosya servisi için core dışı modül.
• Next.js 16.3 duyuru yazısı — native Node.js stream, immutable asset paylaşımı ve Turbopack build cache güncellemeleri.