Next.js Uygulaması VPS'e Nasıl Deploy Edilir? PM2, Nginx ve SSL

Next.js için VPS deploy nasıl yapılır?

Next.js uygulamasında VPS deploy işi için projeyi standalone çıktıyla derler, çıkan klasörü sunucuya aktarır, Node sürecini PM2 ile çalıştırır, önüne Nginx ters proxy koyar ve Let's Encrypt ile HTTPS'i açarsınız. Bu beş adım, tek sunuculu bir kurulumun iskeletidir.

Bu rehberi, kendi VPS'ini yöneten web sitesi sahipleri ve yazılımcılar için hazırladık. Komutları sırayla uygulayabilirsiniz. Ancak her adımın nedenini de anlatıyoruz, çünkü VPS deploy işinde sorunların çoğu yanlış varsayımdan çıkar.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu nedenle anlatım Next.js, PM2, Nginx ve Certbot'un resmi dokümanlarına dayanır. Emin olmadığımız komutu ya da sürüm numarasını yazmadık; gerektiğinde "güncel kararlı sürüm" diyoruz.

Örnek alan adı olarak example.com, örnek IP olarak da 203.0.113.10 kullanıyoruz. Bunları kendi değerlerinizle değiştirin. Parola, anahtar ve gerçek alan adlarınızı hiçbir zaman bir rehberden kopyaladığınız dosyaya ya da depoya yazmayın.

Next.js için VPS deploy mu, Vercel mi seçmelisiniz?

Doğru cevap ekibinize ve işinize bağlıdır. Vercel, Next.js'i geliştiren şirketin yönetilen platformudur ve sunucu bakımını sizden alır. VPS ise size tam kontrol verir, karşılığında güncelleme, güvenlik, yedek ve izleme sorumluluğunu da size bırakır.

Aşağıdaki tablo, kararı verirken bakmanız gereken ekseni özetler. Fiyat kıyası yapmadık, çünkü tarifeler sık değişir; güncel fiyatı her sağlayıcının kendi sayfasından kontrol edin.

Kısacası, sunucu işletmeye vakit ayıramıyorsanız yönetilen platform daha güvenlidir. Zaten bir VPS'iniz varsa ya da maliyeti sabit tutmak istiyorsanız VPS mantıklıdır. Barındırma seçeneklerini ayrıca hosting seçimi rehberimizde karşılaştırdık.

VPS deploy öncesinde hangi kararları vermelisiniz?

VPS deploy için komut yazmadan önce üç karar verin. Birincisi, uygulamanızın gerçekten bir Node sunucusuna ihtiyacı olup olmadığıdır. İkincisi, derlemeyi nerede yapacağınız. Üçüncüsü, tek sunucuyla mı yoksa birden fazla süreçle mi çalışacağınız.

Next.js dokümanı, statik dışa aktarım seçeneğini de anlatır. Sayfalarınızın hepsi derleme anında üretilebiliyorsa çıktıyı doğrudan Nginx ile sunabilirsiniz. Ancak sunucu tarafı işlev, istek anında render ya da varsayılan görsel optimizasyonu isterseniz Node sunucusu gerekir.

• Sayfalar tamamen statikse statik dışa aktarımı değerlendirin; Node süreci ve PM2 gerekmez.
• Sunucu bileşenleri, API rotaları ya da istek anında veri kullanıyorsanız Node sunucusu çalıştırın.
• Derlemeyi küçük VPS'te yapmak bellek zorlayabilir; derlemeyi başka bir makinede yapıp çıktıyı aktarmayı düşünün.
• Tek süreçle başlayın; birden fazla süreç ek önbellek ve anahtar ayarı ister.

Derlemeyi nerede yapacağınız da bir güvenlik kararıdır. Sunucuda derleme yaparsanız derleme araçları ve geliştirme bağımlılıkları üretim makinesine girer. Başka bir makinede derleyip yalnızca standalone klasörünü aktarırsanız sunucu daha yalın kalır. Bu nedenle bu rehberde ikinci yolu öneriyoruz.

