# Paylaşımlı Hosting'e Next.js Kurulur mu? Sınırlar ve VPS Kararı > Paylaşımlı hosting'de Next.js çalışabilir. Ama ikinci dağıtımda çarptığımız duvar aşılabilir değildi: EAGAIN, kilitlenen SSH, her dağıtımda silinen veritabanı. - Kanonik URL: https://algoritmaajans.com/tr/blog/paylasimli-hostinge-nextjs-kurulur-mu - Dil: tr - Kategori: Yazılım - Yayın: 2026-08-27 - Güncelleme: 2026-08-29 - Yayıncı: Algoritma Ajans --- **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. ![Tek bir duvar prizine takılmış üst üste çoklu prizler ve kablolar — paylaşımlı hosting'de tek makinenin süreç sınırını zorlamanın görsel karşılığı](/images/blog/paylasimli-hosting-inline-1.jpg) Denediklerimiz: ```bash 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: ```bash 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](/tr/blog/cdn-onbellegi-nasil-temizlenir) 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. ```bash 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. ```json { "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](/tr/blog/yeni-sunucu-nasil-guvenli-hale-getirilir) 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](/tr/blog/web-sitesi-fiyatlari-neye-gore-degisir) 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](/tr/blog/cloudflare-dns-gecisi-nasil-yapilir) 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](/tr/blog/e-ticaret-sitesi-nasil-kurulur) bu adımın neden atlanmaması gerektiğini ayrıca yazdık.