Tek VPS Üzerinde Birden Fazla WordPress Sitesi Barındırmak

Tek VPS’te Çoklu WordPress Barındırma Neden Gündeme Geliyor?

Bir ajans, freelancer ya da birden fazla markayı yöneten bir ekipseniz, belli bir noktadan sonra aynı soruyla karşılaşıyorsunuz: “Tüm bu WordPress sitelerini tek bir VPS üzerinde, hem güvenli hem de yönetilebilir şekilde nasıl toplayabilirim?” paylaşımlı hosting paketleri belli bir sayının üzerinde siteyi taşımakta zorlanmaya başlıyor; her müşteri için ayrı VPS açmak ise maliyet ve operasyon yükü açısından yorucu olabiliyor. Tam bu noktada, tek VPS üzerinde birden fazla WordPress sitesi barındırma fikri devreye giriyor.

Bu yazıda DCHost ekibi olarak, yıllardır sahada kullandığımız pratik bir mimariyi adım adım anlatacağız: Her site için ayrı Linux kullanıcı hesabı, ayrı Nginx vHost, ayrı PHP-FPM havuzu ve ayrı veritabanı. Böylece hem kaynakları daha verimli kullanıyor, hem de “bir site hacklenirse diğerleri ne olacak?” kaygısını ciddi oranda azaltıyoruz.

Odak noktamız cPanel tarzı hazır paneller değil, daha esnek ve kontrolü sizde olan bir kurulum olacak. Yani DCHost üzerindeki bir Linux VPS alıp, sadece SSH ile bu mimariyi uçtan uca kurabilecek seviyede net bir yol haritası paylaşacağız. Araya gerçek senaryolar, yapılandırma örnekleri ve yıllar içinde öğrendiğimiz küçük ama kritik püf noktalarını serpiştireceğiz.

Senaryo ve Hedef: Tek VPS, Çoklu Müşteri Sitesi

Örnek üzerinden gidelim. Diyelim ki bir dijital ajanssınız ve elinizde şu tip projeler var:

• Kurumsal WordPress site (kurumsal.com)
• Blog odaklı bir içerik sitesi (blogmarka.com)
• Küçük ölçekli WooCommerce mağazası (dukkan.com)

Üçü de kritik, üçü de uptime istiyor, üçü de farklı geliştirme ekipleri tarafından zaman zaman kurcalanıyor. Hepsi için ayrı bir VPS açarsanız hem maliyet artıyor hem de yönetilecek sunucu sayısı çoğalıyor. Tek VPS üzerinde hepsini toplamak istiyorsunuz ama şu riskleri almak istemiyorsunuz:

• Bir sitenin hacklenmesiyle diğer sitelerin de etkilenmesi
• Bir müşterinin yoğun trafik aldığında diğerlerine CPU / RAM bırakmaması
• Log, yedek, dosya izinleri gibi konuların tam bir kaosa dönüşmesi

Bizim kuracağımız mimarinin amacı tam olarak şu:

• İzolasyon: Her WordPress sitesi, kendi Linux kullanıcısı, kendi PHP-FPM havuzu, kendi Nginx vHost’u ve kendi veritabanı ile çalışacak.
• Kaynak kontrolü: Her site için ayrı PHP-FPM ayarları, gerekirse ayrı limitler.
• Yönetilebilirlik: Yapılandırma dosyalarınız okunabilir, mantıklı klasör yapılarıyla kurgulanmış olacak.
• Ölçeklenebilirlik: Gerekirse tek bir siteyi başka bir VPS’e taşımak kolay olacak.

Bu yazıdaki yaklaşım, “tek WordPress multisite mi, yoksa ayrı kurulumlar mı?” sorusuna da pratik bir alternatif sunuyor. Eğer bu ikilemi detaylı tartmak istiyorsanız, mutlaka WordPress Multisite mi ayrı kurulumlar mı sorusunu teknik açıdan değerlendirdiğimiz rehbere de göz atın.

Mimariyi Çizelim: Katman Katman Yapı

Önce büyük resmi netleştirelim. Tek VPS üzerinde çoklu WordPress için önerdiğimiz katmanlar:

1. Linux kullanıcılar ve klasör yapısı
   Her site için ayrı kullanıcı ve /home/siteadi/ dizini.
2. Nginx sanal host (vHost) yapılandırmaları
   Her domain için ayrı server bloğu, ayrı root dizini, ayrı log dosyaları.