Bu yazı, Node sunucusu çalıştıran en yaygın senaryoyu anlatır. Anlatım, Next.js'in resmi self-hosting dokümanındaki yaklaşımı izler.

VPS'i Next.js için nasıl hazırlarsınız?

İlk iş, root hesabıyla çalışmayı bırakmaktır. Yetkisiz bir kullanıcı oluşturun, uygulamayı onunla çalıştırın ve SSH girişini anahtarla yapın. Aşağıdaki komutlar Ubuntu gibi Debian tabanlı bir dağıtım varsayar; başka dağıtımda paket yöneticisi komutu farklıdır.

sudo apt update
sudo apt upgrade
sudo adduser deploy
sudo usermod -aG sudo deploy
sudo apt install nginx ufw

Ardından güvenlik duvarını açın. Dışarıya yalnızca SSH, HTTP ve HTTPS portlarını verin. Next.js süreci 3000 numaralı portta çalışacak, ama internetin bu porta ulaşmaması gerekir.

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable
sudo ufw status

Dikkat: güvenlik duvarını açmadan önce SSH kuralını eklediğinizden emin olun. Aksi halde kendi bağlantınızı kesersiniz. Genel güvenlik zafiyetlerini ise OWASP Top 10 web güvenlik açıkları yazısında anlattık.

Node.js'i sunucuya nasıl kurarsınız?

Node.js için tek bir doğru yöntem yoktur. Dağıtımın paket deposu, nvm gibi bir sürüm yöneticisi ya da resmi paket kaynakları kullanılabilir. Yöntemi, nodejs.org kurulum sayfasından seçin; çünkü sürüm ve depo adresleri zamanla değişir.

Sürüm seçerken iki şeye bakın. Next.js'in istediği asgari Node sürümü, kurulum sayfasında yazar. Ayrıca üretimde, güncel kararlı sürüm hattını (LTS) tercih edin. Böylece güvenlik yamalarını daha uzun süre alırsınız.

Kurulumdan sonra sürümü doğrulayın. Aynı sürümün geliştirme ortamınızda ve sunucuda kullanıldığından emin olun. Sürüm farkı, "bende çalışıyordu" türü hataların en sık nedenidir.

node --version
npm --version

Next.js standalone çıktıyı nasıl alırsınız?

Standalone çıktı, Next.js'in derleme sırasında hangi dosyaların gerektiğini izleyip yalnızca onları ayrı bir klasöre kopyalamasıdır. Resmi dokümana göre bu klasör .next/standalone altında oluşur ve node_modules kurmadan tek başına çalışır.

Etkinleştirmek için next.config.js dosyasına tek satır eklersiniz.

module.exports = {
  output: 'standalone',
}

Next.js, derlemeden sonra public ve .next/static klasörlerini kendiliğinden kopyalamaz. Doküman bunları elle kopyalamayı gösterir. Aksi halde sayfa gelir, ama görsel ve betik dosyaları 404 verir.

npm ci
npm run build
cp -r public .next/standalone/
cp -r .next/static .next/standalone/.next/

Monorepo kullanıyorsanız ek bir ayar gerekir: outputFileTracingRoot. Bu ayar, izlemenin hangi klasörden başlayacağını belirler. Böylece proje dışındaki ortak dosyalar da çıktıya girer.

Standalone sunucuyu elle nasıl başlatırsınız?

PM2'ye geçmeden önce sunucuyu elle başlatıp test edin. Böylece hata varsa süreç yöneticisini suçlamazsınız. Dokümana göre PORT ve HOSTNAME ortam değişkenleri, sunucunun hangi portu ve adresi dinleyeceğini belirler.

cd .next/standalone
PORT=3000 HOSTNAME=127.0.0.1 node server.js

Burada adres olarak 127.0.0.1 seçtik. Yani süreç yalnızca sunucunun kendi içinden erişilebilir olur. Dışarıya açılan kapı Nginx olacağı için bu, güvenlik açısından daha temiz bir tercihtir.

