Paylaşımlı Hosting'e Next.js Kurulur mu? Sınırlar ve VPS Kararı

Paylaşımlı hosting'e Next.js kurulabilir — sağlayıcının "Node.js uygulaması" bölümü varsa çalışır. Ama üç sert sınıra çarparsınız: derlemeyi sunucuda kendiniz yapamazsınız, veritabanınız her dağıtımda silinir ve CDN dağıtımınızdan haberdar olmaz. Veritabanına yazan ve sık güncellenen bir proje için VPS gerekir.

Bir Next.js projesini paylaşımlı hosting'e kurduk. Site açıldı, sayfalar çalıştı, her şey yolunda göründü. Sonra ikinci dağıtımda duvara çarptık — ve o duvar aşılabilir değildi.

Bu yazı, aynı yolu denemeden önce bilmeniz gerekenleri anlatıyor. Teori değil: hangi hataları aldığımızı, ne denediğimizi ve neyin işe yaramadığını yazıyorum.

Önce iyi haber

Paylaşımlı hosting'de Next.js çalışabilir. Hostinger, Namecheap gibi sağlayıcılar artık "Node.js uygulaması" ya da "Web Apps" adında bir bölüm sunuyor. Uygulamanızı yüklüyorsunuz, onlar npm install ve npm run build çalıştırıp Passenger altında ayağa kaldırıyor.

Statik ağırlıklı, seyrek güncellenen bir site için bu gerçekten yeterli olabilir.

Şu tabloya bakıp hangi tarafta olduğunuzu baştan görebilirsiniz:

İhtiyaç	Paylaşımlı hosting	VPS
Statik / SSG sayfalar	Çalışır	Çalışır
Sunucu tarafı render (SSR)	Genelde çalışır	Çalışır
Sunucuda derleme (SSH ile)	Çalışmaz	Çalışır
Veritabanına yazma (SQLite)	Dağıtımda silinir	Sorun yok
Harici veritabanı (MySQL/Postgres)	Çalışır	Çalışır
Cron / arka plan işi	Kısıtlı	Çalışır
WebSocket / uzun bağlantı	Genelde kapalı	Çalışır
Önbellek başlığı kontrolü	Sağlayıcının CDN'i ezer	Sizde
Log erişimi	Kısıtlı	Tam
Aylık maliyet	~2-5 €	~5-7 €

Son satır dikkat çekici: fiyat farkı düşündüğünüz kadar büyük değil. Karar maliyetten çok kontrol meselesi.

Kötü haber: derlemeyi siz yapamazsınız

İlk dağıtım panel üzerinden sorunsuz geçti. Sonra SSH ile bağlanıp sunucuda derleme yapmak istedik. Aldığımız hata:

> Build error occurred
Error: EAGAIN
    at ignore-listed frames {
  code: 'ERR_WORKER_INIT_FAILED'
}

EAGAIN + ERR_WORKER_INIT_FAILED, Node'un worker_threads katmanının yeni iş parçacığı açamadığı anlamına gelir. Next 16 Turbopack ile derliyor ve derleme sırasında çekirdek sayısı kadar worker açmaya çalışıyor.

Sunucu 64 çekirdek raporluyordu. Next de 63 worker açmaya kalkıştı. Paylaşımlı hosting'de kullanıcı başına süreç sınırı bunun çok altındadır.

Sorunun kökeni şu: paylaşımlı hosting'de sunucu donanımını yüzlerce hesap paylaşır. Sizin gördüğünüz nproc çıktısı makinenin çekirdek sayısıdır, size ayrılan pay değil. CloudLinux gibi katmanlar hesap başına bellek, CPU ve süreç sayısı sınırı koyar; Node bu sınırı okuyamaz ve makinenin tamamına sahipmiş gibi davranır.

Denediklerimiz:

export TOKIO_WORKER_THREADS=2      # Turbopack'in kendi havuzu
export CIRCLE_NODE_TOTAL=4         # Next'in worker sayısını ezer
export NEXT_TURBOPACK_USE_WORKER=0 # Turbopack'i aynı süreçte çalıştır

