Node.js 22, 24, 26: Hangi LTS'e Ne Zaman Geçmeli?

Node.js dünyasında Eylül 2026 itibarıyla üç aktif hat var: 22, 24 ve 26. Hangisine ne zaman geçmen gerektiği sorusu artık sadece "en yeni sürüm en iyisidir" mantığıyla cevaplanamıyor, çünkü her hattın kendi risk profili ve takvimi var. Bu rehber, resmi Node.js sürüm takvimini ve gerçek kırıcı değişiklikleri temel alarak sana somut bir geçiş kararı verir.

💡 Pro Tip: Karar vermeden önce node -v ile hangi hatta olduğunu ve npm ls --depth=0 ile native bağımlılıklarını (bcrypt, sharp, sqlite3 gibi derlenmiş modülleri) kontrol et — asıl risk sürüm numarasında değil, bu modüllerin ABI uyumluluğunda.

İçindekiler

• Eylül 2026 itibarıyla sürüm tablosu
• Active LTS / Maintenance / Current farkı ve risk profili
• Ekim 2026 kırılma noktası: Node 26 LTS'e geçince ne olur
• Yükseltmede gerçekten kıran şeyler (N-API, native rebuild, OpenSSL)
• OpenSSL 3.5 ve security level 2
• V8 13.6 ve native eklentiler
• Derleyici ve platform gereksinimleri
• Node 26'da (Current) zaten girmiş kırılmalar
• Next.js/Prisma/Sentry'nin desteklediği minimum sürümler
• Sıfır-kesinti yükseltme prosedürü ve rollback
• CI matrisini nasıl kurmalı
• 2027 ufku: Node.js'in yıllık tek-LTS modeline geçişi
• SSS
• Node.js 22'den 24'e mi geçmeliyim, 26'yı mı beklemeliyim?
• Node 22 ne zaman EOL oluyor?
• Node 26 ne zaman LTS olacak?
• Node sürüm yükseltmesinde native modüller neden kırılır?
• Node 24'ten Node 26'ya doğrudan atlamak mantıklı mı?
• Node 22'de Prisma 8'i kullanabilir miyim?
• Sonuç
• Kaynaklar

Eylül 2026 itibarıyla sürüm tablosu

Node.js projesi üç sürümü aynı anda destekliyor, her biri farklı bir fazda:

Kaynak: nodejs/Release resmi takvim.

Yazım günü (2026-09-23) itibarıyla her hattın en güncel yayını şöyle: 26.x serisinde en güncel patch v26.10.0 (21 Eylül 2026; npm 11.19.1, V8 14.6.202.34, OpenSSL 3.5.8, ABI modül sürümü 147). 24.x serisinde en güncel patch yaklaşık 24.21.x (Eylül 2026 başı), 22.x serisinde yaklaşık 22.23.x (Temmuz 2026 sonu) civarında — bu iki hattın tam patch numarasını yükseltmeden hemen önce nvm ls-remote --lts ile teyit etmeni öneririm, çünkü patch sürümleri her birkaç haftada bir çıkıyor.

Active LTS / Maintenance / Current farkı ve risk profili

Üç faz farklı garanti seviyesi sunar:

• Current: Ana geliştirme dalından gelen, henüz LTS onayından geçmemiş değişiklikleri içerir; major API kırılmaları burada serbestçe girer.
• Active LTS: Release ekibinin "uygun ve kararlı" bulduğu yeni özellikler, hata düzeltmeleri ve güncellemeler kabul edilir — production için önerilen faz.
• Maintenance LTS: Yalnız kritik hata düzeltmeleri ve güvenlik güncellemeleri; yeni özellik eklenmesi Release ekibinin takdirine bağlı ve nadir.

Pratik risk sıralaması: Current > Active LTS > Maintenance LTS. Node 22 şu an Maintenance'ta — yeni özellik beklemiyorsan güvenli ama "geleceğe yatırım" değil. Node 24 Active LTS'te — çoğu ekip için doğru varsayılan. Node 26 henüz Current'ta — deneme/test ortamı için uygun, production için 28 Ekim 2026'yı bekle.

Ekim 2026 kırılma noktası: Node 26 LTS'e geçince ne olur

28 Ekim 2026 tek bir tarih değil, sekiz gün arayla iki olay: aynı takvimde Node 24, Active LTS'ten Maintenance LTS'e inerken (20 Ekim 2026), sekiz gün sonra Node 26 Active LTS'e çıkıyor. Yani Ekim 2026'nın üçüncü haftası, "yeni proje başlatıyorsan hangi hattı seçmelisin" sorusunun cevabının değiştiği andır.

