Discourse ve Flarum İçin VPS Hosting Rehberi: Kaynak Planlama ve Güvenlik

Discourse ve Flarum İçin VPS Neden Doğru Zemin?

Discourse veya Flarum ile yeni bir topluluk forumu kurmayı planlıyorsanız, akla gelen ilk iki soru genelde aynıdır: “Bu iş için nasıl bir VPS almalıyım?” ve “Bu sunucuyu nasıl güvene alırım?” Forum yazılımları, klasik kurumsal sitelere göre çok daha etkileşimli çalışır; sürekli okuma-yazma yapan bir veritabanı, anlık bildirimler, arama sorguları ve zamanla büyüyen bir medya arşivi söz konusudur. Yanlış boyutlandırılmış veya güvenliği zayıf bir VPS, performans dalgalanmalarına, veri kaybına veya doğrudan güvenlik ihlallerine kadar giden sorunların kapısını aralayabilir.

Bu rehberde, DCHost ekibi olarak sahada sıkça gördüğümüz senaryolardan yola çıkarak Discourse ve Flarum forumlarınızı VPS üzerinde nasıl konumlandırmanız gerektiğini adım adım ele alacağız. CPU, RAM ve disk planlamasından başlayıp, veritabanı mimarisi, SSL/TLS, e-posta yapılandırması, güvenlik sertleştirme ve yedekleme stratejilerine kadar uzanan pratik bir yol haritası göreceksiniz. Amacımız; hem ilk forum projesini hayata geçirecek olanlara, hem de mevcut topluluğunu bir üst seviyeye taşımak isteyenlere uygulanabilir, sahada denenmiş öneriler sunmak.

Discourse ve Flarum’un Kaynak Profilleri: Temel Farklar

Önce iki yazılımı teknik açıdan doğru konumlandıralım; çünkü kapasite planlaması burada başlıyor.

Discourse’un mimarisi ve kaynak tüketimi

Discourse; Ruby on Rails tabanlı, genellikle Docker konteyner içinde kurulan, arka planda Sidekiq ile çalışan iş kuyrukları, Redis ve PostgreSQL kullanan modern bir forum yazılımıdır. Özellikleri ve kullanıcı deneyimi güçlüdür; ancak bunun karşılığında RAM ve CPU tarafında Flarum’a göre daha iştahlıdır.

• Dil ve framework: Ruby on Rails
• Veritabanı: PostgreSQL
• Önbellek/Kuyruk: Redis + Sidekiq
• Dağıtım: Çoğunlukla Docker ile tek host üzerinde

Bu yapı, özellik eklemeyi ve güncellemeleri kolaylaştırırken, özellikle RAM tarafında belirli bir taban ihtiyacı oluşturur. Küçük bir toplulukta bile 2 GB RAM altına inmemeyi, gerçekçi bir üretim ortamında ise 2–4 vCPU ve 4 GB RAM bandından başlamayı anlamlı buluyoruz.

Flarum’un mimarisi ve kaynak tüketimi

Flarum ise PHP tabanlı, MySQL/MariaDB kullanan, hafif ve modüler bir forum yazılımıdır. Discourse’a kıyasla daha düşük kaynaklarla ayağa kalkabilir, bu yüzden düşük bütçeli veya hafif trafiğe sahip topluluklar için güçlü bir alternatiftir.

• Dil ve runtime: PHP (genellikle PHP-FPM üzerinden)
• Veritabanı: MySQL/MariaDB
• Dağıtım: Nginx/Apache + PHP-FPM klasik web stack

İyi yapılandırılmış bir 1–2 vCPU ve 2 GB RAM’li VPS üzerinde, hafif–orta ölçekli bir Flarum forumu gayet akıcı çalışabilir. Ancak eklenti sayısı arttıkça, arama fonksiyonları ve gerçek zamanlı bildirimler devreye girdikçe CPU ve RAM kullanımının da buna paralel yükseldiğini unutmamak gerekiyor.

