Odoo ve ERPNext İçin Doğru VPS Hosting Neden Bu Kadar Önemli?
Odoo, ERPNext ve benzeri CRM/ERP uygulamaları bir web sitesi gibi sadece sayfa sunmaz; satış, stok, muhasebe, üretim ve insan kaynakları süreçlerinizi kullanılan modüllere göre destekler. Yani bu sistemler yavaşladığında ya da erişilemez olduğunda, aslında şirketin operasyonu da yavaşlar. Bu yüzden bu uygulamaları nerede ve nasıl host ettiğiniz, yazılım seçimi kadar stratejik bir karardır.
Birçok işletme Odoo veya ERPNext’i ilk kurarken “paylaşımlı hosting yeter mi, yoksa VPS mi almalıyım, dedicated sunucuya ne zaman geçmeliyim?” sorularında takılıyor. 5–10 kullanıcılı küçük kurulumlarda bile kaynak ihtiyacı, kullanılan modüllere ve işlem yoğunluğuna bağlıdır; yetersiz CPU ve RAM performans sorunlarına yol açabilir. Öte yandan, baştan aşırı büyük sunucuya çıkmak da gereksiz maliyet demek.
Bu rehberde, bir VPS üzerinde Odoo, ERPNext ve diğer CRM/ERP uygulamalarını çalıştırırken hangi VPS özelliklerine ihtiyaç duyduğunuzu, hangi mimarinin hangi ölçek için uygun olduğunu ve güvenlik, yedekleme, izleme tarafında neleri mutlaka yapmanız gerektiğini, örnek kullanım senaryolarıyla adım adım anlatacağız.
CRM/ERP Uygulamaları İçin Neden VPS Tercih Etmelisiniz?
Odoo ve ERPNext gibi uygulamalar, kullanılan modüllere ve işlem hacmine bağlı olarak yoğun veritabanı ve arka plan işlem yükü oluşturabilir. Paylaşımlı hosting’deki CPU, RAM, I/O ve servis çalıştırma kısıtları bu uygulamalar için engel olabilir. VPS hosting, gerekli servisleri yönetmek ve kaynakları ihtiyaca göre planlamak için bir seçenektir.
VPS’inizi seçerken temel avantajlar şunlardır:
- Kaynak izolasyonu: VPS, ayrı bir çalışma ortamı sağlar; bu, fiziksel CPU ve disk altyapısının size özel olduğu anlamına gelmez. Paylaşımlı kaynaklardaki yoğunluğun etkisi, kaynak tahsisine ve sağlayıcının uyguladığı sınırlara bağlıdır.
- Tam kontrol: Root erişimi sunan ve yönetim koşulları buna izin veren bir planda, işletim sistemi, veritabanı sürümü, Python/NodeJS sürümleri ve uygulamanın gerektirdiği ek servisleri (Redis, Celery, wkhtmltopdf vb.) yönetebilirsiniz.
- Ölçeklenebilirlik: Planın yükseltme seçenekleri izin veriyorsa kullanıcı sayınız arttıkça vCPU, RAM ve disk kapasitesini kademeli olarak büyütebilirsiniz.
- Güvenlik ve uyumluluk: Erişim, yedekleme ve veri konumunu daha ayrıntılı yönetebilirsiniz. VPS kullanımı tek başına KVKK/GDPR veya sektör uyumluluğu sağlamaz; veri işleme, sözleşme, erişim ve saklama yükümlülüklerini ayrıca değerlendirin.
VPS’in ne olduğunu ve küçük işletmeler için ne tür avantajlar sunduğunu daha temelden görmek isterseniz, VPS hosting nedir ve küçük işletmeler için avantajları yazımıza da göz atabilirsiniz.
Odoo ve ERPNext İçin Kaynak Planlama: CPU, RAM, Disk ve Trafik
ERP kurulumlarında rastgele bir VPS paketi seçmek yerine eş zamanlı kullanıcıları, modülleri ve veri büyümesini birlikte değerlendirin. Aşağıdaki rakamlar ölçülmüş sonuçlar veya resmi minimumlar değil, kapasite denemeleri için örnek başlangıç değerleridir; gerçek iş yüküyle doğrulanmalıdır.
Tipik Kullanım Senaryoları
- Senaryo 1 – Küçük ekip (5–10 kullanıcı): Temel CRM, satış, stok; eş zamanlı 3–4 kullanıcı aktif. Denenecek örnek kaynaklar: 2 vCPU, 4–8 GB RAM, NVMe SSD üzerinde 80–100 GB disk.
- Senaryo 2 – Orta ölçek (20–40 kullanıcı): CRM + muhasebe + satın alma + üretim modülleri, eş zamanlı 15–20 kullanıcı. Denenecek örnek kaynaklar: 4 vCPU, 8–16 GB RAM, NVMe SSD’de 150–250 GB disk.
- Senaryo 3 – Yoğun kullanım (50+ kullanıcı): Birden fazla lokasyon, raporlama ve yoğun stok hareketi. Denenecek örnek kaynaklar: 8 vCPU, 16–32 GB RAM, NVMe SSD’de 300+ GB disk; veritabanını ayrı bir VPS veya dedicated sunucuya alma planıyla.
Benzer bir kapasite planlama mantığını, farklı iş yükleri için anlattığımız CPU, RAM, NVMe ve bant genişliği rehberimizde daha ayrıntılı olarak görebilirsiniz; aynı yaklaşım ERP dünyasında da geçerli.
CPU (vCPU) Seçimi
Odoo ve ERPNext gibi Python tabanlı ERP çözümleri, özellikle raporlama, toplu fatura kesimi ve toplu stok güncellemelerinde CPU’ya yüklenir. Dikkat etmeniz gerekenler:
- 2 vCPU ile başlangıç denemesi: Tek vCPU’da arka plan görevleri (cron) ve web istekleri aynı anda çalışırken CPU darboğazı oluşabilir; ihtiyaç işlem yoğunluğuna bağlıdır.
- Eş zamanlı yükü ölçün: Kullanıcı başına sabit bir vCPU oranı yoktur. Örneğin 20 aktif kullanıcı için 4–6 vCPU’yu deneme aralığı olarak alıp yanıt süreleri, CPU kullanımı ve iş kuyruklarıyla değerlendirebilirsiniz.
- Raporlama ve BI yükü: Çok ağır raporlar ve pivot analizleri için, üretim veritabanınızın bir replikası üzerinde ayrı bir raporlama sunucusu planlamak mantıklı olabilir.
Raporlama replikası kullanılırsa gecikme nedeniyle yeni işlemler hemen görünmeyebilir. Raporun tutarlılık ihtiyacını, izinleri ve üretime geri yazmayı engelleyen erişimi doğrulayın; replika bağımsız yedek değildir.
RAM Planlaması
RAM, özellikle PostgreSQL/MariaDB veritabanı ve Odoo/ERPNext uygulama süreçleri için kritiktir. Yetersiz RAM, swap etkinse yoğun swap kullanımına ve yavaşlamaya; bellek tükenirse süreçlerin sonlanmasına yol açabilir.
- Başlangıç değerlendirmesi: 2 GB RAM’i demo/PoC için dahi ölçümle değerlendirin; küçük üretim senaryosunda 4 GB bir deneme başlangıcı olabilir, yeterlilik garantisi değildir.
- Veritabanı + uygulama: Aynı VPS üzerinde hem Odoo/ERPNext hem de veritabanı çalışıyorsa, 8 GB ve üzerini değerlendirin; ihtiyacı süreç sayısı ve veritabanı yüküyle ölçün.
- Arka plan iş yükleri: E-posta gönderimleri, entegrasyon script’leri ve planlanmış görevler için de RAM payı bırakın; örneğin +1–2 GB payın yeterliliğini eş zamanlı görevlerle ölçün.
Disk Türü, Kapasite ve IOPS
ERP sistemlerinde disk sadece kapasite değil, IOPS (saniyede okuma/yazma işlemi) açısından da önemlidir. Yavaş diskler, özellikle stok hareketleri ve muhasebe kayıtlarında ciddi yavaşlık yaratabilir.
- NVMe SSD tercih edin: Klasik HDD yerine NVMe SSD’yi değerlendirin; seçilen plandaki IOPS ve aktarım hızı sınırlarını da karşılaştırın.
- Kapasite hesabı: Uygulama dosyaları + veritabanı + ek dosyalar (rapor PDF’leri, ekler, belge taramaları) için 2–3 yıllık büyümeyi hesaplayın. Örneğin yıllık 20–30 GB artış, üç yılda 60–90 GB ek kapasite gerektirir; buna başlangıç verisini, logları, geçici dosyaları ve boş alan payını ekleyin.
- IOPS ihtiyacı: Yoğun yazma yükü olan üretim/muhasebe sistemlerinde, yüksek IOPS disk darboğazı varsa performansı iyileştirebilir; NVMe etiketi tek başına uygulama performansı garantisi değildir.
Ağ ve Bant Genişliği
Ağ ihtiyacını yalnızca kullanıcı sayısından çıkarmayın. Büyük ekler, şubeler arası erişim, toplu API işlemleri ve yedek aktarımı bant genişliği kullanır; kullanıcı ile uygulama ve uygulama ile veritabanı arasındaki gecikme de önemlidir.
- Uzaktan çalışan çok sayıda kullanıcı varsa (VPN üzerinden), yeterli upload/download kapasitesi planlayın.
- Harici entegrasyonlar (e-fatura, e-arşiv, e-irsaliye, API tüketen entegrasyonlar) için de istek sıklığına, aktarılan veri boyutuna ve eş zamanlı aktarımlara göre bant genişliği planlayın.
Daha detaylı trafik ve bant genişliği hesabı için, paylaşımlı hosting ve VPS için bant genişliği ihtiyacı hesaplama rehberimizde yer alan prensipleri ERP senaryolarına da uyarlayabilirsiniz.
Mimari Seçenekleri: Tek VPS mi, Çoklu VPS mi, Dedicated mi?
Doğru mimariyi seçmek, sadece bugünkü kullanıcı sayınıza değil, önümüzdeki 2–3 yıldaki büyüme hızınıza da bağlı. Değerlendirilebilecek üç temel yaklaşım var.
1) Tek VPS Üzerinde Tüm Bileşenler (Uygulama + Veritabanı)
Kimler için uygun? Örneğin 5–20 aktif kullanıcılı, hızlı başlamak isteyen küçük ekipler ve tek lokasyonlu şirketler için değerlendirilebilir; uygunluk işlem yüküne bağlıdır.
- Avantajlar: Basit kurulum, tek sunucu yönetimi, düşük başlangıç maliyeti.
- Dezavantajlar: Büyüdükçe veritabanı ve uygulama aynı kaynakları tükettiği için performans sıkışabilir. Tek VPS ayrıca ortak arıza ve bakım noktasıdır; kabul edilebilir kesinti ve geri yükleme süresiyle değerlendirin.
Denenecek örnek kaynaklar: 4 vCPU, 8 GB RAM, NVMe SSD 150–200 GB. Büyüme sırasında CPU darboğazı ölçülürse 6–8 vCPU değerlendirilebilir.
2) Uygulama ve Veritabanının Ayrı VPS’lerde Koşması
Kimler için uygun? Örneğin 20+ aktif kullanıcılı, yoğun raporlama yapan veya büyüme öngören işletmelerde değerlendirilebilir. Geçiş kararı kullanıcı eşiğine değil, ölçülen kaynak rekabetine ve yönetim ihtiyacına dayanmalıdır.
- 1 adet VPS: Odoo/ERPNext uygulaması (web + worker’lar)
- 1 adet VPS: Seçilen uygulama ve sürümün desteklediği veritabanı sunucusu; PostgreSQL, MariaDB veya MySQL her iki uygulama için birbirinin yerine kullanılabilir seçenekler olarak alınmamalıdır.
Avantajları:
- Uygulama ve veritabanı kaynaklarını ayrı ayrı ölçekleyebilirsiniz.
- Veritabanı sunucusuna ek disk, RAM ve yedekleme stratejisi tanımlamak kolaylaşır.
- Güvenlik açısından veritabanı sunucusunu sadece uygulama VPS’inden erişilebilir hale getirerek saldırı yüzeyini küçültürsünüz.
Ayrı veritabanı yeni bir ağ bağımlılığı getirir. Gecikmeyi ölçün; yalnızca yetkili uygulama/yönetim kaynaklarına özel ağ veya VPN erişimi verin ve gereken durumda sertifika doğrulamalı veritabanı TLS’ini kullanın. İki VPS bulunması otomatik failover veya yüksek erişilebilirlik sağlamaz.
3) Dedicated Sunucu + VPS Kombinasyonları
Kimler için değerlendirilebilir? Örneğin 50+ aktif kullanıcıyla yüksek işlem hacmi, sık raporlama ve yoğun entegrasyon yükü olan ekipler; karar yalnızca kullanıcı sayısına değil, ölçülen kaynak ihtiyacına dayanmalıdır.
- Dedicated sunucu üzerinde veritabanı (yüksek RAM, güçlü disk altyapısı)
- 1 veya daha fazla VPS üzerinde Odoo/ERPNext uygulama katmanı
Bu mimari, büyüyen SaaS girişimleri veya birden fazla şirketi tek Odoo/ERPNext altyapısında çalıştıran gruplar için değerlendirilebilir; tek başına yüksek erişilebilirlik sağlamaz. Dedicated sunucu ve colocation ile kendi fiziksel sunucunuzu barındırma senaryoları da ağ bağlantısı, gecikme ve işletim sorumlulukları planlanarak aynı mimaride birleştirilebilir.
Küçük SaaS uygulamaları için tek VPS, çoklu VPS ve yönetilen bulut mimarilerini karşılaştırdığımız detaylı mimari rehberimiz, ERP projelerinde de düşünce sisteminizi netleştirmenize yardımcı olacaktır.
Kurulum Stratejileri
Linux Dağıtımı Seçimi
Dağıtımı, seçtiğiniz ERP ve kurulum yönteminin sürüm gereksinimlerine göre seçin. Güncel Frappe kurulum belgesi resmî desteklediği sistemler arasında Debian/Ubuntu’yu sayar; bu, her eski ve yeni dağıtım sürümünün her ERPNext sürümüyle uyumlu olduğu anlamına gelmez.
- Ubuntu/Debian: Ubuntu/Debian için verilen kurulum adımlarını kullanırken hedef uygulama ve dağıtım sürümünü eşleştirin; paket adlarının ve komutların sürümler arasında bire bir uyumlu olduğunu varsaymayın.
- AlmaLinux/Rocky Linux: RHEL uyumlu genel seçeneklerdir. Ekip deneyimi bulunsa bile hedef ERP sürümü, bağımlılıkları ve desteklenen kurulum yolunu ayrıca doğrulayın; bu liste ERPNext için resmî dağıtım desteği listesi değildir.
Bu konuda kararsızsanız, VPS için Linux dağıtımı seçimi rehberimizde, Ubuntu, Debian, AlmaLinux ve Rocky Linux’u artılarıyla birlikte detaylı karşılaştırdık.
Tek Tenant mı, Çok Tenant mı?
Odoo tarafında özellikle iki yaklaşım var:
- Tek müşteri (single-tenant): Örneğin tek firma için ayrılmış kurulum ve veritabanı.
- Birden fazla müşteri (multi-tenant): Örneğin aynı Odoo kurulumunda farklı müşterileri ayrı veritabanlarında barındırma. Tenant ayrımı, şirket sayısından ziyade müşteri ve erişim sınırlarıyla ilgilidir.
Aynı uygulama ortamını paylaşmak işletim maliyetini azaltabilir; toplam avantaj iş yüküne ve yönetim ihtiyacına bağlıdır. Ayrı veritabanları, ortak uygulama hesabı veya yanlış yönlendirme karşısında tek başına müşteri izolasyonu sağlamaz. Her müşteri için kaynak ve erişim sınırlarını değerlendirin:
- Bağımsız kaynak veya erişim sınırı gereken müşteriler için ayrı VPS + ayrı veritabanı (uygulama ve veritabanı ortamlarını ayırmak için)
- Paylaşımlı uygulama risklerinin kabul edildiği küçük müşteriler için ortak Odoo kurulumunda birden fazla veritabanı
Odoo’da alan adı ile veritabanı eşlemesini ve veritabanı seçimi kısıtlarını yapılandırın; farklı bir müşteriyle giriş, doğrudan URL, ek dosya ve yedek erişimini sınayın. Üretim müşterilerini test ortamlarıyla aynı güven sınırında tutmayın.
Docker mı, Klasik Kurulum mu?
Hedef sürümün desteklediği bir konteyner dağıtımı veya işletim sistemine doğrudan kurulum değerlendirilebilir. Seçim, ekibin güncelleme, kalıcı veri ve arıza inceleme süreçlerine uyum sağlamalıdır.
- Klasik kurulum (VPS işletim sistemine doğrudan kurulum): Konteyner ağ/depolama katmanı eklemez; servis, bağımlılık ve yedek yönetiminin belgelenmesi yine gerekir.
- Docker ile kurulum: Sabitlenmiş imajlarla sürüm dağıtımı ve staging süreçlerini tekrarlanabilir kılabilir. Kalıcı dosyalar, sırlar, ağ erişimi ve yedekler ayrıca yönetilir. İmajı geri almak, uygulanmış veritabanı şema değişikliğini geri almaz.
Docker ile çalışan ekipler için, VPS üzerinde konteyner tabanlı üretim mimarilerini anlattığımız konteynerize WordPress üretim mimarisi yazımızdaki reverse proxy, SSL sonlandırma, kalıcı depolama, yedekleme ve loglama gibi tasarım başlıkları burada da önemlidir; uygulamaya özgü servisler ve veri tutarlılığı gereksinimleri için yapılandırmalar ayrıca uyarlanmalıdır.
Kontrol Paneli Kullanımı
cPanel, Plesk veya DirectAdmin gibi kontrol panelleri WordPress ve PHP siteleri gibi klasik web uygulamalarını yönetmek için kullanılabilir. ERP’nin servislerini destekleyip desteklemediklerini kontrol edin. Odoo/ERPNext işletiminde şu bileşenlerin yönetimi de gerekir:
- Doğrudan SSH ile yönetim,
- Systemd servisleri,
- Nginx/Apache reverse proxy yapılandırmaları,
- Ve veritabanının CLI üzerinden yönetimi
Bu bileşenleri SSH ve belgelenmiş servis yapılandırmalarıyla yönetebilirsiniz. E-posta, ek web siteleri ve alt alan adları için panel de kullanılacaksa panelin proxy/port, paket ve güncelleme değişiklikleriyle ERP’nin ayarlarının çakışmadığını sınayın. Uygulama servislerini kimin yöneteceğini açıkça belirleyin.
Güvenlik, Yedekleme ve İzleme
ERP sunucuları, içerdiği verinin kritikliği nedeniyle saldırganlar açısından da cazip hedeflerdir. Birkaç temel güvenlik, yedekleme ve izleme adımını standart hale getirmek, bu riskleri azaltmaya yardımcı olur.
VPS Güvenlik Temelleri
Yeni bir VPS aldığınızda ilk 24 saatte yapmanız gerekenler çoğu ortamda benzerdir: sistem güncellemeleri, temel güvenlik duvarı (firewall) kuralları, kullanıcı hesaplarının düzenlenmesi. Bu adımları yeni VPS’te ilk 24 saat rehberimizde adım adım anlattık; ERP’deki uygulama servisleri, dış entegrasyonlar ve bakım penceresine göre bu adımları uyarlayın.
Buna ek olarak:
- Parola yerine SSH anahtarları ile giriş yapın; SSH portunu değiştirmek erişim kontrolünün yerini tutmaz. Parolalı veya doğrudan root girişini kapatmadan önce ayrı bir oturumda anahtarla giriş ve sudo yetkisini doğrulayın; mevcut oturumu açık tutun.
- Güçlü bir güvenlik duvarı (nftables, ufw vb.) ile sadece gerekli portları dış dünyaya açın; web erişimi için 80/443, SSH için yapılandırdığınız portu yalnızca yetkili kaynaklara izin verecek şekilde değerlendirin.
- Veritabanı portlarını (PostgreSQL: 5432, MySQL/MariaDB: 3306) yalnızca gerekli uygulama ve yönetim kaynaklarından erişilebilir hale getirin.
- ERP yönetim paneli erişimlerini IP kısıtlamaları, VPN veya ek HTTP kimlik doğrulaması ile sınırlandırın.
- Docker kullanıyorsanız yayımlanan konteyner portlarını ayrıca denetleyin; bu portlar ufw/firewalld ile beklediğiniz filtrelemeyi aşabilir.
Uygulama hesabının yetkisini sınırlayın; müşteri/parola/token/ödeme verisini loglara taşımayın. ERP panelinde ve gerekiyorsa harici API/webhook yollarında hangi kaynakların yetkili olduğunu ayrı tanımlayın; erişim kısıtlaması eklerken gerekli entegrasyonları da test edin.
VPS güvenliğini daha derinlemesine ele aldığımız VPS sunucu güvenliği rehberi, ERP sunucularınız için de uygulayabileceğiniz kapsamlı bir kontrol listesi sunuyor.
Yedekleme Stratejisi: RPO/RTO’yu Netleştirin
ERP tarafında yedekleme planının temel hedefleri, tolere edilebilir veri kaybının zaman karşılığı (RPO) ve kesinti sonrası hizmete dönüş için hedeflenen süre (RTO) olmalıdır.
- Veritabanı yedekleme sıklığı: Tam yedekleri ve aradaki değişikliklerin korunmasını RPO hedefine göre planlayın; artımlı yedekleme yöntemi seçilen veritabanı ve yedekleme aracının desteğine bağlıdır.
- Dosya sistemi yedeği: Odoo/ERPNext konfigürasyonları, ek dosyalar ve modüller; dosyalar ile veritabanının tutarlı bir geri yükleme noktasına sahip olmasını sağlayın.
- Uzak lokasyona yedek: Aynı fiziksel sunucuda veya aynı veri merkezinde tek kopya yedek, felaket senaryolarında yeterli olmayabilir. Veri merkezi kaybına karşı farklı bir veri merkezinde bağımsız yedek kopyası tutun; aynı merkezde farklı fiziksel havuz bu riski karşılamaz. Geri yükleme denemeleriyle veri tutarlılığını ve RTO hedefini doğrulayın.
Veritabanı yedeklerine özellikle önem verin. MySQL için mysqldump, XtraBackup ve snapshot karşılaştırmasını yaptığımız rehberde anlattığımız araçların adlarını ERPNext/MariaDB’ye veya PostgreSQL’e doğrudan uygulamayın. Seçilen motor ve sürümün desteklediği yedekleme aracını kullanın; MySQL, MariaDB ve PostgreSQL araçlarının motor/sürüm uyumu doğrulanmadan birbirinin yerine kullanılabildiği varsayılmamalıdır.
Odoo’da veritabanıyla filestore’u, ERPNext’te veritabanıyla public/private dosyaları, gerekli site yapılandırmasını ve korunan anahtarları birlikte kurtarabilmelisiniz. Bench’in varsayılan backup işlemi yalnız veritabanı dökümü üretir; dosyalar için desteklenen dosya-yedekleme seçeneğini ayrıca seçin. Yedek setini uzak konuma kopyalayın; erişimini ve silme yetkisini üretim hesabından ayırın.
Loglama ve İzlenebilirlik
ERP performans problemlerini incelemek için düzenli loglama ve izlemeyi birlikte kullanın. Sadece CPU ve RAM grafiği yeterli olmaz; hangi modülün, hangi sorgunun sistemi yorduğunu da görmek istersiniz.
- Uygulama logları (Odoo/ERPNext),
- Veritabanı slow query logları,
- Nginx/Apache erişim ve hata logları
Bu kayıtları tek noktada toplamak çoklu ERP sunucularında incelemeyi kolaylaştırır. VPS’te merkezi log yönetimi rehberini değerlendirirken kullanılan istemcinin yaşam döngüsünü de dikkate alın. Promtail 2 Mart 2026’da yaşam sonuna ulaştı ve artık destek/güncelleme almıyor; yeni Loki toplamasında Grafana Alloy gibi desteklenen bir istemci kullanın. Eski Promtail örneklerini yeni servis kurulum talimatı olarak uygulamayın. Grafana panosu, kayıtların toplandığını veya bildirimin ulaştığını tek başına kanıtlamaz.
Birden fazla sunucunuz varsa, birden fazla sunucuda ELK/Loki Stack ile merkezi loglama rehberimizde anlattığımız yaklaşım, ERP’deki log biçimi, kişisel veri, erişim ve saklama gereksinimlerine göre uyarlanmalıdır.
CPU/RAM/IO ve kuyruk metriklerini loglardan ayrı toplayın. Örnek uygulama hatası ve başarısız yedekle alarmın tetiklenmesini, bildirim alıcısını ve iyileşmesini sınayın; hiç veri gelmemesi ile sıfır hata aynı şey değildir.
Odoo/ERPNext İçin Varsayımsal Mimari Senaryolar
Senaryo 1: Büyüyen KOBİ (10–20 Kullanıcı)
Durum: Tek ofis veya birkaç şube, temel modüller (CRM, satış, stok, fatura), ara sıra raporlar.
- Başlangıç kapasitesi adayı: 1 adet NVMe VPS (4 vCPU, 8 GB RAM, 150–200 GB NVMe SSD); gerçek iş yüküyle doğrulanmalıdır.
- Odoo + PostgreSQL veya ERPNext + MariaDB aynı VPS üzerinde. ERPNext örneği, resmi Helm dağıtım belgesindeki MariaDB yolunu esas alır; MariaDB ile MySQL’i birbirinin yerine kullanmayın. Kurulumdan önce seçilen ERPNext/Frappe sürümlerinin veritabanı gereksinimlerini eşleştirin: Kasım 2026’da kontrol edilen güncel Frappe kurulum belgesi v14/v15 için MariaDB 10.6.6+, v16/develop için MariaDB 11.8 belirtir. ERPNext develop dalına Haziran 2026’da PostgreSQL çalışması alınmıştır; bu gelişme tüm yayımlanmış sürümler, eklentiler ve geçiş yolları için uyumluluk garantisi değildir. Aynı şekilde tüm ERPNext sürümleri için kesin PostgreSQL desteksizliği de çıkarılamaz.
- Günlük veritabanı ve dosya yedeğini tutarlı bir geri yükleme noktası oluşturacak şekilde planlayın; RPO hedefi bir günden kısaysa sıklığı artırın.
- SSH erişimi sadece belirli IP’lere açık, ERP paneli HTTPS üzerinden yayınlanıyor
Bu mimarinin ne kadar süre yeterli kalacağı, eşzamanlı kullanım, modüller, veri büyümesi ve entegrasyon yüküne bağlıdır; kapasite kararını izleme ve yük testi sonuçlarıyla verin. İzleme ve loglama ihtiyacı arttıkça, ayrı bir küçük VPS üzerine merkezi loglama istasyonu eklenerek büyütülebilir.
Senaryo 2: Çok Lokasyonlu Üretim Firması (30–60 Kullanıcı)
Durum: Birden fazla depo, üretim modülü, yoğun stok hareketi, sık raporlama, entegrasyonlar (e-fatura, B2B, e-ticaret).
- Denenecek örnek altyapı: 2 adet NVMe VPS; aşağıdaki kaynaklar kapasite garantisi değildir
- VPS-1: Odoo/ERPNext uygulaması (6–8 vCPU, 12–16 GB RAM)
- VPS-2: Odoo için PostgreSQL veya bu ERPNext örneği için MariaDB veritabanı (4–6 vCPU, 16–24 GB RAM, daha yüksek NVMe disk kapasitesi)
- Opsiyonel: Küçük bir üçüncü VPS üzerinde loglama + izleme (desteklenen bir toplayıcıyla Loki; ayrı metrik toplaması için Prometheus; Grafana panoları)
Veritabanını ayırmak kaynakları bağımsız büyütmeye yardımcı olabilir, fakat ağ gecikmesi ve işletim yükü ekler. Raporlama replikası kullanılacaksa desteklenen çoğaltma yolunu, gecikmeyi ve tutarlılığı sınayın. Bu iki sunuculu örnekte her katman hâlâ tek arıza noktasıdır; failover ayrıca tasarlanıp test edilmelidir.
Senaryo 3: ERP Tabanlı SaaS Girişimi
Durum: Birden fazla müşteriye Odoo/ERPNext bazlı SaaS hizmeti sunan bir girişim; her müşteri için ayrı veritabanı, bazıları için ayrı modül setleri.
- Ölçümle uyarlanacak örnek altyapı:
- 1–2 adet güçlü NVMe VPS üzerinde Odoo/ERPNext uygulama katmanı (yüksek vCPU sayısı)
- 1 adet dedicated veritabanı sunucusu (veya büyük RAM’li güçlü VPS)
- İsteğe bağlı olarak farklı müşterileri farklı VPS kümelerine bölerek kaynak rekabetini sınırlama; erişim izolasyonunu ayrıca doğrulama
Birden fazla uygulama düğümünde ortak dosyaları/ekleri, oturumları, arka plan kuyruklarını, scheduler sahipliğini ve alan adı yönlendirmesini uygulamanın desteklediği tasarımla çözün. Bir yük dengeleyici eklemek veritabanı, dosya veya kuyruk katmanında otomatik yedeklilik sağlamaz.
Bu mimaride otomatik deploy, CI/CD, staging ortamları, domain ve SSL yönetimi gibi konular öne çıkıyor. SaaS uygulamaları için çok kiracılı mimari rehberimizde anlattığımız yaklaşımlar, ERP tabanlı SaaS için de değerlendirme çerçevesi sağlar; Odoo’nun veritabanı yönlendirmesi veya ERPNext’in site yapısı, genel tenant_id örneklerinin doğrudan uygulaması değildir.
Sürüm yükseltmesini ayrı staging ortamında tutarlı ve gerekli verileri maskelenmiş bir kopyayla prova edin. Test ortamında gerçek e-posta, ödeme/e-fatura bağlantıları ve zamanlanmış dış etkileri kapatın. Geri dönüş için eski uygulama/eklenti sürümleri, yapılandırma, veritabanı ve dosyaları birlikte koruyun; yükseltilmiş Frappe veritabanını eski sürüme yüklemek desteklenen bir downgrade yolu değildir. Geri dönüşten önce yeni kayıtların nasıl korunacağına karar verin.
Sonuç ve Yol Haritası
Odoo, ERPNext ve benzeri CRM/ERP uygulamalarında VPS seçimini işlem yükü, veri büyümesi, erişim sınırı ve kurtarma hedefleriyle birlikte yapın. Uzun dönem tahmini bir planlama girdisidir; gerçek kapasiteyi temsilî işler ve izleme sonuçları belirler.
İlk adım olarak, kullanıcı sayınızı, modül kapsamınızı ve büyüme hızınızı kabaca çıkarın. Ardından bu rehberde ele alınan şu başlıkları değerlendirin:
- Tek VPS / çoklu VPS / dedicated senaryolarını,
- CPU, RAM, NVMe disk ve bant genişliği planlamasını,
- Güvenlik, yedekleme ve loglama önceliklerini
Bu başlıkları bir kapasite ve işletim tablosuna yerleştirin. DCHost veya değerlendirilen sağlayıcıyla kaynak sınırlarını, yedek kapsamını, yükseltme koşullarını ve işletim sorumluluklarını netleştirin. ERP kurulumu, uygulama güncellemeleri ve taşıma desteğinin seçilen hizmete dahil olduğunu varsaymayın.
Canlıya geçmeden önce oturum açma, fatura/ek dosya akışı, zamanlanmış iş, yedekten dönüş ve alarm bildirimini deneyin. Taşımada bakım penceresi boyunca kullanıcı, worker ve entegrasyon yazılarını durdurup son tutarlı kopyayı doğrulayın; eski ve yeni ortamı aynı anda yazılabilir bırakmayın. DNS önbellekleri kesintisiz geçiş garantisi vermez. Ölçüm sonuçlarını ve geri dönüş sınırını kayıt altına alarak işletime başlayın.