Önemli bir ayrım: Node 26 zaten Current fazında olduğu için, 2026-09-23 itibarıyla 26.x'i kullanan ekipler SEMVER-MAJOR kırılmaları şimdiden görüyor. 28 Ekim 2026'da LTS etiketinin gelmesi bu kırılmaları geri almıyor — sadece "artık kararlı, production'a alabilirsin" güvencesini ekliyor. Aşağıdaki bölümdeki kırıcı değişiklikler bu yüzden hem "26'ya şimdiden geçenler" hem de "LTS'i bekleyenler" için geçerli, sadece zamanlama farklı.

Bir bağlam notu: Node.js projesi 10 Mart 2026'da yayınladığı planla, önümüzdeki dönemde yıllık tek major sürüm + her sürümün LTS olacağı bir modele geçmeyi duyurdu; bu değişim çift/tek numara ayrımını kaldıracak ve 6 aylık bir Alpha kanalı getirecek. Node 27'nin bu yeni kadanstaki takvimi duyuruda zaten mutlak tarihlerle verildi: Alpha Ekim 2026, 27.0.0 Nisan 2027 — 22/24/26 kararını verirken bunu bir arka plan bilgisi olarak tut, doğrudan bir aksiyon gerektirmiyor.

Yükseltmede gerçekten kıran şeyler (N-API, native rebuild, OpenSSL)

Sürüm numarası artışından çok daha kritik olan dört kategori var:

OpenSSL 3.5 ve security level 2

Node 24, öntanımlı olarak OpenSSL 3.5'e geçti ve security level 2 varsayılan hale geldi: 2048 bitten kısa RSA/DSA/DH anahtarları, 224 bitten kısa ECC anahtarları ve RC4 tabanlı cipher suite'ler artık reddediliyor. Eski bir sertifika veya legacy bir TLS entegrasyonun varsa, yükseltmeden önce anahtar uzunluklarını kontrol et.

V8 13.6 ve native eklentiler

V8 motorunun 13.6'ya geçmesiyle, doğrudan V8 API'lerine bağlı derlenmiş (native) eklentiler güncellenmeden çalışmayabilir; bazı durumlarda C++17 yeterliyken artık C++20 desteği gerekebiliyor. Mümkün olduğunda V8'e değil NODE-API'ye bağlı paketleri tercih etmek, gelecekteki rebuild zorunluluklarını azaltır.

Derleyici ve platform gereksinimleri

Node 24'ten itibaren Windows'ta derleme için MSVC desteği kaldırıldı, ClangCL zorunlu hale geldi; kaynaktan derlemede AIX/Linux'ta minimum gcc 12.2, macOS'ta minimum Xcode 16.1 gerekiyor. Önceden derlenmiş macOS ikilikleri artık minimum macOS 13.5 istiyor; 32-bit Windows (23.0.0'dan itibaren) ve armv7 üzerinde 32-bit Linux (24.0.0'dan itibaren) için önceden derlenmiş ikilik artık sağlanmıyor.

Node 26'da (Current) zaten girmiş kırılmalar

ServerResponse.prototype.writeHeader() (DEP0063) tamamen kaldırıldı — writeHead() kullanmalısın. Legacy _stream_wrap, _stream_readable, _stream_writable, _stream_duplex, _stream_transform ve _stream_passthrough modülleri tamamen kaldırıldı (DEP0193 artık sadece çalışma-zamanı uyarısı değil, End-of-Life). Buna karşılık Node 26'da Temporal API varsayılan olarak etkin ve Undici 8.0.2'ye yükseltildi — yeni tarih/saat kodun için avantaj.

Bu iki kırılma pratikte şöyle karşına çıkar: eski bir HTTP sunucu kodunda hâlâ res.writeHeader(200, {...}) çağrısı varsa, çağrı artık tanımsız bir fonksiyona gider ve Node 26'da bir TypeError fırlatır, sessizce görmezden gelinmez. Benzer şekilde, core'un node:_stream_* modüllerinden birini require eden bir bağımlılığın varsa, o bağımlılık Node 26'da aradığı modülü bulamaz. Yükseltme öncesi kod tabanında hızlı bir tarama işe yarar:

1# writeHeader ve legacy _stream_* kullanımlarını tara
2grep -rn "writeHeader(" src/ --include="*.ts" --include="*.js"
3grep -rn "node:_stream_\|require('_stream_" node_modules --include="*.js" --include="*.cjs" -l

