Yeni VPS Sunucuyu 30 Dakikada Canliya Alma Rehberi

Yeni VPS Sunucuyu 30 Dakikada Hazır Hale Getirme Stratejisi

Yeni bir VPS aldığınızda geri sayım başlar. Proje sahibi yayına çıkmak ister, geliştirici ekip alan adını bağlamaya hazırdır, siz ise daha VPS ilk kurulum aşamasındasınızdır. Panik yapmak yerine doğru sırayı izlemek gerekir; temel adımları önceden belirlediğinizde 30 dakika içinde güvenli bir başlangıç yapabilirsiniz.

Buradaki adımlar, sıfırdan alınan Debian 13 veya Ubuntu 24.04 LTS tabanlı bir Linux VPS için pratik bir yol haritasıdır. Odak noktası hızlı ama doğru sunucu yapılandırma, minimum ama etkili sunucu güvenliği ayarları ve temel servislerin çalışır hale getirilmesidir. Uzun vadeli mimariyi ayrıca planlayabiliriz; burada hedefimiz VPS canlıya alma işini tekrarlanabilir bir standartla tamamlamak.

Eğer hâlâ doğru kapasitede bir plan seçmediyseniz, üzerinde çalışacağınız projeye göre VPS.TC Linux VPS ya da daha yüksek ihtiyaçlar için VDS sunucu seçeneklerine göz atabilirsiniz.

Süre Yönetimi: 30 Dakikanın Mantıklı Dağılımı

Her adıma ne kadar zaman ayıracağınızı bilmek, panik seviyesini ciddi şekilde düşürür. Yaklaşık dağılım şöyle olabilir:

Bu süreler yaklaşık değerlerdir. Dağıtım, disk hızı, paket önbelleği ve ağ bağlantısına göre birkaç dakikalık fark normaldir. Önemli olan her kurulumda tekrarlanabilir bir VPS ilk kurulum standardı kullanmaktır.

İlk 5 Dakika: Güvenli SSH Erişimi ve Paket Güncellemeleri

Yeni açılan VPS çoğu zaman yalnızca temel işletim sistemi kurulumu ile gelir. Sunucuya ilk bağlandığınız an, sonraki bakım ve güvenlik adımlarının temelini atarsınız.

SSH ile bağlantı ve root parolasını güvenceye alma

Önce yönetim panelinden IP adresini, SSH portunu ve geçici parolayı alın. SSH portu çoğunlukla 22’dir. Ardından kendi makinenizden bağlanın:

ssh root@SUNUCU_IP_ADRESI

İlk iş olarak geçici root parolasını değiştirin:

passwd

Parolanın uzun, benzersiz ve parola yöneticisinde saklanan bir değer olduğundan emin olun. Bu hesabı günlük operasyonlar için kullanmayacağız; birazdan sudo yetkili ayrı bir kullanıcı oluşturacağız.

Paket depolarını güncelleme

Debian ve Ubuntu sistemlerinde önce paket listesini yenileyip mevcut paketleri güncelliyorum:

apt update && apt full-upgrade -y

full-upgrade, gerekirse bağımlılık değişikliklerini de yönetir. Kernel veya temel sistem kütüphaneleri güncellendiyse yeniden başlatma gerekip gerekmediğini kontrol edin:

if [ -f /var/run/reboot-required ]; then cat /var/run/reboot-required; fi

RHEL, AlmaLinux ve Rocky Linux gibi dağıtımlarda karşılığı:

dnf upgrade -y

Bu adımı atlamak, bilinen güvenlik açıkları bulunan bir sunucuyu internete açmak demektir. Sunucu güvenliği açısından bunu ertelemiyorum.

5-15 Dakika: Temel Sunucu Yapılandırma Adımları

Sunucu güncel. Şimdi root ile çalışmayan, anlaşılır log üreten ve bakımı kolay bir sistem kuracağız.

Sudo yetkili normal kullanıcı oluşturma

Production ortamında root ile doğrudan çalışmak hem yetki kapsamını büyütür hem de hataların etkisini artırır. Debian veya Ubuntu’da kullanıcı oluşturup sudo grubuna ekleyin:

adduser deploy
usermod -aG sudo deploy

Yeni oturum açarak bağlantıyı ve sudo yetkisini test edin:

ssh deploy@SUNUCU_IP_ADRESI
sudo whoami

Çıktı olarak root görmelisiniz. AlmaLinux veya Rocky Linux kullanıyorsanız grup adı genellikle wheel olur:

usermod -aG wheel deploy

Benzer iki VPS arasında işlem yaparken önce hostname ve IP kontrolü yaparım. Bir keresinde yanlış terminal sekmesinde dosya temizlemeye ramak kala hostname’i görünce durdum; kırmızı production prompt’u bu alışkanlığın yerini tutmuyor, sadece hatayı fark etmeyi kolaylaştırıyor.

Hostname, saat dilimi ve temel ayarlar

Log analizi ve izleme tarafında yanlış hostname ile hatalı zaman damgası birleştiğinde olayın hangi makinede gerçekleştiğini anlamak zorlaşır:

sudo hostnamectl set-hostname proje-uygulama-01
sudo timedatectl set-timezone Europe/Istanbul
timedatectl status

Sunucu UTC ile çalışacak bir ekip veya dağıtık sistem kullanıyorsa saat dilimini değiştirmek yerine UTC standardını korumak daha doğru olabilir. Önemli olan seçimin bütün sistemlerde tutarlı olmasıdır.

SSH anahtarıyla kimlik doğrulama (mecburi olması gereken “opsiyonel” adım)

Parola ile giriş çalışır; ancak internete açık SSH için anahtar tabanlı kimlik doğrulama daha iyi bir temel sağlar. Yerel makinenizde henüz anahtar yoksa:

ssh-keygen -t ed25519 -C "deploy@proje"
ssh-copy-id deploy@SUNUCU_IP_ADRESI

Windows’ta OpenSSH istemcisi kullanıyorsanız public anahtarı sunucudaki ~/.ssh/authorized_keys dosyasına güvenli biçimde ekleyebilirsiniz. Yeni terminalde anahtarla giriş yapmadan parola ile SSH erişimini kapatmayın.

15-25 Dakika: Hızlı ama Sağlam Sunucu Güvenliği Ayarları

Yeni açılan IP adresleri otomatik taramalara kısa sürede girer. Bu yüzden sunucu güvenliği adımlarını uygulamayı servis kurulumunun sonuna bırakmıyorum.

Minimal firewall kural seti

Ubuntu ve Debian’da ufw küçük VPS’lerde pratik bir arayüzdür. Önce SSH erişimini izinli hale getirin, sonra firewall’u etkinleştirin:

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

SSH portunu değiştirdiyseniz ufw enable komutundan önce yeni portu ekleyin. Firewall’u açmadan önce bağlantı sağlayan kuralı yazmamak, uzaktaki VPS’te kendinizi kilitlemenin en hızlı yollarından biridir.

SSH konfigürasyonunda temel sıkılaştırma

Güncel OpenSSH kurulumlarında ayarları ayrı bir drop-in dosyasında tutmak, ana dosyayı değiştirmekten daha düzenlidir:

sudo vim /etc/ssh/sshd_config.d/99-hardening.conf

Dosyaya aşağıdaki ayarları ekleyin:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes

Ubuntu ve Debian’da yapılandırmayı doğrulayıp servisi yeniden başlatmadan yeniden yüklemek için:

sudo sshd -t
sudo systemctl reload ssh

sshd -t hata verirse reload çalıştırmayın. Ayrı bir terminalde yeni kullanıcıyla bağlantıyı test edin ve mevcut oturumu kapatmadan önce erişimin gerçekten çalıştığını doğrulayın. RHEL tabanlı sistemlerde servis adı çoğunlukla sshd olur.

Brute force denemelerine karşı temel koruma

