Kişisel Siteyi Sıfırdan Yayına Almak: VPS, Nginx ve HTTPS

Kişisel bir siteyi paylaşımlı hostingden bir sanal sunucuya taşırken izlediğim gerçek adımlar: Ubuntu, Nginx, PHP-FPM, MariaDB kurulumu, SSH anahtarı, doğru belge kökü ve Let's Encrypt ile HTTPS.

Giriş

Bir kişisel siteyi paylaşımlı hostingden kendi sanal sunucuma (VPS) taşırken izlediğim adımları, aldığım kararları ve dikkat ettiğim güvenlik noktalarını bu yazıda topladım. Amaç bir ürün tanıtmak değil; aynı yolu yürüyecek birine sağlam bir harita bırakmak. Sunucuya, alan adına veya kimlik bilgilerine dair hassas hiçbir ayrıntı paylaşmıyorum — anlatı sürecin kendisi üzerine.

Neden paylaşımlı hosting yerine VPS

Paylaşımlı hostingde çoğu zaman SSH erişimi ve kök (root) yetkisi olmaz; arka planda çalışan işler, zamanlanmış görevler ve sürüm bazlı dağıtım zorlaşır. Uygulamayı rahatça çalıştırmak için sunucuya tam hâkim olmak istedim; bu yüzden temiz bir Linux sunucusuyla başladım.

Kurduğum yapı

Klasik ve dayanıklı bir yığın seçtim:

• Ubuntu (uzun destekli LTS sürüm) — istikrar için.
• Nginx — web sunucusu.
• PHP-FPM — uygulama çalışma zamanı.
• MariaDB — veritabanı.

Panel yazılımı yerine bu bileşenleri elle kurmayı tercih ettim; her parçanın ne yaptığını bilmek, sorun çıktığında en büyük avantaj oluyor. (Bu kişisel bir tercih; panelle çalışmak da geçerli bir yoldur.)

Güvenliği baştan doğru kurmak

Sunucu ayağa kalkar kalkmaz yapılması gerekenler var; bunları sonraya bırakmak risklidir:

• SSH anahtarı: Parola ile girişi bırakıp anahtar tabanlı girişe geçtim; kaba kuvvet denemelerine kapı kapanıyor.
• Güvenlik duvarı: Yalnız gerekli portları (SSH, HTTP, HTTPS) açtım.
• Doğru belge kökü: Web sunucusunu, uygulamanın yalnızca public/ klasörüne bakacak şekilde ayarladım. Böylece yapılandırma dosyaları ve gizli değerler tarayıcıdan erişilemez olur — en sık yapılan ve en tehlikeli hatalardan biri budur.

Kodu taşımak ve HTTPS

Kodu sürüm kontrolünden (Git) çektim; gizli ayarları içeren dosyayı depoya dahil etmeden sunucuda ayrı ve dar izinlerle tuttum. Son olarak Let's Encrypt ile ücretsiz bir SSL sertifikası alıp siteyi tamamen HTTPS'e taşıdım; sertifika otomatik yenilenecek şekilde ayarlandı.

DNS'i taşırken e-postayı korumak (kolay atlanan tuzak)

İşin en sinsi kısmı buydu. Alan adının e-postası da aynı alan adı üzerinden çalışıyordu: MX kaydı doğrudan alan adının kendisine işaret ediyordu. Web'i yeni sunucuya almak için alan adının A kaydını doğrudan değiştirseydim, e-posta da yeni sunucuya yönlenecekti — ama yeni sunucuda mail sistemi yok; yani gelen e-postalar sessizce kaybolurdu.

Çözüm sırası önemliydi: önce e-postayı eski sunucuya sabitleyip MX'i oraya yönelttim, sonra web'in A kaydını yeni sunucuya çevirdim. Böylece site yeni sunucuya taşındı, e-posta hiç kesilmeden eski yerinde kaldı. Çıkarım: DNS'te web ve mail ayrı düşünülmeli; sıra yanlışsa mail sessizce kesilir.

Karşılaştığım sorunlar

• İlk kurulumda küçük süreç aksaklıkları (yarım kalan bir komut, izin ayarları) çıktı; acele etmeden tek tek çözmek en sağlıklısı oldu.
• Anahtar tabanlı girişte küçük bir yapılandırma detayı ilk denemede giriş yaptırmadı; sabırla doğrulayınca oturdu.
• Yukarıdaki DNS/mail tuzağı — en kritik olanı.

Öğrendiklerim

(Aşağıdakiler kişisel çıkarımlarım.)

• Güvenliği "sonra hallederim" demek en pahalı erteleme; SSH anahtarı ve belge kökü ilk günden doğru olmalı.
• Her katmanı elle kurmak, hata anında neye bakacağını öğretiyor.
• Gizli değerler asla sürüm kontrolüne girmemeli; sunucuda ayrı ve dar izinlerle durmalı.
• DNS taşımada mail'i ayrı düşünmezsen, en görünmez hatayı yaparsın.

Sonraki adım

Bu akışın temelinde sürüm kontrolü var; Git'e alışkın değilsen Git ile Sürüm Kontrolüne Giriş dersiyle başla. Ortamı tekrarlanabilir kılmak ve dağıtımı otomatikleştirmek için Sözlük'teki Docker ve CI/CD tanımlarına göz atabilirsin.