Kapasite Planlama: Kaç vCPU, Ne Kadar RAM ve Disk?

Kaynak planlarken sadece kayıtlı kullanıcı sayısına bakmak yetmez. Asıl önemli olan aynı anda çevrimiçi olan kullanıcı sayısı, sayfa görüntüleme sıklığı, eklenti yoğunluğu ve yedekleme politikalarıdır. Aşağıdaki tabloyu, DCHost üzerinde barındırdığımız gerçek forum projelerinden çıkardığımız ortalama değerler üzerine kurduk (sıkı bir optimizasyon yapıldığı varsayımıyla):

Senaryo 1: Küçük topluluk (hobi projeleri, niş gruplar)

Yeni açılan, günlük 200–500 sayfa görüntülemesi olan, 1–3 bin kayıtlı kullanıcıya ulaşmayı hedefleyen bir Flarum forumu için genellikle şu yapı yeterli olur:

• 1–2 vCPU
• 2–3 GB RAM
• 40–60 GB NVMe disk

Bu seviyede en kritik nokta RAM yönetimidir. PHP-FPM havuz ayarlarını abartmadan, MySQL’in buffer ayarlarını makul sınırlar içinde tutarak RAM’inizi bitirmemelisiniz. DCHost ortamında sıkça gördüğümüz hata, “nasılsa RAM boş” diye PHP-FPM çocuk süreç sayısını artırıp birkaç ay sonra trafik artınca OOM Killer ile süreçlerin öldürülmesi. Bu noktada RAM, swap ve OOM Killer yönetimini doğru yapmak uzun vadede sizi ciddi kesintilerden korur.

Senaryo 2: Orta ölçekli teknik topluluk

Günlük birkaç bin ziyaret, onlarca aktif tartışma ve sık kullanılan arama fonksiyonu varsa, Discourse için minimum:

• 2–3 vCPU
• 4–6 GB RAM
• 60–80 GB NVMe disk

Bu seviyede Redis ve PostgreSQL’in aynı VPS’te çalışması hâlâ kabul edilebilir; ancak disk I/O performansına hassasiyet artar. NVMe diskli DCHost VPS planlarımızda, özellikle yoğun okuma/yazma yapan forum veritabanlarında gecikme sürelerini anlamlı şekilde düşürdüğümüzü gözlemliyoruz.

Senaryo 3: Kurumsal / yoğun trafik alan forumlar

Günlük on binlerce sayfa görüntülemesi olan, sürekli çevrimiçi yüzlerce kullanıcıya sahip Discourse forumlarında artık tek VPS üzerinde çalışmak yerine uygulama ve veritabanı sunucularını ayırmayı konuşmak gerekir. Bu mimariyi veritabanı sunucusunu uygulama sunucusundan ayırmanın mantıklı olduğu durumlar başlıklı yazımızda da detaylı anlattık. Özetle:

• Uygulama VPS’i: 4–8 vCPU, 8–16 GB RAM
• Veritabanı VPS’i: 4–8 vCPU, 16–32 GB RAM, yüksek IOPS’li NVMe disk

Böylece ağır SQL sorgularının CPU ve disk kullanımını, web isteklerinden izole ederek forum deneyimini daha öngörülebilir hâle getirirsiniz. Bu eşikte, replikasyon, read-replica ve yedekli mimariler de konuşulmaya başlanabilir.

Disk, Yedekleme ve Büyüme Planı

Forumlar doğası gereği “yavaş ama sürekli” büyür. Sonradan eklenen görseller, ekler, log dosyaları ve yedekler derken, başlangıçta yeterli görünen disk alanının nasıl dolduğunu çoğu zaman fark bile etmezsiniz.

Hangi diski ne kadar planlamalı?