SSH anahtarı kullanmak riski azaltır, fakat logları izlemek ve tekrar eden denemeleri sınırlamak yine de faydalıdır. Debian ve Ubuntu’da:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Dağıtımın varsayılan jail ayarlarını doğrudan değiştirmek yerine gerektiğinde /etc/fail2ban/jail.d/ altında yerel bir dosya oluşturun. Fail2ban’ı tek güvenlik katmanı gibi görmeyin; güncellemeler, anahtar erişimi, firewall ve log takibi birlikte düşünülmeli.

Uygulamayı Ayağa Kaldırma: Web Sunucusu ve Servisler

Temel sunucu yapılandırma ve güvenlik ayarları tamamlandı. Şimdi VPS canlıya alma işinin uygulama tarafına geçebiliriz. Aşağıdaki örnek Debian 13 ve Ubuntu 24.04 üzerinde Nginx kullanan basit bir web katmanını gösteriyor.

Nginx ile hızlı bir web katmanı kurma

sudo apt install nginx -y
sudo systemctl enable --now nginx
systemctl status nginx --no-pager

Tarayıcıdan http://SUNUCU_IP_ADRESI adresini açtığınızda varsayılan Nginx sayfasını görüyorsanız web servisi çalışıyordur. İlk kez yaptığım bir kurulumda status çıktısına bakmadan doğrudan uygulama dosyalarına geçmiştim; servis kapalı olduğu için birkaç dakika dosya izinlerini suçladım.

Basit bir sanal host örneği

Alan adı DNS’te bu sunucunun adresine yönleniyorsa Nginx için ayrı bir server bloğu oluşturabilirsiniz:

sudo vim /etc/nginx/sites-available/proje.conf