Üçü de yetmedi. Sonuncusu derlemeyi biraz ilerletti ama oturumu düşürdü.

Bellek tarafını da denedik:

export NODE_OPTIONS=--max-old-space-size=1024

Bu, Node'un yığın sınırını düşürür ve bellek kotasına takılmayı önleyebilir. Bizim sorunumuz bellek değil süreç sayısıydı, o yüzden işe yaramadı — ama sizinki bellek sınırıysa deneyin, hata mesajı JavaScript heap out of memory şeklinde gelir.

İşin ilginç yanı: sağlayıcının kendi derleme günlüğüne baktık, orada şu satır vardı:

Generating static pages using 63 workers (150/150) in 2.6s

Yani onların derleme hattı 63 worker'la sorunsuz çalışıyordu. Çünkü o derleme, sizin SSH oturumunuzun bulunduğu kısıtlı konteynerde değil, ayrı bir ortamda koşuyor.

Sonuç: derleme yalnızca panel üzerinden yapılabilir. Sunucuya bağlanıp elle derleyemezsiniz.

Bunun pratik bedeli şudur: her küçük düzeltme için tüm projeyi paketleyip panele yüklemeniz gerekir. Bir yazım hatasını düzeltmek beş dakikalık bir tur haline gelir. Günde bir dağıtım yapıyorsanız katlanılır; günde beş yapıyorsanız değil.

SSH kilitleniyor

Yarım kalan derleme süreçleri hesabın süreç kotasını doldurdu. Ardından SSH şu hatayı vermeye başladı:

exec request failed on channel 0

Bu, kimlik doğrulamanın geçtiği ama sunucunun komut için yeni süreç açamadığı anlamına gelir. Bağlanabiliyorsunuz, hiçbir şey çalıştıramıyorsunuz.

Süreçleri öldürmek isterdik — ama öldürmek için de süreç açmak gerekiyor. Kilit ancak yeni bir dağıtım başlatınca çözüldü.

Bu duruma düşerseniz sırayla deneyin: panelden uygulamayı yeniden başlatın, olmazsa panelden yeni bir dağıtım tetikleyin, olmazsa destek talebi açın. Kendi başınıza çözebileceğiniz bir aşama yok — ki bu da paylaşımlı hosting'in tanımı.

Veritabanı her dağıtımda siliniyor

SQLite kullanıyorsanız veritabanınız arşivin içinde bir dosyadır. Yeni bir sürüm yüklediğinizde sunucudaki dosya arşivdekiyle değişir.

Yani o güne kadar panelden girdiğiniz her yazı, her mesaj, her müşteri kaydı gider.

Çözümü var ama elle: her dağıtımdan önce canlı veritabanını indirin, yeni pakete koyun, sonra yükleyin. Bunu bir kez unutursanız veri kaybedersiniz.

Daha iyi bir yol, veritabanını dağıtım klasörünün dışına almaktır — ama paylaşımlı hosting'de "dışarısı" diye bir yer genelde yoktur; hesabınızın kök dizini zaten dağıtım hedefidir. Bazı sağlayıcılarda ~/veri gibi bir klasör dağıtımdan etkilenmez, ama bu garanti değil ve sağlayıcı değiştirdiğinde bozulur.

Sağlam alternatif: harici bir veritabanı kullanmak. MySQL ya da PostgreSQL, hosting hesabınızın dışında ayrı bir servis olarak durur ve dağıtımdan etkilenmez. Paylaşımlı hosting'de MySQL zaten genelde dahildir. SQLite'ın sadeliğinden vazgeçersiniz ama veri kaybı riskinden de kurtulursunuz.

Kendi sunucunuzda bu sorun hiç yoktur — veritabanı dağıtım klasörünün dışında durur ve dağıtım betiği ona dokunmaz.

CDN dağıtımı bilmiyor

Sağlayıcının CDN'i sizin dağıtımınızdan haberdar değildir. Next statik sayfalara s-maxage=31536000 (bir yıl) basar ve CDN bunu harfiyen uygular.