• Uygulama kodu: 1–2 GB civarı (Discourse Docker imajı daha büyük olabilir)
• Veritabanı: Kullanıcı sayısı ve mesaj hacmine göre; orta ölçekli forumlarda 10–30 GB
• Upload (görsel/ekler): Topluluğun kullanım alışkanlığına göre 10 GB’tan yüzlerce GB’a kadar çıkabilir
• Loglar ve geçici dosyalar: Temizleme stratejiniz yoksa gizli disk katili

Forum projelerinde, başlangıçta disk kullanımının en az 2 katını boşta bırakmak iyi bir kuraldır. Örneğin toplamda 20 GB veri tutmayı bekliyorsanız 40+ GB disk ile başlayın; büyüdükçe DCHost tarafında dikey veya yatay ölçeklemeye gidebilirsiniz.

Yedekleme stratejisi: 3-2-1 kuralını forumlara uyarlamak

Forumunuz birkaç yıl sonra kurum hafızasının önemli bir parçası hâline gelir. Bu nedenle “günlük otomatik yedek var, yeter” demek sağlıklı değildir. Bizim önerimiz, klasik 3-2-1 yedekleme stratejisini forumlara da birebir uygulamak:

• En az 3 kopya yedek (canlı sunucu dışındaki kopyalar dahil)
• En az 2 farklı depolama türü (örneğin NVMe disk + object storage)
• En az 1 kopya farklı lokasyonda (farklı veri merkezi/bölge)

Discourse için hem veritabanı dump’ı hem de upload dizinini; Flarum için ise veritabanı, yapılandırma dosyaları ve public/upload dizinlerini düzenli olarak yedekleyip zaman zaman geri yükleme testi yapmak kritik. Yedeklerin sadece var olması yetmez; geri dönülebildiğini periyodik olarak doğrulamak gerekir.

VPS Mimarisi: Tek Sunucu mu Ayrı Veritabanı Sunucusu mu?

Başlangıç için tüm bileşenlerin (web sunucusu, uygulama, veritabanı, Redis) tek bir DCHost VPS üzerinde çalışması makul ve ekonomiktir. Ancak büyüme işaretleri belirginleştiğinde mimariyi gözden geçirmek gerekir.

Ne zaman tek VPS yeterli?

• Günlük sayfa görüntülemesi 10–15 binin altındaysa
• Aynı anda çevrimiçi kullanıcı sayısı 100–150 civarındaysa
• CPU kullanımı piklerde bile %70–80’i kısa süreliğine geçiyorsa
• Disk I/O bekleme süreleri düşük ve htop/iotop çıktıları sakin görünüyorsa

Bu durumda iyi yapılandırılmış bir tek VPS, hem maliyet hem de operasyonel basitlik açısından idealdir.

Ne zaman veritabanını ayırmalı?

Şu sinyalleri görmeye başladıysanız veritabanını ayrı bir DCHost VPS’e taşımayı ciddi ciddi düşünme zamanı gelmiş demektir:

• CPU’nun önemli kısmını PostgreSQL veya MySQL süreçleri tüketiyor
• Disk I/O bekleme süreleri artıyor, forum zaman zaman “takılıyormuş” hissi veriyor
• Haftalık raporlar veya toplu bakım görevleri sırasında forum hissedilir derecede yavaşlıyor
• Replikasyon, read-replica veya ileri seviye yedekleme/toparlama (PITR gibi) planları konuşulmaya başlandı

Bu geçişi yaparken, uygulama VPS’i ile veritabanı VPS’i arasında düşük gecikmeli, güvenli bir ağ yapılandırması (VPN tüneli, private network vb.) kurgulamak gerekir. DCHost tarafında bu tür senaryolara uygun VLAN ve ağ izolasyonu çözümleriyle forum altyapınızı büyütmenize yardımcı olabiliyoruz.

Güvenlik: Discourse ve Flarum İçin VPS Sertleştirme