TLS/OpenSSL tarafında ise, security level 2'ye geçişin gerçekten seni etkileyip etkilemediğini stage ortamında openssl ile hızlıca doğrulayabilirsin — eski bir sertifikanın anahtar uzunluğunu kontrol etmek, production'da sürpriz bir "handshake failure" almaktan çok daha ucuzdur:

1# Sertifika anahtar uzunluğunu kontrol et (2048 bit altı Node 24+'ta reddedilir)
2openssl x509 -in cert.pem -noout -text | grep "Public-Key"

Native modüllerin neden kırıldığını anlamak için: her Node major sürümü, V8/N-API ABI'sini (NODE_MODULE_VERSION) değiştirebilir. .node uzantılı derlenmiş eklentiler eski ABI'ye göre paketlenmişse, yeni sürümde struct offset/symbol uyuşmazlığı yüzünden segfault verir ya da Node'un kendi versiyon kontrolü tarafından reddedilir. Sabit N-API'ye bağlı paketler (V8 header'ına değil) bu sorundan büyük ölçüde muaftır. Yükseltme sonrası ilk adım:

1# Hangi native modüller derlenmiş, kontrol et
2npm ls --all 2>&1 | grep -i "gyp\|native"
3 
4# ABI uyumsuzluğunda önce temiz rebuild dene
5rm -rf node_modules package-lock.json
6npm install
7npm rebuild
8 
9# Belirli bir paketi hedefli rebuild etmek için
10npm rebuild bcrypt --build-from-source

Rebuild sonrası hâlâ hata alıyorsan, paketin kendi GitHub sayfasında "Node 24/26 desteği" ile ilgili açık bir issue olup olmadığına bak; prebuilt binary'nin yeni hat için yayınlanıp yayınlanmadığını en güvenilir şekilde orada görürsün.

Next.js/Prisma/Sentry'nin desteklediği minimum sürümler

Stack'inin geri kalanı seni geride tutuyor olabilir mi? Yazım günü (2026-09-23) itibarıyla npm registry'deki güncel yayınların engines.node alanları şöyle:

Buradaki tek gerçek risk Prisma: eğer projen hâlâ Node 22'nin erken bir minor'ında (22.18'den önce) donmuşsa, Prisma 8'e geçiş öncesi en azından güncel 22.x patch'ine (22.23.x civarı) çekilmen gerekir. Next.js ve Sentry tarafında minimum sürüm şartı zaten üç LTS hattının da altında kaldığı için darboğaz oluşturmuyorlar. Kendi projende kesin rakamı teyit etmek için:

1npm view next engines.node
2npm view prisma engines.node
3npm view @sentry/nextjs engines.node

Kendi package.json dosyanda da bir engines alanı tanımlamak, hangi Node hattını hedeflediğini ekip içinde ve CI konfigürasyonunda açıkça belgelemenin en ucuz yolu — özellikle birden fazla geliştiricinin farklı yerel Node sürümleri kullandığı ekiplerde faydalı bir referans noktası:

1{
2  "engines": {
3    "node": ">=22.18.0"
4  }
5}

Bu alanı .nvmrc dosyandaki sürümle elle senkron tutmak, "lokalde çalışıyor ama CI'da patlıyor" tipi sürüm uyuşmazlıklarını erken görmeni sağlar.

Sıfır-kesinti yükseltme prosedürü ve rollback

Node major sürüm yükseltmesi, TLS/OpenSSL davranış değişikliği ve native ABI riski taşıdığı için doğrudan production'da denenmemeli. Önerilen sıra:

1. Yerel + CI'da hedef sürümü kur — nvm install 24 && nvm use 24 (veya n 24), .nvmrc/.node-version dosyasını güncelle.
2. Native bağımlılıkları temiz rebuild et — bir önceki bölümdeki npm rebuild adımını CI pipeline'ına ekle, böylece ABI uyumsuzluğu merge öncesi yakalanır.
3. TLS/OpenSSL davranışını stage ortamında doğrula — özellikle eski sertifika veya legacy entegrasyon kullanan servislerde security level 2 kontrolünü stage'de test et.
4. Canary/mavi-yeşil dağıtım — yeni Node sürümünü trafiğin küçük bir yüzdesine (örneğin %5-10) yönlendir, hata oranı ve p95 gecikmeyi izle.
5. Rollback planı hazır tut — eski Node sürümüyle derlenmiş build artefaktını (native modüller dahil) en az bir dağıtım penceresi boyunca sakla; sorun çıkarsa trafiği eski sürüme geri al ve native modülleri o sürüme göre yeniden derle.

Kritik nokta: rollback sadece Node ikili dosyasını değiştirmek değildir — native modüller yeni ABI'ye göre yeniden derlendiyse, eski Node sürümüne dönerken bu modüllerin de eski ABI'ye geri derlenmesi gerekir. Bu yüzden node_modules'ı sürüm etiketiyle birlikte artefakt olarak saklamak, canlı bir rollback'te zaman kazandırır.

Bu prosedürü birden fazla servisi olan bir ekipte uygularken, servisleri tek seferde değil dalgalar halinde taşımak riski daha da azaltır: önce trafiği en düşük olan, en az kritik servisi yükselt, sorun çıkmazsa bir sonraki dalgaya geç. Her dalga arasında en az bir tam iş günü bekleyip hata oranı, bellek kullanımı ve p95/p99 gecikme metriklerini karşılaştırmak, bir önceki Node sürümüne göre performans regresyonu olup olmadığını görmeni sağlar. Bu adım özellikle OpenSSL 3.5'e geçişte önemli, çünkü security level 2'nin reddettiği zayıf anahtar/cipher suite kombinasyonları yalnızca gerçek trafikle karşılaşan bir bağlantıda ortaya çıkabilir — bunu canlıda değil, dalga bazlı kontrollü bir ortamda görmek istersin.

CI matrisini nasıl kurmalı

CI matrisini kurarken iki ilkeyi takip et: production'da çalışan Active LTS hattını mutlaka test et, ve bir sonraki Current hattını erken uyarı için matrise ekle — ama Current'ı asla deploy gate'i yapma. Maintenance'a inmiş ve EOL'e yaklaşan hatları matriste tutmak gürültü üretir, kaldırman gerekir.

1# .github/workflows/ci.yml (GitHub Actions ile actions/setup-node)
2strategy:
3  matrix:
4    node-version: ["24.x", "26.x"] # Active LTS + erken uyarı için Current
5    # '22.x' Maintenance'a düştü: yalnız eski bir dala destek veriyorsan tut
6    include:
7      - node-version: "26.x"
8        experimental: true # 26.x hâlâ Current: bloklamasın
9continue-on-error: ${{ matrix.experimental || false }}
10steps:
11  - uses: actions/checkout@v4
12  - uses: actions/setup-node@v4
13    with:
14      node-version: ${{ matrix.node-version }}
15      cache: "npm"
16  - run: npm ci
17  - run: npm rebuild
18  - run: npm test

26.x satırındaki bir kırılma sadece "bilgi amaçlı" olmalı (continue-on-error: true ile) — 28 Ekim 2026'dan önce bu satırı deploy'u bloklayan bir gate yapmak erken davranmak olur; o tarihten sonra Active LTS'e terfi ettiğinde matristeki rolünü "erken uyarı"dan "zorunlu"ya yükseltebilirsin.

2027 ufku: Node.js'in yıllık tek-LTS modeline geçişi

10 Mart 2026'da Node.js projesi, önümüzdeki dönemde çift/tek numara ayrımını kaldırıp yılda tek bir major sürüm çıkaracağı ve her sürümün doğrudan LTS'e gireceği bir modele geçiş planını duyurdu; bu değişikliğe altı aylık bir Alpha kanalı da eşlik edecek. Duyurudaki takvim Node 27 için mutlak: Alpha Ekim 2026'da başlıyor, 27.0.0 Nisan 2027'de çıkıyor, Ekim 2027'de LTS'e giriyor ve Nisan 2030'da EOL oluyor; faz süreleri Alpha 6 ay, Current 6 ay, LTS 30 ay olarak tanımlandı. Bu, bugünkü "çift sayı = LTS adayı" sezgisinin önümüzdeki yıllarda geçerliliğini yitireceği anlamına geliyor. 22/24/26 kararını verirken bu planı bir hatırlatma olarak tut: seçtiğin hat ne olursa olsun, sürüm numaralandırma mantığının birkaç yıl içinde değişeceğini bilerek ilerle.

SSS

Node.js 22'den 24'e mi geçmeliyim, 26'yı mı beklemeliyim?

Çoğu production servis için doğru varsayılan Node 24'tür, çünkü Active LTS fazında ve Release ekibinin "kararlı" onayından geçmiş durumda. Node 26 henüz Current fazında; 28 Ekim 2026'da Active LTS'e geçtikten sonra yeni projeler için değerlendirilebilir, ama kütüphane sahiplerinin test matrisine şimdiden eklemesinde fayda var.

Node 22 ne zaman EOL oluyor?

30 Nisan 2027'de. Şu an Maintenance LTS fazında (21 Ekim 2025'ten beri) ve yalnız kritik hata düzeltmeleri ile güvenlik güncellemeleri alıyor.

Node 26 ne zaman LTS olacak?

28 Ekim 2026'da Active LTS'e geçiyor. 2026-09-23 itibarıyla Current fazında ve en güncel patch'i v26.10.0.

Node sürüm yükseltmesinde native modüller neden kırılır?

Her major Node sürümü V8/N-API ABI'sini (NODE_MODULE_VERSION) değiştirebilir. Eski ABI'ye göre derlenmiş .node dosyaları yeni sürümde struct offset/symbol uyuşmazlığı yüzünden segfault verir ya da Node'un kendi versiyon kontrolü tarafından reddedilir; çözüm npm rebuild ile temiz yeniden derlemedir.

Node 24'ten Node 26'ya doğrudan atlamak mantıklı mı?

28 Ekim 2026'dan önce hayır — Node 26 henüz Current fazında ve production garantisi taşımıyor. O tarihten sonra, native bağımlılıklarını rebuild edip stage'de OpenSSL/security level testlerini geçtiysen doğrudan atlamak teknik olarak mümkün; tek ön koşul her iki ara sürümün (24 ve 26) kırıcı değişikliklerini birlikte değerlendirmen.

Node 22'de Prisma 8'i kullanabilir miyim?

Bağlı olduğun Node 22 patch'ine göre değişir. Prisma CLI'nin engines.node şartı >=22.18.0 — yani Node 22'nin 22.18'den önceki minor sürümlerinde Prisma 8 kurulumu başarısız olur, ama güncel Node 22 patch'leri (22.23.x civarı) bu şartı zaten karşılıyor. npm view prisma engines.node ile kendi hedef sürümünde teyit et, çünkü Prisma 8 yazım günü itibarıyla hâlâ release candidate (rc) etiketiyle dağıtılıyor ve şart değişebilir.

Sonuç

Node.js 22/24/26 kararı özünde bir risk yönetimi sorusu: Node 22 güvenli ama gelecek yatırımı değil, Node 24 çoğu ekip için doğru production varsayılanı, Node 26 ise 28 Ekim 2026'ya kadar test/deneme ortamında kalmalı. Gerçek risk sürüm numarasında değil, OpenSSL security level değişikliğinde ve native bağımlılıklarının ABI uyumluluğunda — bu yüzden yükseltme sırasını native bağımlılık yoğunluğuna göre planlamak, sürüm numarasına göre planlamaktan daha güvenli.

Node.js ekosistemindeki diğer runtime ve araç geçişlerini de aynı disiplinle ele almak istersen, Next.js 16.3'te runtime='edge' kaldırılıp Node'a dönüşü, Prisma 6'dan 7'ye geçişte Rust motorunun kaldırılmasını, TypeScript 7'nin Go derleyicisine geçiş kararını, Next.js 16.3 Instant Navigations ve Cache Components rehberini ve Hono.js ile serverless production kurulumunu incelemeni öneririm — hepsi aynı Eylül-Ekim 2026 penceresinde stack'ini etkileyen kararlar.

Kaynaklar

• nodejs/Release resmi sürüm takvimi — Node 22/24/26 için Active LTS, Maintenance ve EOL tarihlerinin birincil kaynağı.
• endoflife.date/nodejs — LTS geçiş tarihlerini ve güncel patch numaralarını teyit eden ikincil derleme.
• Node.js v22'den v24'e geçiş rehberi (resmi) — OpenSSL 3.5, V8 13.6 ve derleyici gereksinimlerindeki kırıcı değişiklikler.
• Node.js v24.0.0 sürüm notları (resmi) — Windows'ta MSVC desteğinin kaldırılıp ClangCL'in zorunlu hale gelmesi.
• Node.js v26.0.0 sürüm notları (resmi) — writeHeader() kaldırılması, legacy stream modülleri, Temporal API ve V8 sürümü.
• Node.js deprecations dokümanı (resmi) — DEP0063 ve DEP0193 kayıtlarının End-of-Life sürümleri.
• nodejs.org/dist/index.json — güncel Node 26.x patch numarası ve ABI modül sürümü.
• Node.js sürüm takviminin evrimi (resmi duyuru) — yıllık tek-major LTS modeline geçiş planı.
• npm registry: next@latest, prisma@latest, @sentry/nextjs@latest — engines.node minimum sürüm şartları.