Ardından ikinci bir terminalde yanıtı kontrol edin. Başlık satırında 200 durum kodu görmelisiniz.

curl -I http://127.0.0.1:3000

Sorun yoksa süreci durdurun ve PM2'ye geçin. Sorun varsa önce günlük çıktısını okuyun; eksik ortam değişkeni ve yanlış Node sürümü en sık iki nedendir.

Ortam değişkenlerini nasıl yönetirsiniz?

Next.js hem derleme anı hem çalışma anı ortam değişkenlerini destekler. Varsayılan olarak değişkenleri yalnızca sunucu görür. Tarayıcıya açmak için adın NEXT_PUBLIC_ ile başlaması gerekir. Next.js bu değerleri next build sırasında JavaScript paketine gömer.

Bunun pratik sonucu şudur: bir NEXT_PUBLIC_ değerini sunucuda değiştirip süreci yeniden başlatmak yetmez. Yeniden derlemeniz gerekir. Gizli anahtarlar ise asla bu önekle başlamamalı, çünkü herkes tarayıcıdan okuyabilir.

• Gizli değerleri depoya koymayın; sunucuda, yalnızca uygulama kullanıcısının okuyabildiği dosyada tutun.
• Tarayıcıya gidecek değerler için NEXT_PUBLIC_ önekini yalnızca gerçekten gerektiğinde kullanın.
• Yeni bir değişkeni değiştirdikten sonra süreci yeniden başlatın ve değerin geldiğini test edin.
• Gerçek parola ve anahtarları örnek dosyalara, ekran görüntülerine ya da sohbet mesajlarına yapıştırmayın.

Dokümana göre sunucu, dinamik render sırasında okuduğu değerleri çalışma anında değerlendirir. Bu sayede tek bir çıktıyı farklı ortamlarda farklı değerlerle çalıştırabilirsiniz.

PM2 ile Next.js uygulamasını nasıl çalıştırırsınız?

PM2, Node süreçlerini arka planda çalıştıran, çökerse yeniden başlatan ve günlükleri toplayan bir süreç yöneticisidir. Resmi dokümandaki ecosystem dosyası, tüm ayarları tek yerde toplar. Böylece her seferinde uzun bir komut yazmazsınız.

module.exports = {
  apps: [{
    name: 'site',
    script: 'server.js',
    cwd: '/var/www/example.com/current/.next/standalone',
    max_memory_restart: '500M',
    env_production: {
      NODE_ENV: 'production',
      PORT: 3000,
      HOSTNAME: '127.0.0.1'
    }
  }]
}

Buradaki max_memory_restart değeri örnektir; kendi uygulamanızın bellek kullanımını ölçüp ona göre belirleyin. Dokümana göre bu ayar, süreç belirlenen belleği aşınca yeniden başlatmayı sağlar.

pm2 start ecosystem.config.js --env production
pm2 status
pm2 logs site

PM2'yi daha ayrıntılı anlatan kardeş yazımız yayınlandığında oradan da bakabilirsiniz. Burada yalnızca Next.js için gereken kısmı aldık.

Sunucu yeniden başlayınca uygulamayı nasıl ayağa kaldırırsınız?

PM2 kendiliğinden açılış sırasında başlamaz. Bunun için startup betiği üretmeniz ve süreç listesini kaydetmeniz gerekir. PM2 dokümanı önce pm2 startup komutunu, ardından ekranda çıkan sudo komutunu çalıştırmanızı söyler.

pm2 startup
pm2 save

İlk komut, sisteminizin açılış yöneticisini (çoğu modern dağıtımda systemd) algılar ve size kopyalayıp çalıştıracağınız bir komut verir. Bu komutu aynen çalıştırın; kullanıcı adı ve Node yolu zaten içinde yazar.

İkinci komut, o anda çalışan uygulamaların listesini kaydeder. Bu listeyi uygulama ekledikten ya da kaldırdıktan sonra tekrar kaydetmeniz gerekir. Son olarak, güvenle denemek için sunucuyu bir kez yeniden başlatın ve uygulamanın kendiliğinden döndüğünü görün.