Forumlar saldırganlar için cazip hedeflerdir; çünkü kullanıcı verisi, oturum çerezleri ve çoğunlukla e-posta adresleri içerirler. Dolayısıyla sadece uygulamayı kurup bırakmak yerine, VPS seviyesinde sistematik bir güvenlik sertleştirme süreci uygulamak şart.

Temel VPS güvenlik adımları

• Güncellemeler: İşletim sistemi ve paketleri düzenli güncelleyin; otomatik güvenlik güncellemeleri kurmayı düşünün.
• SSH sertleştirme: Şifreli girişleri kapatıp SSH anahtar doğrulamasına geçin, root ile doğrudan girişe izin vermeyin, ihtiyaca göre SSH portunu değiştirin.
• Güvenlik duvarı: Sadece gerekli portları (örneğin 80/443, SSH) açın; ufw, firewalld veya nftables ile sade ama net bir kural seti tanımlayın.
• Fail2ban / benzeri araçlar: SSH brute-force ve web tabanlı saldırı denemelerini sınırlamak için IP tabanlı yasaklama kuralları uygulayın.
• Yetki yönetimi: Ayrı kullanıcılar, sudo yetkileri ve log takibi ile tek kullanıcıya bağlı riskleri azaltın.

Bu başlıkları daha derinlemesine ele aldığımız VPS güvenlik sertleştirme kontrol listemizde anlattığımız adımları forum sunucularınıza da birebir uygulayabilirsiniz.

Uygulama seviyesi güvenlik

• Güncel sürüm: Discourse ve Flarum’u, güvenlik yamaları yayınlandıkça güncel tutun.
• Eklentiler: Sadece güvenilir geliştiricilerden, aktif olarak güncellenen eklentileri kullanın.
• Yönetici hesapları: Güçlü parolalar ve mümkünse 2FA kullanın; gereksiz admin/moderator hesabı bırakmayın.
• Yedek erişimi: Alınan yedekleri aynı sunucuda, herkese açık dizinlerde tutmayın; şifreli ve izole bir ortamda saklayın.

SSL/TLS, HTTPS ve Güvenlik Başlıkları

Modern bir forumun HTTPS olmadan yayına çıkması artık düşünülemez; hem güvenlik hem de SEO açısından bu bir zorunluluk. DCHost üzerinde barındırdığınız Discourse ve Flarum projeleri için Let’s Encrypt tabanlı otomatik SSL kurulumlarıyla süreci oldukça basitleştiriyoruz.

Temel HTTPS mimarisi

• Forum alan adınız için A/AAAA kayıtlarını VPS IP’nize yönlendirin.
• Nginx/Apache üzerinde HTTP’den HTTPS’e 301 yönlendirmesi yapın.
• Let’s Encrypt veya ticari bir SSL sertifikasıyla 443 portunu güvenceye alın.
• HSTS, modern şifre paketleri ve HTTP/2/HTTP/3 desteğini etkinleştirin.

HSTS, CSP ve diğer HTTP güvenlik başlıklarını nasıl doğru kuracağınızı, hem forumlar hem de diğer web uygulamaları için genel geçer olan HTTP güvenlik başlıkları rehberimizde detaylı olarak anlattık. Forumlarınızda da aynı prensipleri uygulayarak XSS, clickjacking gibi birçok saldırı vektörünü ciddi oranda daraltabilirsiniz.

E-posta Bildirimleri, SPF/DKIM/DMARC ve Teslim Edilebilirlik

Discourse ve Flarum kullanıcı etkileşiminin önemli bir kısmı e-posta bildirimleri üzerinden gerçekleşir: yeni yanıtlar, mention’lar, şifre sıfırlama linkleri, özet e-postalar vb. Bu bildirimler spam klasörüne düşerse, kullanıcılar forumun “sessizleştiğini” düşünür ve etkileşim hızı düşer.

Forum sunucusundan e-posta çıkışı

Forumunuzu e-posta gönderecek şekilde yapılandırırken şu adımları atlamayın:

• Forum alan adınız için SPF kaydı tanımlayın.
• Gönderici sunucunuz için DKIM imzası oluşturun ve DNS’e ekleyin.
• En azından DMARC p=none politikası ile raporlama ve görünürlük sağlayın.
• VPS IP’niz için doğru bir PTR (reverse DNS) kaydı tanımlayın.

Tüm bu adımları, forum bildirimleriniz de dahil olmak üzere e-posta teslim edilebilirliğini artırmak için hazırladığımız SPF, DKIM, DMARC ve rDNS ile e-posta teslim edilebilirliğini adım adım yükseltme rehberimizde daha teknik detaylarıyla bulabilirsiniz. Forumlar için de birebir geçerli aynı prensiplerdir.

İzleme, Loglama ve Performans İyileştirme

Sağlam bir VPS ve iyi yapılandırılmış bir forum kadar önemli bir diğer başlık da görünürlüktür: Sunucunuz ne durumda, dar boğaz nerede, ne zaman ölçeklemeniz gerekiyor? Bunları hissiyatla değil, metriklerle karar vermek gerekir.

Temel metrikler

• CPU kullanımı: Sürekli yüksekse vCPU sayısı veya sorgu/uygulama optimizasyonu gündeme gelir.
• RAM kullanımı: Disk swap kullanımı artıyorsa PHP-FPM, PostgreSQL/MySQL veya Redis ayarları yeniden gözden geçirilmelidir.
• Disk I/O: Veritabanı veya upload işlemlerinde kuyruklar oluşuyorsa NVMe diske geçiş veya veritabanının ayrılması düşünülmelidir.
• Ağ trafiği ve gecikme: Ani trafik artışları veya DDoS benzeri durumları tespit etmek için düzenli izleme gerekir.

Prometheus, Grafana, Netdata gibi araçlarla VPS izleme ve alarm kurulumunu yapılandırdığınızda, forumunuzun sağlığını tek panelden takip edebilir, kritik eşiklerde otomatik bildirimler alabilirsiniz. Ayrıca web sunucusu ve uygulama loglarını düzenli analiz ederek, yavaş sorguları ve sık 4xx/5xx hatası üreten endpoint’leri de ortaya çıkarabilirsiniz.

DCHost ile Discourse ve Flarum Forumlarınızı Güvenle Büyütün

Forum projeleri, ilk günkü heyecan geçtikten sonra bile uzun yıllar yaşayan, kurum kültürünün ve topluluk hafızasının önemli bir parçasına dönüşür. Bu yolculukta sizi yarı yolda bırakmayacak, büyürken esneyebilen ve güvenlik tarafında arkanızda duran bir VPS altyapısına ihtiyacınız var.

DCHost olarak, Discourse ve Flarum gibi kaynak duyarlı uygulamalar için optimize edilmiş VPS altyapımızla; NVMe disk performansı, modern sanallaştırma teknolojileri ve Türkiye/Avrupa lokasyonlu veri merkezlerimiz üzerinden düşük gecikme süreleri sunuyoruz. İhtiyacınız olduğunda, tek VPS’ten ayrı veritabanı sunucularına, hatta çok bölgeli mimarilere geçişte hem kapasite planlama hem de güvenlik sertleştirme tarafında yanınızdayız. İlk topluluk forumunuzu açmayı düşünüyorsanız veya mevcut forumunuzu daha güçlü bir DCHost VPS’e taşımak istiyorsanız, ihtiyaçlarınıza en uygun mimariyi birlikte tasarlayalım.

Doğru kaynak planlama, sağlam bir güvenlik temeli ve düzenli yedekleme ile Discourse ve Flarum forumlarınızı yıllarca sorunsuz çalıştırmak mümkün. Bu rehberdeki adımları kendi projenize uyarlayın, ihtiyaç duyduğunuz noktada DCHost ekibiyle iletişime geçin; gerisini birlikte çözeriz.