Dağınıklığa Yol Açmadan Çok Kiracılı Barındırma Kurulumu
25 Ekim 2026 tarihinde yayımlandı
Çok kiracılı bir barındırma kurulumu dışarıdan basit görünür: tek sunucu, çok sayıda müşteri ve birçok web sitesi. Zor kısım, bir müşterinin eklenti güncellemesi kaynakları tükettiğinde, bir hazırlık sitesi herkese açık hâle geldiğinde ya da bir destek talebi dağınık oturum açma bilgileri ve yarım yamalak hatırlanan ayarlar arasında arama yapmayı gerektirdiğinde başlar. İyi bir çok kiracılı barındırma, mümkün olan en fazla sayıda siteyi tek bir sunucuya sığdırmakla ilgili değildir. Önemli olan, her hesaba güvenli biçimde çalışabilmesi için yeterli yalıtım, görünürlük ve denetim olanağı sağlamaktır.
Ajanslar, serbest çalışanlar ve barındırma sağlayıcıları için bu kurulum, sunucu kapasitesini tekrarlanabilir bir hizmete dönüştürebilir. Birden fazla marka ya da projeyi yöneten küçük bir işletme içinse dağınık barındırma hesapları koleksiyonunun yerini, tek ve düzenli bir çalışma ortamı alabilir. Sonuç, yönetici için düzenli, her müşteri içinse bağımsız bir ortam sunmalıdır.
Çok Kiracılı Barındırma Kurulumu Neler Gerektirir
Çok kiracılı barındırma; birden fazla müşterinin, ekibin veya projenin aynı temel sunucu altyapısını paylaşırken ayrı barındırma ortamları kullanması anlamına gelir. Her kiracının kendine ait bir hesabı, web siteleri, alan adları, veritabanları, e-posta ayarları, dosyaları ve izinleri olmalıdır. Sunucuyu paylaşırlar ancak birbirlerinin çalışmalarına erişememelidirler.
Bu ayrım önemlidir. Tek bir yönetici hesabı altında farklı siteler için klasörler oluşturmak, doğru bir kiracı modeli değildir. Bir avuç dahili proje için işe yarayabilir, ancak farklı kişilerin erişmesi gerektiği anda riskli hâle gelir. A Müşterisi üzerinde çalışan bir geliştirici, B Müşterisinin dosyalarına göz atamamalı, veritabanı parolasını sıfırlayamamalı veya yanlışlıkla PHP ayarlarını değiştirememelidir.
İyi bir kurulum üç unsuru dengeler: yalıtım, operasyonel basitlik ve sunucu kaynaklarının verimli kullanımı. Yalıtımı aşırıya kaçırırsanız her müşteri için ayrı bir sanal sunucu gerekebilir; bu da maliyetli olabilir ve bakımı zorlaştırabilir. Birleştirmeyi aşırıya kaçırırsanız güvenliği ihlal edilmiş tek bir site veya trafik artışı herkesi etkileyebilir. Doğru yanıt, barındırdığınız müşterilerin türüne ve web sitelerinin taşıdığı risk düzeyine bağlıdır.
Sunucu Boyutuyla Değil, Kiracı Sınırlarıyla Başlayın
İşe CPU çekirdeklerini, RAM'i ve disk alanını karşılaştırarak başlamak cazip gelebilir. Bunlar önemlidir, ancak hesap sınırları öncelikli olmalıdır. Her kiracının bağımsız olarak neleri yönetebileceğine ve nelerin yönetici denetiminde kalacağına karar verin.
Çoğu durumda her kiracının ayrı bir sistem kullanıcısına, web kök dizinine, veritabanı kullanıcılarına, SSL sertifikalarına ve erişim bilgilerine ihtiyacı vardır. Sunucunun geri kalanını görmeden kendi alan adlarını ve uygulamalarını yönetebilmelidirler. Yönetici; sunucu genelindeki hizmetler, güvenlik kuralları, yazılım güncellemeleri ve kaynak politikaları üzerindeki denetimini korumalıdır.
Bu, müşteriyle çalışmayı sonlandırma sürecini de çok kolaylaştırır. Bir müşteri ayrıldığında, dosyalarını, veritabanlarını, alan adlarını ve yedeklerini içeren tek bir hesaba sahip olmak istersiniz. Gece 11'de paylaşılan bir dizin yapısını çözmek zorunda kalmamalısınız. çünkü geçişin sabaha kadar tamamlanması gerekir.
Ajanslar için müşterilerin panele doğrudan erişmesi gerekip gerekmediğini değerlendirin. Bazı müşterilerin yalnızca e-posta hesaplarına ve ara sıra WordPress'e erişmeye ihtiyacı vardır; diğerleri ise alan adlarını, veritabanlarını ve dağıtımları kendileri yönetmeyi bekler. Herkese tam erişim vermek, sağladığından daha fazla destek işi yaratabilir. Hesap rollerini olası her özelliğe göre değil, gerçek sorumluluklara göre oluşturun.
Web sitelerini, veritabanlarını ve erişim bilgilerini birbirinden ayırın
Web sitesi yalıtımı temel gerekliliktir. Her hesap, dosya sahipliği ve izinleri ayrı olacak şekilde kendi kullanıcı bağlamında çalışmalıdır. Bu, bir web sitesinde güvenlik açığı bulunan bir tema, zayıf bir parola veya kötü yazılmış bir dosya yükleme betiği varsa oluşabilecek zararı sınırlar.
Veritabanları da aynı özeni gerektirir. Tüm müşteri uygulamalarında tek bir veritabanı yöneticisi kimlik bilgisini kullanmaktan kaçının. Her kiracı için ayrı veritabanları ve veritabanı kullanıcıları oluşturun, ardından yalnızca ilgili uygulamanın ihtiyaç duyduğu ayrıcalıkları atayın. Bir WordPress sitesinin genellikle kendi veritabanı dışındaki veritabanlarında geniş yetkilere ihtiyacı yoktur.
Erişim bilgileri de aynı düzeni izlemelidir. Her hesap için ayrı SFTP veya SSH erişimi oluşturmak, denetlemeyi ve iptal etmeyi, paylaşılan sunucu erişim bilgilerine kıyasla çok daha kolaylaştırır. Yüklenicilerin erişmesi gerekiyorsa, er ya da geç birinin notlarında kalacak yönetici parolasını paylaşmak yerine geçici veya kısıtlı hesaplar oluşturun.
Kaynak Sınırlarını Planınıza Dahil Edin
Paylaşılan sunucu; CPU, bellek, depolama alanı ve disk girdi/çıktısı için ortak bir kaynak havuzudur. Sınırlar olmadan, kaynakları aşırı kullanan tek bir kiracı diğer tüm siteleri yavaşlatabilir. Bu her zaman birinin yanlış bir şey yapmasından kaynaklanmaz. Popüler bir kampanya, verimsiz bir WordPress eklentisi, bozuk bir cron işi veya büyük bir yedek aniden kaynak kullanımını artırabilir.
Platformunuz destekliyorsa hesap düzeyinde uygulanabilir sınırlar belirleyin. Disk kotalarını, posta kutusu depolama alanını, işlem sınırlarını, PHP çalışanı kapasitesini ve yedek saklama süresini göz önünde bulundurun. Normal kullanımı yansıtan planlarla başlayın ve kısa süreli yoğunluklar için pay bırakın. Çok sıkı sınırlar yanlış alarmlara ve mutsuz müşterilere yol açar. Çok gevşek sınırlar ise tek bir sorunu sunucu genelinde bir soruna dönüştürür.
Bu sınırların işe yarayıp yaramadığını izleme sayesinde anlarsınız. CPU yükünü, RAM kullanımını, disk alanını, veritabanı etkinliğini ve web sunucusu hatalarını zaman içinde izleyin. Gerçek zamanlı görünürlük özellikle yararlıdır; çünkü müşteriler nadiren “Hesabım çok fazla PHP çalışanı kullandı.” diye bildirimde bulunur. Genellikle önemli bir lansmandan hemen önce, “Sitem yavaş.” derler.
FASTPANEL gibi bir kontrol paneli; hesapları, alan adlarını, hizmetleri ve sunucu izlemeyi tek yerde toplayarak bunu uygulanabilir hâle getirebilir. Bu, iyi kapasite planlamasının yerini tutmaz; ancak temel operasyonel bilgileri birbirinden kopuk çeşitli araçlardan derleme ihtiyacını ortadan kaldırır.
Gerçekten barındırdığınız uygulamalara göre plan yapın
On tanıtım sitesi barındıran bir sunucunun ihtiyaçları, on aktif WooCommerce mağazası barındıran bir sunucununkinden çok farklıdır. E-ticaret siteleri, üyelik platformları, öğrenim sistemleri ve sık sık içe aktarma işlemleri veya zamanlanmış işleri olan siteler, sayfa sayılarından anlaşılabileceğinden çok daha fazla bellek ve veritabanı kapasitesi kullanabilir.
Bir kiracıyı paylaşılan altyapıya yerleştirmeden önce birkaç soru sorun: Site ödeme veya hassas müşteri verileri saklıyor mu? Trafikte ani artışlar bekleniyor mu? Özel kod çalıştırıyor mu? Özel bir PHP sürümüne veya arka plan çalışanlarına ihtiyaç duyuyor mu? Bu sorulardan birkaçının yanıtı evetse kiracı, ayrı bir sunucuda veya daha yalıtılmış bir planda daha iyi hizmet alabilir.
İyi tasarlandığında paylaşımlı barındırma, daha düşük nitelikli bir seçenek değildir. Birçok iş yükü için makul bir modeldir. Önemli olan, bir iş yükünün bu modeli ne zaman aştığını fark etmektir.
Güvenliği Olağan Bir Uygulama Hâline Getirin, Kahramanlık Gösterisine Değil
En iyi güvenlik süreci, ekibinizin tek bir uzmanın hafızasına bağlı kalmadan tekrarlayabileceği süreçtir. İşletim sistemini, web sunucusunu, PHP sürümlerini, veritabanlarını ve kontrol panelini güncel tutun. Kullanılmayan hesapları ve eski uygulamaları kaldırın. Güçlü parolalar, varsa çok faktörlü kimlik doğrulama ve her alan adı için SSL sertifikaları kullanın.
Yedekler de önleme kadar önemlidir. Mümkün olduğunda yedekleri ana sunucudan ayrı bir yerde saklayın. Aynı makinedeki bir yedek, dosyanın yanlışlıkla silinmesi durumunda yardımcı olabilir; ancak sunucu arızası, fidye yazılımı olayı veya sağlayıcı düzeyinde bir sorun sonrasında pek işe yaramayabilir. İhtiyaç duymadan önce yedekten geri yüklemeyi deneyin. Hiç geri yüklenmemiş bir yedek, yalnızca umut verici bir varsayımdır.
Kiracı yalıtımı için izinlere ve uygulama bakımına dikkat edin. Güvenliği ihlal edilmiş tek bir WordPress kurulumu, komşu hesaplara erişememelidir. Gereksiz hizmetleri devre dışı bırakın, yönetici erişimini kısıtlayın ve olağandışı bir durum gördüğünüzde hesap etkinliğini inceleyin. Güvenliğin dramatik bir ritüele dönüşmesi gerekmez. Olağan yönetim çalışmalarının bir parçası hâline gelmesi gerekir.
Müşteri Yönetimini Düzenli Tutun
Çok kiracılı bir ortam, rutin işler rutin kaldığında başarılı olur. Yeni bir müşteri ekleme işlemi her seferinde aynı sırayı izlemelidir: hesabı oluşturun, alan adını atayın, SSL'yi yapılandırın, veritabanını hazırlayın, siteyi dağıtın ve yedeklerle izlemenin etkin olduğunu doğrulayın. Yalnızca birkaç dakika sürse bile bu süreci kurum içinde belgelendirin. Tutarlılık, sonradan destek talebine dönüşen küçük aksaklıkları önler.
Özellikle çok sayıda markayı veya bayi müşterisini yönetiyorsanız hesapları anlaşılır biçimde adlandırın. Altı ay sonra da anlamlı olacak bir adlandırma kuralı kullanın. Özel DNS, alışılmadık cron işleri, harici e-posta sağlayıcıları veya uygulama düzeyinde önbelleğe alma gibi özel gereksinimleri not edin. Amaç, sırf evrak işi olsun diye belge hazırlamak değildir. Amaç, her hesabı baştan sona araştırmak zorunda kalmaması için sonraki kişiye, gelecekteki kendiniz de dahil, yardımcı olmaktır.
İletişim de önemlidir. Müşterilere barındırma planlarının neleri içerdiğini, yedeklerin nasıl çalıştığını, nereden destek alabileceklerini ve kaynak tahsislerini aştıklarında ne olacağını açıkça anlatın. Beklenmedik kısıtlamalar can sıkıcıdır. Müşteriler, açık sınırların sunucudaki herkesin performansını koruduğunu görebildiğinde bu sınırları kabul etmek daha kolay olur.
Sunucuyu Ne Zaman Ayırmanız Gerektiğini Bilin
Hiçbir çok kiracılı barındırma kurulumu sonsuza kadar aynı kalmaz. Müşteri tabanınız büyüdükçe orantısız risk veya talep oluşturan iş yüklerini ayırın. Yoğun trafiğe sahip bir mağaza, kaynak tüketen bir uygulama veya katı uyumluluk gereksinimleri olan bir müşteri için ayrı bir sanal sunucu gerekebilir. Bu hesabı taşımak, paylaşılan ortamı diğer herkes için daha sorunsuz hâle getirirken hesabın performansını da artırabilir.
Bir müşteri büyüdüğünde tüm platformu yeniden tasarlamanız gerekmez. Hesapları düzgünce ayırarak, kaynak kullanımını izleyerek, yedekleri test ederek ve net bir yükseltme yolu belirleyerek başlayın. Böylece ölçeklendirme, yaratıcı davranmaya başlayan bir sunucuya acil müdahale etmek yerine planlı bir adıma dönüşür.
En iyi kurulum; yeni bir müşteriyi güvenle eklemenizi, bir sonraki sorunu hızla çözmenizi ve mevcut her müşterinin web sitesinin kendine ait bir yeri olduğunu hissetmesini sağlayan kurulumdur.