3. PHP-FPM havuzları
   Her site için ayrı .conf, ayrı socket, ayrı kullanıcı/grup.
4. Veritabanı katmanı
   Her site için ayrı veritabanı ve kısıtlı yetkili veritabanı kullanıcısı.
5. SSL / SNI ve DNS
   Tek IP üzerinde birden fazla HTTPS site, Let’s Encrypt otomasyonu.
6. Güvenlik ve yedekleme
   Firewall, fail2ban, dosya izinleri, merkezi veya site bazlı yedek.

Bu model, DCHost üzerindeki NVMe diskli Linux VPS paketlerimizle birebir uyumlu. CPU/RAM ihtiyacını belirlerken isterseniz WordPress ve WooCommerce için CPU ve RAM hesaplama rehberimizden de faydalanabilirsiniz.

Linux Katmanı: Ayrı Kullanıcı ile Gerçek İzolasyon

İşin temelinde, her site için ayrı Linux kullanıcısı yaratmak yatıyor. Tek bir kullanıcı altında 10 siteyi /var/www/ içine yığıp sahiplikleri www-data bırakmak, güvenlik açısından en zayıf senaryolardan biri. Bizim istediğimiz ise şu:

• site1 kullanıcısı sadece /home/site1/ altında her şeye sahip olsun.
• site2 kullanıcısı sadece /home/site2/ altında her şeye sahip olsun.
• Hiçbiri diğerinin dosyalarını okuyamasın.

Örnek bir klasör yapısı şöyle olabilir:

/home/
  site1/
    public_html/   # WordPress dosyaları
    logs/          # Nginx & PHP logları (isteğe bağlı)
    backups/       # Site özel yedekler
  site2/
    public_html/
    logs/
    backups/

Kullanıcı oluştururken kabaca şu mantığı izleyebilirsiniz (komutlar dağıtıma göre ufak farklılık gösterebilir):

useradd -m -d /home/site1 -s /bin/bash site1
passwd site1
mkdir -p /home/site1/public_html
chown -R site1:site1 /home/site1

Eğer SSH erişimini sadece SFTP ile sınırlamak istiyorsanız, chroot/SFTP-only yapılandırmaları devreye girer. Çoklu kullanıcı ve yetki tasarımı konusunda daha derin inmek isterseniz, Linux VPS’te kullanıcı, grup ve sudo mimarisi rehberimizde kapsamlı örnekler bulabilirsiniz.

Dosya İzinleri ve Sahiplik

WordPress sitelerinde pratik ve nispeten güvenli bir temel yaklaşım:

• Dosyalar: 644
• Klasörler: 755
• Sahip: site1:site1 (ilgili kullanıcı)

Bu konuyu daha teorik değil, doğrudan WordPress bağlamında ele aldığımız bir yazımız var: Linux dosya izinleri ve güvenli ayarlar rehberi. Oradaki öneriler bu mimari için de birebir geçerli.

Nginx vHost Mimarisi: Her Domain Ayrı Birer “Kiracı”

Nginx tarafında hedefimiz, her alan adını ayrı bir vHost olarak tanımlamak. Genelde aşağıdaki dizin yapısı kullanılır:

/etc/nginx/
  sites-available/
    kurumsal.com.conf
    blogmarka.com.conf
    dukkan.com.conf
  sites-enabled/
    kurumsal.com.conf -> ../sites-available/kurumsal.com.conf
    ...

Örnek bir vHost yapılandırması (basitleştirilmiş haliyle) şöyle olabilir:

server {
    listen 80;
    server_name kurumsal.com www.kurumsal.com;

    root /home/site1/public_html;
    index index.php index.html index.htm;

    access_log /var/log/nginx/kurumsal.access.log;
    error_log  /var/log/nginx/kurumsal.error.log;

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

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php-fpm-site1.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param SCRIPT_NAME $fastcgi_script_name;
    }

    location ~* .(jpg|jpeg|png|gif|css|js|ico|webp|avif)$ {
        expires 30d;
        access_log off;
    }
}

Dikkat ederseniz, PHP isteklerini domain bazlı değil, site1’e özel bir PHP-FPM socket’ine yolluyoruz. Birazdan o havuz yapılandırmasını da göreceğiz.

HTTP’den HTTPS’e ve SNI