PM2 yerine systemd kullanabilir misiniz?

Evet, kullanabilirsiniz. Modern Linux dağıtımlarında systemd zaten süreç yöneticisidir. Dolayısıyla Node sürecini doğrudan bir birim dosyasıyla çalıştırmak, ek bir araç kurmadan aynı sonucu verir. PM2 ise günlük ve çok süreçli kullanım kolaylığı sağlar.

Örnek bir birim dosyası şöyle görünür. Dosyayı /etc/systemd/system/site.service olarak kaydeder, ardından etkinleştirirsiniz.

[Unit]
Description=Next.js site
After=network.target

[Service]
User=deploy
WorkingDirectory=/var/www/example.com/current/.next/standalone
Environment=NODE_ENV=production PORT=3000 HOSTNAME=127.0.0.1
ExecStart=/usr/bin/node server.js
Restart=always

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now site
sudo systemctl status site

Node'un tam yolunu which node ile kontrol edin; nvm kullanıyorsanız yol farklı olur. Hangisini seçeceğiniz zevk meselesidir. Ekip PM2'ye alışkınsa PM2, sade kurulum istiyorsanız systemd uygundur.

Nginx ters proxy'yi Next.js için nasıl kurarsınız?

Next.js dokümanı, sunucuyu doğrudan internete açmak yerine Nginx gibi bir ters proxy kullanmanızı önerir. Proxy; bozuk istekleri, yavaş bağlantı saldırılarını, yük sınırlarını ve hız sınırlamayı karşılar. Böylece Next.js yalnızca render işini yapar.

Debian ve Ubuntu'da site dosyasını sites-available altında oluşturup sites-enabled içine bağlarsınız. Örnek yapılandırma şöyledir.

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Dosyayı kaydettikten sonra sözdizimini sınayın, ardından yapılandırmayı yeniden yükleyin. Önce test etmek, hatalı bir ayarla tüm siteyi düşürmenizi engeller.

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Nginx arkasında Next.js için hangi ayarlar önemlidir?

Üç ayar özellikle önemlidir. İlki Host başlığıdır. Nginx dokümanına göre varsayılan değer $proxy_host olduğu için uygulama, kendi adresini 127.0.0.1:3000 sanabilir. Bu yüzden yukarıda Host $host ekledik.

İkincisi X-Forwarded-Proto başlığıdır. Uygulama, isteğin HTTPS ile geldiğini bu başlıktan anlar. Eksikse yönlendirme ve mutlak bağlantı üretiminde http adresleri çıkabilir.

Üçüncüsü akış (streaming) desteğidir. Next.js dokümanına göre App Router akışı destekler, ancak Nginx varsayılan olarak yanıtı tamponlar. Akışı korumak için doküman, X-Accel-Buffering başlığını no yapmayı gösterir; bunu next.config.js içindeki headers() ile ekleyebilirsiniz.

• Nginx'in proxy_read_timeout varsayılanı dokümana göre 60 saniyedir; uzun süren isteklerde bunu bilin.
• Yükleme yapan formlarda client_max_body_size sınırını kontrol edin.
• Yük dengeleyici eklerseniz, aradaki her katmanın akışı tamponlamadan geçirdiğinden emin olun.

Ayar adlarını resmi sayfadan doğrulamak için Nginx proxy modülü dokümanına bakın.

Let's Encrypt SSL sertifikasını nasıl kurarsınız?

HTTPS için Certbot kullanabilirsiniz. Certbot, Nginx eklentisiyle sertifikayı alır ve yapılandırmanıza HTTPS bloğunu ekler. Kurulum yöntemi dağıtıma göre değiştiği için Certbot sitesinde dağıtımınızı seçip güncel talimatı izleyin.

Alan adının DNS kaydı sunucunuzun IP adresini göstermeden sertifika alamazsınız. Önce DNS sorgulama aracımızla A ve AAAA kayıtlarını kontrol edin.

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run