Bizde 108 sayfanın 50'si saatlerce eski kopyadan sunuldu. Bunun çözümü var — önbellek süresini kısaltmak — ama sorunun varlığını bilmiyorsanız fark etmezsiniz. Nasıl ölçtüğümüzü ve next.config.ts içinde ne yazdığımızı CDN önbelleği yazısında ayrıntılı anlattık.

Paylaşımlı hosting'e özgü ek sıkıntı şu: sağlayıcının CDN'ini kapatma ya da temizleme düğmesi ya yoktur ya da güvenilir çalışmaz. Yani sorunu kaynağında (uygulama başlıklarında) çözmek zorundasınız.

Dosya formatı reddi

Küçük ama zaman kaybettiren bir ayrıntı: yüklediğimiz .tar.gz dosyası "Desteklenmeyen dosya formatı" hatası verdi. Dosyayı denetledik — geçerli gzip, okunabilir tar, bütünlük tamam. Yükleyici çift uzantıyı ya da tarayıcının bildirdiği MIME tipini tanımıyordu.

.zip sorunsuz kabul edildi. Aynı içerik, farklı kap.

Bu tür ayrıntılar paylaşımlı hosting deneyiminin karakteristiği: sorun sizin projenizde değil, aracın kendisinde. Ve belgede yazmıyor.

Çalışmayan diğer şeyler

Yukarıdakiler bizim çarptıklarımız. Aynı ortamda sık sorun çıkaran birkaç konu daha var:

Cron ve arka plan işleri. Panel bir cron arayüzü sunabilir ama uzun süren işler süreç sınırına takılır. Zamanlanmış rapor, e-posta kuyruğu, veri senkronizasyonu gibi işler için uygun değil.

Dosya yükleme ve işleme. Kullanıcı görsel yüklüyorsa ve siz onu sunucuda küçültüyorsanız, sharp gibi kütüphaneler yerel derleme ister ve bazı ortamlarda kurulmaz. Kurulsa bile işlem yükü kotanızı yer.

WebSocket ve uzun bağlantılar. Canlı bildirim, sohbet, anlık güncelleme gerektiren özellikler genelde kapalıdır ya da bağlantı belirli sürede düşürülür.

Log erişimi. Bir hatayı teşhis etmek için uygulamanın çıktısına bakmanız gerekir. Panelin gösterdiği log genelde kısaltılmıştır ve journalctl gibi bir aracınız yoktur.

Node sürümü seçimi. Panel size birkaç sürüm sunar. İhtiyacınız olan sürüm listede yoksa yapabileceğiniz bir şey yok.

Yine de kuracaksanız: pratik ayarlar

Paylaşımlı hosting'de kalmaya karar verdiyseniz, işi kolaylaştıran birkaç ayar var.

Paketi küçük tutun. node_modules klasörünü arşive koymayın; sağlayıcı zaten npm install çalıştıracak. .next/cache de girmemeli — yüzlerce megabayt olabilir ve hiçbir işe yaramaz.

zip -r surum.zip .   -x "node_modules/*" ".next/cache/*" ".git/*" "*.db" ".env.local"

Sürüm dosyalarını dışarıda bırakın. Yukarıdaki komutta .env.local ve *.db bilinçli olarak hariç: biri sırlarınızı, diğeri canlı verinizi ezer.

Portu ortamdan okuyun. Passenger uygulamanıza bir port atar; siz sabit 3000 yazarsanız ayağa kalkmaz.

{ "scripts": { "start": "next start -p ${PORT:-3000}" } }

Node sürümünü sabitleyin. Panelde seçtiğiniz sürümle package.json içindeki engines alanı uyuşmalı; uyuşmadığında hata mesajı genelde alakasız bir yerden gelir.

Ortam değişkenlerini panelden girin. Dosyaya yazdığınız .env bir sonraki dağıtımda gider.

Statik ihracı düşünün. Sitenizde sunucu tarafı mantık yoksa output: "export" ile tamamen statik dosya üretebilirsiniz. O zaman Node çalıştırmaya bile gerek kalmaz, paylaşımlı hosting'in en güvenilir kullanım şekli budur. Karşılığında API route'lardan, sunucu bileşenlerinden ve dinamik render'dan vazgeçersiniz.