Günümüzde tüm sitelerin HTTPS olması artık tartışmasız bir zorunluluk. Tek VPS’te, hatta tek IP’de onlarca HTTPS site barındırabilirsiniz; burada devreye SNI (Server Name Indication) giriyor. SNI sayesinde istemci, TLS el sıkışması aşamasında hangi domain için geldiğini belirtiyor ve sunucu da ona uygun sertifikayı gönderiyor.

Bu konuyu detaylı anlattığımız tek IP üzerinde birden fazla HTTPS site barındırma ve SNI rehberimize mutlaka göz atın. Oradaki örnekler bu mimariyle birebir uyumlu.

PHP-FPM Havuzları: Her Site İçin Ayrı “Motor”

Nginx, PHP çalıştırmak için doğrudan PHP’ye dokunmaz; genelde arada PHP-FPM (FastCGI Process Manager) vardır. Varsayılan kurulumlarda tüm siteler tek bir www havuzu üzerinden çalışır. Bizim hedefimiz ise her site için ayrı bir PHP-FPM havuzu kurmak:

• Havuz kullanıcı/grubu: ilgili Linux kullanıcısı (site1, site2 vb.)
• Socket dosyası: /run/php-fpm-site1.sock gibi benzersiz bir yol
• Havuz başına pm, pm.max_children gibi kaynak limitleri

Örnek bir PHP-FPM havuzu (dağıtıma göre dosya yolu değişebilir):

;/etc/php-fpm.d/site1.conf
[site1]
user = site1
group = site1
listen = /run/php-fpm-site1.sock
listen.owner = nginx
listen.group = nginx

pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 5

php_admin_value[upload_max_filesize] = 64M
php_admin_value[post_max_size] = 64M
php_admin_value[memory_limit] = 256M
php_admin_value[display_errors] = Off
php_admin_flag[log_errors] = On

Böylece:

• site1’in PHP süreçleri site1 kullanıcısı ile çalışır; diğer sitelerin dosyalarını okuyamaz.
• WooCommerce gibi ağır siteler için pm.max_children değerini artırabilir, küçük bloglar için düşürebilirsiniz.
• Bir sitede memory leak olsa bile, diğer sitelerin PHP havuzları görece izole kalır.

PHP-FPM ayarlarını WordPress ve WooCommerce bağlamında çok daha detaylı tartıştığımız PHP-FPM hesaplama rehberini de bu mimariyi kurarken yanınızda açık tutmanızı öneririm.

Veritabanı Katmanı: Ayrı DB, Ayrı Kullanıcı, Sıkı Yetkiler

Birçok kurulumda gördüğümüz tipik hata: Tüm siteler için aynı veritabanı kullanıcısını kullanmak, hatta bazen aynı veritabanını paylaşmak. Tek VPS’te çoklu WordPress için minimum iyi pratik şu olmalı:

• Her site için ayrı veritabanı (ör: wp_kurumsal, wp_blogmarka, wp_dukkan).
• Her veritabanı için ayrı, kısıtlı yetkili kullanıcı (ör: dbuser_kurumsal gibi).
• Kullanıcıya sadece kendi veritabanı üzerinde yetki vermek (GRANT ALL ON wp_kurumsal.* TO…).

Bu sayede:

• Bir sitede SQL injection açılsa bile, diğer sitelerin veritabanlarına doğrudan erişilemez.
• Yedek ve geri yükleme operasyonlarını site bazlı planlamak kolaylaşır.
• İleride tek bir siteyi farklı bir VPS’e taşımanız gerektiğinde, o siteye ait DB’yi almak çok daha basit olur.

Veritabanı replikasyonu, ayrı DB sunucusuna geçiş gibi daha ileri senaryolarla ilgileniyorsanız, blogumuzdaki MariaDB vs MySQL vs PostgreSQL karşılaştırmasını da mutlaka inceleyin.

SSL, DNS ve Let’s Encrypt Otomasyonu

Tek VPS üzerinde birden fazla domain için HTTPS kurmak için üç adımı netleştirelim:

1. DNS kayıtları: Her domain için A kaydını VPS IP’nize (ve gerekiyorsa AAAA kaydıyla IPv6 adresinize) yönlendirin.
2. Nginx HTTP vHost’ları: 80 portunda gelen istekleri karşıladığınızdan ve server_name’leri doğru yazdığınızdan emin olun.
3. Let’s Encrypt istemcisi: certbot veya acme.sh ile her domain için sertifika alın ve Nginx HTTPS vHost’larını oluşturun.

Örneğin, certbot ile Nginx eklentisini kullanıyorsanız:

certbot --nginx -d kurumsal.com -d www.kurumsal.com

Komut, Nginx yapılandırmanızı okuyarak 443 portunda yeni bir server bloğu oluşturur, sertifikayı bağlar ve 80’den 443’e yönlendirmeleri ayarlar. Çok sayıda domain için wildcard veya DNS-01 yaklaşımına geçmek istiyorsanız, Let’s Encrypt wildcard SSL otomasyonu rehberimize göz atabilirsiniz.

Güvenlik Sertleştirme: “Tek VPS, Çok Site”nin Risklerini Azaltmak

Birden fazla sitesi olan bir VPS, saldırganlar için de cazip bir hedeftir. Çünkü bir açık üzerinden içeri girildiğinde, düzgün izole edilmemiş yapılarda onlarca site birden etkilenebilir. Bizim mimarimiz bu riski azaltmak için zaten izole yapı kuruyor; ancak şu ek adımları ihmal etmeyin:

• SSH güvenliği: root login kapalı, sadece anahtar ile erişim, mümkünse farklı port.
• Güvenlik duvarı: Sadece gerekli portları (80, 443, SSH) açın.
• fail2ban: SSH ve gerekirse Nginx loglarını izleyip brute-force saldırılarını otomatik engelleyin.
• Güncellemeler: Dağıtım, Nginx, PHP, MariaDB güvenlik güncellemelerini düzenli uygulayın.

Bu başlıkta daha derin bir checklist isterseniz, VPS güvenlik sertleştirme kontrol listesi rehberimiz iyi bir başlangıç noktasıdır. WordPress tarafında da eklenti, tema ve çekirdek güncellemelerini düzenli yapmak, admin paneline ek koruma (2FA, IP kısıtlama, WAF vb.) eklemek gerekir.

WordPress’in kendisini sertleştirmek için ayrıca WordPress güvenlik sertleştirme kontrol listesi makalemizi de inceleyebilirsiniz.

Performans: Tek VPS’te Çoklu WordPress’i Nasıl Uçururuz?

Mimariyi doğru kurmak kadar, sunucu tarafı optimizasyon da kritik. Aynı VPS üzerinde birden fazla WordPress çalışırken şu adımlar ciddi fark yaratır:

Nginx Seviyesinde Önbellekleme

Her isteği PHP’ye göndermek yerine, Nginx’in mikro önbellekleme yeteneklerinden yararlanabilirsiniz. Örneğin:

• Cache süresi: 1–5 saniye (haber siteleri, yoğun yorum alan bloglar)
• Cache key: domain + URL + cihaz türü gibi parametreler

Böylece aynı saniye içinde gelen yüzlerce isteği PHP’ye değil Nginx önbelleğine çarptırmış olursunuz. Bu tekniği detaylarıyla anlattığımız Nginx mikro önbellekleme rehberine mutlaka göz atın.

PHP-FPM, OPcache ve Object Cache

PHP tarafında üç temel kaldıraç var:

• OPcache: PHP kodlarının derlenmiş halini bellekte tutar, TTFB’yi ciddi düşürür.
• PHP-FPM: Havuz başına çocuk süreç sayısını, memory limit’leri, max_requests değerlerini doğru ayarlamak gerekir.
• Object cache: Redis veya Memcached ile WordPress sorgularını hafifletmek.

Bunların hepsini WordPress bağlamında bir arada incelediğimiz sunucu tarafı WordPress optimizasyon rehberimiz, tek VPS’te çoklu site senaryosunda da size doğrudan uygulanabilir ayarlar sunar.

MySQL/MariaDB Ayarları

Bir VPS’te birden fazla WordPress sitesi için tipik bottleneck, veritabanı olur. Özellikle:

• innodb_buffer_pool_size
• query_cache (yeni sürümlerde devre dışı, bu yüzden object cache daha önemli)
• slow query log ve index eksikleri

WooCommerce veya büyük katalog siteleri barındırıyorsanız, MySQL indeksleme ve sorgu optimizasyon rehberimizi inceleyerek, veritabanı katmanında dar boğaz yaşamadan çoklu site çalıştırabilirsiniz.

Yedekleme, Güncellemeler ve Operasyonel Rutin

Tek VPS, çok site kurulumlarında asıl sınav, zaman geçtikçe başlar: Yedekler, güncellemeler, taşıma operasyonları… Temel tavsiyelerimiz:

• Site bazlı yedek: Her site için ayrı dosya + veritabanı yedekleri alın. İsterseniz /home/site1/backups/ altına periyodik tar.gz + SQL dump koyabilirsiniz.
• Harici yedek: Tüm VPS’in snapshot’ına güvenmeyin; S3 uyumlu depolama veya uzak sunucuya rsync/restic/borg ile kopya alın.
• Geri dönüş testleri: Yedeklerinizin gerçekten çalıştığını, düzenli restore testleriyle doğrulayın.

Yedek politikanızı tasarlarken sadece WordPress’i değil, tüm altyapınızı hesaba katmanız gerekiyor. Bu konuda detaylı anlattığımız 3-2-1 yedekleme stratejisi rehberimiz çok iyi bir referans noktası.

WordPress özelinde ise, eklentilere güvenmek yerine, mümkün olduğunca sunucu tarafı script’lerle (cron + wp-cli + mysqldump gibi) çalışan, şeffaf ve denetlenebilir bir yedekleme akışı kurmanızı öneriyoruz.

DCHost Üzerinde Bu Mimarinin Yaşaması

Bu kadar detaylı bir mimariyi kağıt üzerinde kurmak başka, üretim ortamında yıllarca sorunsuz yaşatmak başka. DCHost tarafında biz bu modeli özellikle şu tip müşterilerde sıklıkla uyguluyoruz:

• 10–30 arası WordPress sitesini yöneten ajanslar
• Kendi müşterilerine bakım/hizmet veren freelancer’lar
• Birkaç markayı aynı ekip altında toplayan şirketler

Genelde aşağıdaki kombinasyon iyi sonuç veriyor:

• NVMe diskli Linux VPS (CPU/RAM, en yoğun sitenize göre planlanmış)
• Ayrı kullanıcı, Nginx vHost, PHP-FPM havuzu ve veritabanı ile izolasyonlu WordPress kurulumu
• Otomatik Let’s Encrypt, günlük dosya + veritabanı yedeği, harici depolama entegrasyonu
• VPS güvenlik sertleştirme (SSH anahtar, firewall, fail2ban), WordPress sertleştirme

Eğer “Ben bu yapıyı sıfırdan kurarım ama doğru sıralamayı ve kritik ayarları bilmek istiyorum” diyorsanız, blogumuzdaki yeni VPS’te ilk 24 saat rehberi ile başlayıp, bu makaledeki mimariyi üzerine inşa edebilirsiniz.

Özet ve Yol Haritası: Nereden Başlamalısınız?

Tek VPS üzerinde birden fazla WordPress sitesi barındırmak, doğru kurgulandığında hem maliyet hem de operasyon açısından ciddi avantaj sağlar. Ancak bunun sırrı, “hepsini /var/www içine yığ” yaklaşımından çıkıp, izolasyon odaklı bir mimariye geçmektir:

• Her site için ayrı Linux kullanıcısı ve /home/siteadi yapısı
• Her domain için ayrı Nginx vHost ve log dosyaları
• Her site için ayrı PHP-FPM havuzu ve kaynak limitleri
• Her WordPress için ayrı veritabanı ve kısıtlı yetkili DB kullanıcısı
• Let’s Encrypt + SNI ile tek IP üzerinde çoklu HTTPS
• VPS + WordPress güvenlik sertleştirme ve düzenli, test edilmiş yedekler

Adım adım ilerlemek isterseniz, yol haritanız kabaca şöyle olabilir:

1. DCHost üzerinde ihtiyaçlarınıza uygun bir Linux VPS seçin.
2. VPS güvenlik sertleştirme, kullanıcı oluşturma ve temel Nginx/PHP-FPM kurulumunu yapın.
3. İlk siteyi bu yazıdaki mimariye göre ayağa kaldırın; performans ve güvenliği test edin.
4. Modeli dokümante edin ve diğer siteleri de aynı şablonla ekleyin.
5. Yedekleme ve izleme (uptime, log, kaynak kullanımı) katmanlarını ekleyin.

Eğer “Bizim elimizde 15 WordPress sitesi var, hangisini nereye taşıyalım, hangi VPS boyutu doğru olur?” gibi daha somut sorularınız varsa, DCHost ekibi olarak altyapınızı birlikte planlamaktan memnuniyet duyarız. Bir kez doğru mimariyi kurduğunuzda, yeni siteleri eklemek gerçekten birkaç komut ve küçük bir Nginx/PHP-FPM yapılandırması kadar kolay hale geliyor.