Certbot dokümanına göre çoğu kurulum otomatik yenilemeyle gelir; bu, certbot renew komutunu düzenli çalıştıran zamanlanmış bir görevdir. Yine de renew --dry-run ile denemeyi unutmayın. Zamanlayıcı kayıtlı mı diye systemctl list-timers çıktısına bakabilirsiniz.

Kurulumdan sonra SSL sorgulama aracıyla zinciri doğrulayın. Sertifikanın ne işe yaradığını merak ediyorsanız SSL sertifikası nedir yazımıza göz atın.

Next.js görsel optimizasyonu VPS'te nasıl çalışır?

Dokümana göre next/image ile görsel optimizasyonu, next start ile çalıştırınca ek ayar olmadan çalışır. Ancak bu iş sunucunun işlemcisini ve belleğini kullanır, çünkü Next.js görselleri derlemede değil çalışma anında optimize eder.

Standalone çıktıyla çalışırken sharp paketinin çıktıya girdiğini kontrol edin; gerekirse dokümandaki outputFileTracingIncludes örneğini kullanın. Ayrıca glibc tabanlı Linux sistemlerde, doküman ek bir bellek ayırıcı ayarı gerekebileceğini belirtir.

• Küçük VPS'te çok büyük kaynak görselleri yüklemeyin; önce boyutlandırın.
• Görsel hizmetini ayırmak isterseniz özel bir görsel yükleyici (loader) tanımlayabilirsiniz.
• Optimizasyonu kapatıp görselleri kendiniz hazırlamak da mümkündür.

Görsel boyutlandırmanın SEO tarafı için web sitesi görsel optimizasyonu yazımıza bakın.

Önbellek ve ISR tek VPS'te nasıl çalışır?

Next.js, üretilen sayfaları ve veriyi sunucu önbelleğinde tutar. Dokümana göre bu önbellek varsayılan olarak her Next.js örneğinin yerel diskinde durur. Tek sunuculu, kalıcı diskli bir VPS'te bu yapı ek ayar olmadan çalışır.

Süreci birden fazla örnekle çoğaltırsanız tablo değişir. Her örnek kendi önbelleğini tutar, yani bir örnekte yapılan yeniden doğrulama diğerine ulaşmaz. Bunun çözümü, özel bir önbellek yöneticisi (cache handler) ve Redis gibi ortak bir depodur.

Küçük ve orta ölçekli siteler için pratik öneri şudur: tek süreçle başlayın. Trafik ya da kesintisiz güncelleme ihtiyacı gerçekten doğunca çoklu örneğe geçin. Önbellek mantığını ayrıca yazılımda önbellekleme yazımızda anlattık.

VPS deploy sonrası güncelleme ve rollback akışını nasıl kurarsınız?

Her sürümü ayrı bir klasöre koyun ve current adlı bir sembolik bağ üzerinden yayınlayın. Böylece yeni sürüm hazır olunca bağı değiştirir, sorun çıkarsa eski sürüme saniyeler içinde dönersiniz.

/var/www/example.com/
  releases/
    20250101-1200/
    20250108-0930/
  current -> releases/20250108-0930

Sürümü kendi bilgisayarınızda ya da CI'da derleyip standalone klasörünü aktarmak, küçük sunucuda bellek baskısını da azaltır. Aktarım için rsync yeterlidir.

rsync -az --delete .next/standalone/ deploy@203.0.113.10:/var/www/example.com/releases/20250108-0930/
ssh deploy@203.0.113.10 "ln -sfn /var/www/example.com/releases/20250108-0930 /var/www/example.com/current"
ssh deploy@203.0.113.10 "pm2 reload ecosystem.config.js --env production"

Rollback için aynı bağı bir önceki klasöre çevirip süreci yeniden yüklersiniz. Yeniden yüklemeden sonra pm2 describe site çıktısına ve yanıt başlıklarına bakıp gerçekten doğru sürümün çalıştığını doğrulayın. Ancak bu yalnızca kodu geri alır. Veritabanı şemasını değiştirdiyseniz eski kodun yeni şemayla çalışıp çalışmadığını önceden düşünün. Yedek stratejisi için web sitesi yedekleme stratejisi yazımıza bakın.