Belirtiden sebebe

Aldığımız ve çevremizde sık duyduğumuz hataların kısa bir eşlemesi:

Belirti	Muhtemel sebep	Ne yapmalı
EAGAIN / ERR_WORKER_INIT_FAILED	Süreç sayısı kotası	Sunucuda derlemeyin, panelden dağıtın
JavaScript heap out of memory	Bellek kotası	NODE_OPTIONS=--max-old-space-size düşürün
exec request failed on channel 0	Kota dolmuş, yeni süreç açılamıyor	Panelden yeniden başlatın
Site açılıyor ama sayfa eski	CDN önbelleği	Önbellek başlıklarını uygulamadan verin
Dağıtımdan sonra veriler yok	SQLite arşivle ezildi	Harici veritabanına geçin
"Desteklenmeyen dosya formatı"	Yükleyici .tar.gz tanımıyor	.zip kullanın
Uygulama ayağa kalkmıyor, log yok	Port sabit yazılmış	PORT ortam değişkenini okuyun

Bu tablonun ortak noktası şu: hataların hiçbiri kodunuzda değil. Hepsi ortamın koyduğu sınırlarla ilgili ve çoğu belgede yazmıyor. Paylaşımlı hosting'de geçirdiğiniz zamanın büyük kısmı, sınırın nerede olduğunu deneyerek öğrenmekle geçer.

Peki ne zaman VPS'e geçmeli

Paylaşımlı hosting yeterli olur:

• Site statik ağırlıklı, seyrek güncelleniyorsa
• Veritabanı yoksa ya da salt okunursa
• Dağıtım ayda bir yapılıyorsa
• Panelden çalışmak sizi rahatsız etmiyorsa
• Sunucu yönetmek istemiyorsanız ve bunun için bir bedel ödemeye razıysanız

VPS gerekir:

• Sık dağıtım yapıyorsanız
• Veritabanına yazılıyorsa (admin paneli, form kayıtları, üyelik)
• Derleme sürecini kontrol etmeniz gerekiyorsa
• Birden çok site aynı sunucuda duracaksa
• Cron, arka plan işleri, özel servisler kullanacaksanız
• Log'lara ve süreçlere doğrudan erişmeniz gerekiyorsa

Biz ikinci gruptaydık ve geçiş yaptık.

Üçüncü bir seçenek daha var ve dürüst olmak gerekirse çoğu proje için en pratiği: Vercel gibi Next.js'e özel bir platform. Derleme, önbellek temizliği, CDN ve dağıtım orada zaten çözülmüş durumda. Neden biz kullanmadık? Çünkü veritabanımız SQLite ve dosya sistemine yazan bir uygulama işletiyoruz; o mimari sunucusuz ortama uymuyor. Sizin projeniz uyuyorsa bu yazının tamamını atlayabilirsiniz.

Geçiş neye mal oldu

VPS: 4 vCPU, 8 GB RAM, aylık ~5-7 €. Kurulum yarım gün: işletim sistemi, Node, nginx, SSL, güvenlik duvarı, systemd servisi, dağıtım betiği.

Geçiş sonrası:

• Derleme sunucuda sorunsuz geçti — paylaşımlı hosting'de çöken adım
• SSH kilitlenmiyor
• Veritabanı dağıtım klasörünün dışında, dağıtımdan etkilenmiyor
• CDN yok, dolayısıyla önbellek sürprizi yok
• Dağıtım tek komut: rsync + bir betik

Ama görünmeyen bir maliyet de geldi: sunucu artık sizin sorumluluğunuzda. Güvenlik güncellemeleri, yedekler, sertifika yenilemesi, disk dolması — hepsi size ait. Bunların ilk gün nasıl kurulduğunu yeni sunucu güvenliği yazısında adım adım yazdık; ilk saatte 54 SSH deneme kaydı gelmişti.