server {
    listen 80;
    listen [::]:80;
    server_name ornekdomain.com www.ornekdomain.com;
    root /var/www/proje/public;
    index index.html index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Dizini oluşturup basit bir test dosyası ekleyin:

sudo mkdir -p /var/www/proje/public
echo "Merhaba, VPS.TC üzerinde çalışan uygulama" | sudo tee /var/www/proje/public/index.html
sudo ln -s /etc/nginx/sites-available/proje.conf /etc/nginx/sites-enabled/proje.conf
sudo nginx -t
sudo systemctl reload nginx

nginx -t başarılı olmadan reload çalıştırmayın. Bu küçük kontrol, daha önce kendi yaptığım bir yazım hatasının çalışan siteyi riske atmasını engelleyen alışkanlığa dönüştü.

Uygulama katmanı: PHP, Node.js veya container yapısı

İlk 30 dakikada bütün mimariyi tamamlamaya çalışmak yerine uygulamanın güvenli ve ölçülebilir biçimde ayağa kalkmasına odaklanın.

• PHP tabanlı uygulamalarda dağıtımın desteklediği PHP sürümünü, php-fpm paketini ve gerekli eklentileri kurup Nginx’i FPM socket’ine bağlayın.
• Node.js uygulamasını doğrudan internete açmak yerine 127.0.0.1 üzerinde çalıştırıp Nginx’i reverse proxy olarak kullanın. Süreç yönetimi için systemd veya projenin ihtiyacına uygun bir process manager tercih edin.
• Container kullanıyorsanız Docker Engine ve Compose eklentisinin güncel, dağıtımınızla uyumlu paketlerini kullanın; uygulama portlarını yalnızca gerçekten gerekiyorsa public hale getirin.

İlk kurulumda karmaşık bir CI/CD hattı kurmak şart değil. Fakat manuel adımların kaydını tutun; çalışan bir sistemi daha sonra Ansible veya başka bir otomasyonla yeniden üretilebilir hale getirebilirsiniz.

Canlıya Çıkmadan Önce Son 5 Dakikalık Kontrol Listesi

Her şey çalışıyor gibi görünürken unutulan küçük bir detay production ortamında uzun bir geceye dönüşebilir. Ben kontrol listesini deployment’ın son komutu değil, canlıya çıkışın bir parçası kabul ediyorum.

Güvenlik odaklı kontroller

• Root ile doğrudan SSH girişi kapalı mı?
• Parola ile SSH girişi kapalı ve anahtarla yeni oturum açılabiliyor mu?
• Firewall yalnızca gerekli portları mı açıyor?
• SSH yapılandırması sshd -t ile doğrulandı mı?
• Sunucu saat kaynağı ve saat dilimi beklendiği gibi mi?
• Gereksiz servisler ve public portlar kapalı mı?

Bu sorulardan birine cevap veremiyorsanız canlı trafiği bekletip önce eksik ayarı tamamlamak daha güvenlidir.

İşlevsellik ve performans odaklı kontroller

• Alan adı doğru IP adresine çözülüyor mu?
• HTTP ve HTTPS erişimi beklediğiniz gibi çalışıyor mu?
• Nginx ve uygulama loglarında belirgin hata var mı?
• Uygulama ilk yük altında nasıl davranıyor?
• Yedekleme, monitoring ve disk doluluk takibi planlandı mı?

İlk aşamada ayrıntılı bir yük testi gerekmeyebilir; ancak production trafiğine çıkmadan önce kontrollü birkaç istekle davranışı gözlemleyin. Daha fazla esneklik gerekiyorsa bulut sunucu veya sanal veri merkezi seçeneklerini değerlendirebilirsiniz.

Tekrar Edilebilir Bir VPS İlk Kurulum Standardı Oluşturmak

Her projede aynı ayarları elle yapmak bir noktaya kadar işe yarar. Sonra unutulan tek bir kural, iki sunucu arasındaki fark veya yanlış bir paket sürümü bakım maliyetini artırır.

Bu adımları ekip içinde bir baseline haline getirebilirsiniz:

• SSH erişimi, root parolası ve paket güncellemeleri için standart komut seti
• Sudo yetkili kullanıcı, hostname ve saat dilimi için sabit prosedür
• Sunucu güvenliği için firewall, SSH sıkılaştırması ve brute force koruması kontrol listesi
• Nginx veya kullandığınız web sunucusu için test edilmiş sanal host şablonları
• Disk, RAM, servis durumu ve yedekleme kontrolleri

İki kez elle yaptığınız işi üçüncüde Ansible playbook haline getirmek mantıklıdır. Tek satırlık işlem için YAML dosyası açmak bazen gereksizdir; yine de sık tekrarlanan kurulumlarda Cloud-init, Ansible veya Terraform ciddi hata payı kazandırır.

Yeni bir VPS’i yayına alırken alan adı DNS kayıtlarını ve transfer durumunu da kontrol ediyorum. Süreci baştan sona planlamak için alan adı transferi nasıl yapılır rehberimdeki adımları ve kontrol listesini kullanabilirsiniz.

Sunucuyu yayına aldıktan sonra HTTPS yapılandırmasını da tamamlayın. Alan adını doğru sunucuya yönlendirme, Nginx ayarları ve otomatik yenileme adımları için VPS’te SSL Sertifikası Kurulumu: Let’s Encrypt Rehberi rehberine bakabilirsiniz.

Yeni bir VPS’te bellek kullanımını ve swap durumunu da kontrol ediyorum. RAM’in yoğun kullanıldığı senaryolarda doğru yapılandırma için VPS’te Swap Alanı Oluşturma ve Linux Bellek Yönetimi rehberini inceleyebilirsiniz.

VPS’inizi temel ayarlarıyla canlıya aldıktan sonra onu bir oyun sunucusu olarak değerlendirmek isterseniz, VPS’te Minecraft sunucusu kurma rehberi ile Java, Paper, güvenlik duvarı ve yedekleme adımlarını uygulayabilirsiniz.

Aynı kurulum adımlarını tekrar tekrar elle uygulamak yerine Cloud-init ile VPS kurulumunu otomatikleştirme yöntemini kullanabilirsiniz. İlk açılışta kullanıcı oluşturma, paket yükleme ve servis yapılandırma gibi işlemler bu yaklaşımla daha tutarlı hale gelir.

Benim için 30 dakikalık hedef, güvenlik kontrollerini atlamak anlamına gelmiyor. Gerekirse süreyi uzatırım; yanlış sunucuda hızlı olmak, doğru sunucuda yavaş olmaktan çok daha pahalıya mal olabilir.

Sık Sorulan Sorular