Birden fazla örnek ve kesintisiz güncelleme için nelere dikkat edersiniz?

PM2'nin küme (cluster) kipi, kesintisiz yeniden yükleme sağlar. Ancak Next.js dokümanı, birden fazla örnekte ek ayar ister. Aksi halde tuhaf hatalar görürsünüz.

• Aynı derleme çıktısıyla tüm örnekleri başlatın; gerekirse generateBuildId ile tutarlı bir derleme kimliği üretin.
• Sunucu İşlevleri için NEXT_SERVER_ACTIONS_ENCRYPTION_KEY değerini tüm örneklerde aynı yapın; yoksa "Failed to find Server Action" hatası alırsınız.
• Sürüm uyumsuzluğunu önlemek için deploymentId ayarını kullanın.
• Önbelleği ortak bir depoya taşıyan bir önbellek yöneticisi tanımlayın.

Bu liste, ayrıntıyı Next.js'in kendi self-hosting rehberinden alır. Next.js self-hosting rehberini uygulamadan önce baştan sona okuyun.

Sunucu ayarları SEO'yu nasıl etkiler?

Arama motoru, siteye sunucunuz üzerinden ulaşır. Dolayısıyla sunucu yapılandırması, görünürlüğü dolaylı olarak etkiler; yani VPS deploy kararı bir SEO kararıdır da. Yavaş ilk yanıt, yanlış yönlendirme ve uzun süren 5xx hataları en bilinen risklerdir. Bu yüzden deploy işini yalnızca teknik bir iş saymayın.

Kural basittir: her adres tek bir kanonik biçimde açılmalıdır. Yani http ile https, www ile www'suz adresler arasında tek adımlı kalıcı yönlendirme kurun. Üstelik yönlendirme zincirleri hem ziyaretçiyi hem tarayıcıyı yavaşlatır.

Planlı bakım yapıyorsanız bunu ziyaretçiye ve arama motoruna doğru durum koduyla bildirin. Bakım sırasında 200 koduyla boş bir sayfa göstermek, yanlış sinyal verir. Ayrıca sunucunuzun konumu, hedef kitlenize uzaksa ilk bayt süresini uzatabilir.

Hızın sıralamaya etkisini aşağıda ayrıca ele alıyoruz. Next.js, sunucu tarafı render sayesinde içeriği HTML olarak gönderebilir; ancak bu avantaj, sunucu sağlıklıysa işe yarar.

VPS deploy sonrası neleri test etmelisiniz?

Siteyi yayına aldıktan sonra yalnızca ana sayfaya bakmayın. Pazarlama ve SEO açısından önemli kontroller vardır. Çünkü yanlış yönlendirme ya da hatalı durum kodu, arama görünürlüğünü sessizce düşürebilir.

• HTTP adresinin HTTPS'e, gerekiyorsa www adresinin ana adrese tek adımda yönlendiğini yönlendirme denetleyiciyle kontrol edin.
• Var olmayan bir adresin 404 durum kodu döndürdüğünü doğrulayın.
• robots.txt ve site haritasının sunucudan erişilebilir olduğunu görün.
• Sayfa hızını ve ilk bayt süresini Lighthouse ile performans testi yaparak ölçün.
• Tarayıcı konsolunda 404 veren statik dosya olmadığını kontrol edin.

Hız ile sıralama arasındaki ilişkiyi site hızı SEO'yu nasıl etkiler yazımızda inceledik. Deploy sonrası bakım için kısa bir kontrol listesi tutmanız, aynı hatayı iki kez yapmanızı önler.

Deploy sonrası günlük ve izlemeyi nasıl kurarsınız?

Çalışan bir site için günlük tutmak şarttır. PM2, uygulama çıktısını pm2 logs ile gösterir. Nginx ise erişim ve hata günlüklerini tutar; Debian ve Ubuntu'da varsayılan konum /var/log/nginx/ klasörüdür. Bu dosyalar zamanla büyüdüğü için döndürme (rotation) ayarını kontrol edin.