Yanlış anlaşılmasın: paylaşımlı hosting kötü değil. Yanlış iş için kullanıldığında sorun çıkarıyor. Yukarıdaki listeye bakıp hangi tarafta olduğunuza karar verin — ortasında bir yerdeyseniz, sonradan taşımak baştan doğru kurmaktan pahalıdır.

Bu kararın bütçeye yansımasını web sitesi fiyatları yazısında ayrı bir kalem olarak ele aldık: barındırma seçimi projenin ilk maliyetini değil, iki yıllık toplam maliyetini belirliyor.

Karar vermeden önce sorulacak beş soru

Sağlayıcı seçerken satış sayfasında yazmayan şeyleri sormak gerekiyor. Destek kanalına yazın; cevap veremiyorlarsa bu da bir cevaptır.

1. Hesap başına süreç ve bellek sınırı nedir? Rakamı isteyin. "Sınırsız" diyorlarsa yanlış soruyu sormuşsunuzdur; her paylaşımlı ortamda bir sınır vardır.

2. SSH ile npm run build çalıştırabilir miyim? Cevap hayırsa dağıtım akışınızı buna göre kurun.

3. Dağıtım sırasında hangi klasörler korunuyor? Veritabanı ve yüklenen dosyalar için hayati soru.

4. CDN önbelleğini programatik olarak temizleyebiliyor muyum? API varsa dağıtım betiğinize ekleyebilirsiniz; yoksa önbellek süresini kendiniz kısaltmalısınız.

5. Uygulama loglarına nasıl erişiyorum? Panelde kısaltılmış bir kutu mu, yoksa dosyaya erişim mi?

Bu beş sorunun cevabını baştan bilseydik paylaşımlı hosting denemesine hiç girmezdik. Girmemiz kötü olmadı — bu yazı oradan çıktı — ama iki gün kaybettik.

Taşımayı düşünüyorsanız

Kesinti yaşamadan taşımanın yolu şu sırayla ilerlemek:

1. Yeni sunucuyu kurun, siteyi orada tam çalışır hale getirin
2. DNS'i değiştirmeden, IP üzerinden test edin
3. Veritabanını taşıyın ve içeriğini doğrulayın
4. DNS'i çevirin — eski sunucu yayılma bitene kadar ayakta kalsın
5. Yeni sunucuda her şeyi bir kez daha doğrulayın
6. Eski hesabı ancak birkaç gün sonra kapatın

Dördüncü adımda sorun çıkarsa DNS'i geri alırsınız, kimse fark etmez.

İkinci adımı nasıl yapacağınız sorulur: alan adı henüz eski sunucuyu gösterirken yeni sunucuyu test etmek için kendi makinenizin hosts dosyasına satır ekleyin.

# /etc/hosts
203.0.113.10   siteniz.com www.siteniz.com

Bu satır yalnızca sizin bilgisayarınızı etkiler; siz yeni sunucuyu görürsünüz, ziyaretçiler eskiyi. Test bitince satırı silin.

Dördüncü adımdan önce TTL'yi düşürmeyi unutmayın — geri dönüş süresi buna bağlı. DNS tarafındaki tuzakları ve nelerin sessizce kaybolduğunu Cloudflare geçişi yazısında anlattık.

Taşıma kontrol listesi

• Yeni sunucuda site tam çalışıyor, hosts dosyasıyla test edildi
• Veritabanı taşındı ve kayıt sayıları karşılaştırıldı
• Yüklenmiş dosyalar (görseller, ekler) taşındı
• Ortam değişkenleri yeni sunucuda tanımlı
• SSL sertifikası kuruldu ve curl -sI https:// 200 dönüyor
• DNS TTL'si düşürüldü
• DNS çevrildikten sonra tüm kayıtlar genel çözümleyiciyle doğrulandı
• Yönlendirmeler ve robots.txt yeni sunucuda doğru
• Eski hesap birkaç gün daha açık

Sipariş alan, ödeme akışı olan bir site taşıyorsanız listeye bir madde daha ekleyin: taşıma sonrası gerçek bir test siparişi geçin. E-ticaret sitesi kurulumunda bu adımın neden atlanmaması gerektiğini ayrıca yazdık.