PM2 için günlük döndürme modülü vardır. Kurmadan önce modülün resmi sayfasındaki güncel talimatı okuyun.

pm2 install pm2-logrotate
pm2 logs site --lines 50

Bunun yanında dışarıdan bir izleme kurun. Basit bir kontrol, sitenin kapandığını ziyaretçilerden önce size haber verir. Hızlı bir kontrol için site çöktü mü aracını kullanabilirsiniz.

Disk dolmasına da dikkat edin. Günlükler, eski sürüm klasörleri ve önbellek diski doldurabilir. Bu nedenle son birkaç sürümü tutup eskileri silen basit bir temizlik alışkanlığı edinin.

En sık hatalar neler, nasıl çözersiniz?

Aşağıdaki tablo, deploy sırasında sık karşılaşılan belirtileri ve ilk kontrol noktasını toplar. Tablo, resmi dokümanlardaki davranışlardan türettiğimiz bir kontrol sırasıdır; her ortamda aynı olmayabilir.

Sorun çözülmezse tahmin yürütmek yerine kanıt toplayın. Süreç günlüğünü, Nginx hata günlüğünü ve istek başlıklarını yan yana okuyun. Çoğu zaman üç kaynaktan biri, sorunun hangi katmanda olduğunu açıkça gösterir. Ardından yalnızca o katmanı değiştirin; aynı anda birden fazla ayar değiştirmek, neyin işe yaradığını gizler.

Hatayı bulmak için sırayla ilerleyin: önce süreç, sonra proxy, ardından alan adı ve sertifika. Sırayı atlamak, vakit kaybettirir.

Ne zaman kendiniz yapmamalı, hosting sağlayıcısına bırakmalısınız?

Dürüst olalım: her ekip için VPS yönetmek doğru değildir. Sunucunuzu güncelleyecek, izleyecek ve yedekleyecek biri yoksa yönetilen bir çözüm daha güvenlidir. Özellikle ödeme alan bir e-ticaret sitesinde kesinti doğrudan gelir kaybıdır.

• Sunucu yamalarını ve güvenlik güncellemelerini takip edecek kimse yoksa yönetilen platformu seçin.
• Kesinti anında müdahale edecek bir nöbet düzeniniz yoksa riski baştan hesaplayın.
• Mevzuat, veri yerleşimi ya da sözleşme gereği özel sunucu gerekiyorsa sağlayıcınızla birlikte planlayın.
• Ani trafik dalgalanması yaşıyorsanız tek VPS yetmeyebilir.

Kurulumu birlikte planlamak isterseniz özel yazılım geliştirme hizmetimiz bu tür projeleri kapsar. Docker ile paketleme düşünüyorsanız Docker nedir yazısı başlangıç için yeterlidir.

VPS deploy için hangi sırayla ilerlemelisiniz?

Özetle sıra şudur: kararı verin, sunucuyu hazırlayın, standalone çıktıyı alın, elle test edin, PM2'ye geçin, Nginx'i kurun, SSL'i açın ve güncelleme akışını kurun. Her adımda bir önceki adımı doğrulamak, hatayı küçük tutar.

Son olarak yazının en önemli uyarısını tekrarlayalım: komutları anlamadan kopyalamayın. Her komutun ne yaptığını resmi dokümandan kontrol edin, önce deneme sunucusunda çalıştırın ve ancak sonra canlı siteye uygulayın. Böylece hem hata riskini hem de kesinti süresini düşürürsünüz.

Ayrıca unutmayın: deploy bir kez yapılan iş değildir. Güncelleme, yedek ve izleme sürekli işlerdir. Bunları üstlenemeyecekseniz, VPS yerine yönetilen çözüm daha akıllı bir tercih olabilir.

Sitenizin teknik altyapısı ve görünürlüğü konusunda destek isterseniz web tasarım ve geliştirme sayfamıza bakabilirsiniz. Sorularınız için ekibimizle iletişime geçebilirsiniz.